| Re: UTM Map Projection Produces Incorrect Results [message #78167 is a reply to message #78166] |
Mon, 31 October 2011 11:33   |
lecacheux.alain
Messages: 325
Registered: January 2008
|
Senior Member |
|
|
On 31 oct, 19:06, Fabzou <fabien.mauss...@tu-berlin.de> wrote:
> THIS IS INCREDIBLE.
>
> The ELLIPSOID keyword may be not documented because the IDL people
> doesn't want us to use it, and use ENVI for more complicated
> transformations (datum shifts, etc).
>
> Now I am terribly confused by this information...
>
> I made the test with the WALBECK (not WALBACK) projection and I have the
> same results as you, David. Fortunately, our applications doesn't
> require such a precision but the damage in some (already published) data
> is done... :(
>
> And what about all the other projections? Do I have to check all IDL
> results against the ESRI engine from now on? I hope not!!!
>
> Fab
>
> On 10/31/2011 06:42 PM, David Fanning wrote:
>
>
>
>> Ed Hyer writes:
>
>>> I am still confused. The first line of code in your article uses a
>>> keyword to MAP_PROJ_INIT, "ELLIPSOID='wgs84'", which I can find
>>> nowhere in the documentation of MAP_PROJ_INIT. I see a DATUM keyword
>>> (that doesn't solve the problem described-- map parameters are still
>>> spherical when I specify DATUM=8). Was this ELLIPSOID keyword
>>> introduced in a recent version?
>
>> I don't know. It works in both IDL 7.1 and IDL 8.1. I guess I have
>> been using it for awhile.
>
>>> Anyway, perusing the group archive, I see that Andrew Cool in 2004
>>> said "I suspect that there is an inherent problem in IDL's mapping
>>> routines in the way they handle Transverse Mercator and rotation."
>
>>> Might be worth updating this page with new information:
>>> http://www.idlcoyote.com/map_tips/utm_to_ll.html
>
>> Yeah. I just received acknowledgment from the support folks
>> at (whatever the company is named now, can't remember) that the
>> WGS84 ellipsoid is broken. They suggest using the WALBACK
>> ellipsoid, which is nearly identical. In some tests I have
>> just conducted, the error is less than a meter using this
>> ellipsoid. (I'll update my article in just a couple of minutes.)
>
>> There are still some things about the UTM projection I don't
>> understand, but this seems to get around the major problem
>> I was having with it. They tell me the WGS84 ellipsoid problem
>> is fixed in the next version of IDL. (The semi-major axis and
>> eccentricity values in the map structure that is returned from
>> Map_Proj_Init for a UTM projection also contains the values
>> 6370997.0 and 0.000, respectively. These are clearly values
>> for a sphere. So, be careful if you use map structure values
>> directly.)
>
>>> proj.4 is nice any everything, but one of the strongest points
>>> remaining in IDL's favor is that it does not use external libraries
>>> and thus does not have dependency troubles that plague other
>>> solutions. In the short-term, they should just fix the bug-- I
>>> seriously doubt that there was ever a version of the GCTP software
>>> that couldn't handle UTM.
>
>> Well, I would think. :-)
>
>> Cheers,
>
>> David
>
>> P.S. Is it just my imagination, or does the name of this
>> company change more than the name of the latest "new"
>> graphics system?- Masquer le texte des messages précédents -
>
> - Afficher le texte des messages précédents -
Changing "WGS84" to "Walbek" or to anything else will not correct the
error in "map_proj_init"! Following my recent post (29 oct., 19:10),
the problem in IDL code appears to be a wrong and systematic
replacement of the given datum by a sphere as long as the projection
identifier is larger than 20 (i.e. in case of a projection to be
processed by GCTP library). This makes likely unusable the entire
implementation of GCTP software in IDL: in other words, we have to
stay with "map_set" and forget "map_proj_init".
One may expect a fix in further IDL version.
alx.
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
