| Re: UTM Map Projection Produces Incorrect Results [message #78164] |
Mon, 31 October 2011 12:23  |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
David Fanning writes:
> In the tests I've done, these seem to be passed properly,
> except in the case of the UTM projection. I honestly
> haven't been able to track down HOW the UTM projection works
> from the code I've looked at, but I agree that it is working
> *somehow* if I use the Walbeck projection.
By the way, I am in the process of updating all of my
map projection software (MapCoord, GeoCoord, etc.) to
work around this bug. It should be available soon.
In the one application that caused all this confusion in
the first place, the changes work great!
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.idlcoyote.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
|
|
|
|
| Re: UTM Map Projection Produces Incorrect Results [message #78165 is a reply to message #78164] |
Mon, 31 October 2011 12:20  |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
alx writes:
> 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.
The technical support folks are looking into this for me,
but I suspect this probably isn't a problem right now. The
CGTP projections don't actually use a datum. They use
semi-major and semi-minor axes. If these get set properly
in the parameter vector that is passed on to the GCTP
software, there shouldn't be a problem.
In the tests I've done, these seem to be passed properly,
except in the case of the UTM projection. I honestly
haven't been able to track down HOW the UTM projection works
from the code I've looked at, but I agree that it is working
*somehow* if I use the Walbeck projection.
Anyway, the folks are looking at this and promise to get
back in touch. I'll let you know if I learn anything more.
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.idlcoyote.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
|
|
|
|
|
|
| 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.
|
|
|
|
|
|
| Re: UTM Map Projection Produces Incorrect Results [message #78169 is a reply to message #78168] |
Mon, 31 October 2011 11:06 |
Fabzou
Messages: 76
Registered: November 2010
|
Member |
|
|
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?
>
>
|
|
|
|
| Re: UTM Map Projection Produces Incorrect Results [message #78170 is a reply to message #78169] |
Mon, 31 October 2011 10:42 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
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?
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.idlcoyote.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
|
|
|
|
|
|
| Re: UTM Map Projection Produces Incorrect Results [message #78252 is a reply to message #78164] |
Tue, 01 November 2011 09:04 |
chris_torrence@NOSPAM
Messages: 528
Registered: March 2007
|
Senior Member |
|
|
Hello everyone,
First of all, the DATUM keyword was renamed to ELLIPSOID in IDL 7.1. IDL's map routines do not support true "datum" shifts, and so that keyword was poorly named. The DATUM keyword is still honored, and will behave identically to ELLIPSOID. The documentation for MAP_PROJ_INIT describes this change.
Second, there was a bug in the GCTP library: for the UTM projection it did not let you pass in arbitrary semimajor/semiminor axis values. Instead, you could only use one of the predefined 20 ellipsoids, which did not include WGS84. In the IDL documentation for MAP_PROJ_INIT, ellipsoids 0-19 would work fine, while 20-24 would just default to the Clark 1866 sphere. Now, ellipsoid #12 (Walbeck) is *identical* to WGS84, and will give you the *exact* same results as if you had used WGS84.
In IDL 8.2, this GCTP bug has been fixed, and you can now use all 25 predefined ellipsoids (including WGS84), as well as using your own semimajor/semiminor axes.
Third, in the !MAP structure, there is a !MAP.A and !MAP.E2 which should contain the semimajor and eccentricity(squared) values. If !MAP.E2 is zero, then you are using a spherical ellipsoid.
Fourth, we are always evaluating our libraries for IDL. The PROJ.4 or ESRI PE libraries are certainly an option, and we may consider upgrading to one of them in the future. However, the real reason to upgrade is not to improve existing map projections, but to gain access to new map projections, ellipsoids, and datum shifts. Nothing about the UTM projection is going to "get any better" between the GCTP and PROJ.4 libraries. The equations are still the same. Now, in this case, maybe we wouldn't have had this particular GCTP bug, but there are certainly some PROJ.4 bugs which we would inherit if we switched libraries.
Fifth, we are going to have a beta for IDL 8.2 in the next few weeks. If you are interested in testing out this fix, as well as trying out the new features, please contact Bill Okubo. He'll be posting a message shortly about the beta.
Thanks,
Chris Torrence
Exelis VIS
p.s. the name may have changed, but we're still the same people
|
|
|
|
| Re: UTM Map Projection Produces Incorrect Results [message #78303 is a reply to message #78170] |
Thu, 03 November 2011 19:11 |
Andrew Cool
Messages: 219
Registered: January 1996
|
Senior Member |
|
|
>> 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."
Thou ought not quote a man with a brain tumour. I may not have been
home that day.
Andrew
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
