[Gdal-dev] OGR, PROJ.4, and handling of Datum

[Ed McNierney]

Ben -

Well, you could be right about this being a missing grid shift file.
Before I wrote I checked the National Geodetic Survey converters, and
they use the same grid shifts.  Then I tried the current version of
Corpscon (Nadcon) just to be sure - no luck.  So it appears the Army
Corps of Engineers won't convert those old Army coordinates <g>.

When you report the "correct output", are you saying you have some other
tool that DOES do the conversion, or are you just estimating the
expected value?

I presume that the Army (or whoever) created a local NAD27-derived
Panama datum for doing their work.  Unfortunately, if you want to get
the conversions right you're going to need to research what that datum
really is and get documentation for it.  I know that work in Central
America used a few datums derived from NAD27 with varying degrees of
rigor - you might trying hunting in NIMA / DMA documents for it.

	- Ed

Ed McNierney
President and Chief Mapmaker
TopoZone.com / Maps a la carte, Inc.
73 Princeton Street, Suite 305
North Chelmsford, MA  01863
Phone: (978) 251-4242  Fax: (978) 251-1396
ed at topozone.com


-----Original Message-----
From: Ben Discoe [mailto:ben at vterrain.org] 
Sent: Wednesday, April 16, 2003 10:57 PM
To: gdal-dev at remotesensing.org
Subject: RE: [Gdal-dev] OGR, PROJ.4, and handling of Datum

> -----Original Message-----
> From: Ed McNierney
>
> While it might seem "quite reasonable" to think 7 degrees North, 81
> degrees West is covered by NAD27, it's not there.  So the first issue
is
> that your datum shift effort should not ever succeed, because the
input
> value is undefined (outside valid domain).

Hmmmmm...  i have this message from the person who provided the Panama
data:
"I have two sources of data..  The basemaps down there are 1960's
vintage US
Army, and are clearly labeled NAD27 / Clark 1866 spheroid, UTM Zone 17."

So perhaps there is such as a thing as NAD27 for Panama, and we (users
of
PROJ) simply lack a Datum shift file for it.

> You didn't describe exactly what OGR does, other than give "bogus"
> results.  Can you give us a bit more detail?  Thanks!

Correct output for the UTM point is around: (-81.8, 7.7)
The resulting OGRCoordinateTransformation is producing: (-1.42, 0.13)

Eeek, i just realized that it's incorrect to point the finger at OGR's
successful creation of a transformation - the failure isn't until the
Transform, and Transform is indeed return 0 to indicate an error for the
point lying outside its known Datum conversion space.  What was throwing
me
off is that although it returns 0 to indicate error, it *also* modifies
the
values passed in by pointer, as if it was succeeding :)

-Ben

_______________________________________________
Gdal-dev mailing list
Gdal-dev at remotesensing.org
http://remotesensing.org/mailman/listinfo/gdal-dev