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

[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).

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

	- 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: VTP [mailto:ben at vterrain.org] 
Sent: Wednesday, April 16, 2003 10:13 PM
To: gdal-dev at remotesensing.org
Subject: [Gdal-dev] OGR, PROJ.4, and handling of Datum


I would have sent this to the PROJ mailing list, but it pertains to OGR
as
well.

When trying to convert coordinates from NAD27 to WGS84, i found that OGR
was
giving me wildly incorrect results.  The first thing i managed to do was
to
duplicate the results with the latest PROJ.4:

>cs2cs +proj=utm +zone=17 +datum=WGS84 +to +proj=latlong +datum=WGS84
400000 800000
81d54'20.901"W  7d14'11.633"N 0.000
(Works)

>cs2cs +proj=utm +zone=17 +datum=NAD27 +to +proj=latlong +datum=WGS84
400000 800000
*       * 0.000
(Fails, the only difference is that it attempts a Datum conversion)

This is an island off Panama; quite reasonable i believe to be covered
by
NAD27.  Turning on debug information with PROJ, we find:

>cs2cs +proj=utm +zone=17 +datum=NAD27 +to +proj=latlong +datum=WGS84
pj_open_lib(proj_def.dat): call fopen(C:\proj\nad/proj_def.dat) -
succeeded
pj_open_lib(proj_def.dat): call fopen(C:\proj\nad/proj_def.dat) -
succeeded
400000 800000
pj_open_lib(conus): call fopen(C:\proj\nad/conus) - succeeded
Ctable Conterminous United States 273x121: LL=(-131,20)
UR=(-62.75,50.25)
pj_open_lib(alaska): call fopen(C:\proj\nad/alaska) - succeeded
Ctable Alaska 529x249: LL=(-194,46) UR=(-127.875,77.125)
pj_open_lib(ntv2_0.gsb): call fopen(C:\proj\nad/ntv2_0.gsb) - failed
pj_open_lib(ntv1_can.dat): call fopen(C:\proj\nad/ntv1_can.dat) - failed
pj_apply_gridshift(): failed to find a grid shift table for
                      location (-81.9057962dW,7.2370229dN)
   tried: @conus, at alaska, at ntv2_0.gsb, at ntv1_can.dat
*       * 0.000

Question #1: What is this ntv2_0.gsb file?  If PROJ looks for it, why is
it
not included with the standard PROJ distribution data?

Now, on to OGR.  When i use OGRCreateCoordinateTransformation() for the
same
transformation as above, it cheerfully gives me an
OGRCoordinateTransformation object which proceeds to perform totally
bogus
conversions.

Question #2: Since PROJ is clearly failing in this case, shouldn't
OGRCreateCoordinateTransformation fail, i.e. return NULL?  Is this a
lack of
error-checking in OGR, PROJ, or both?

Thanks,
Ben


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