Take the 2-minute tour ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

As I understand it, a datum transform (e.g. urn:ogc:def:coordinateOperation:EPSG::1241) based on a grid interpolation method, e.g. NADCON, is undefined outside of the grid of points. Therefore the lat/long of Mexico city as expressed in NAD 1927 cannot be converted to WGS 1984 by way of this NADCON conversion -- it's not in the United States.

If you call the ESRI projection engine directly (pe.dll#pe_geog1_to_geog2), it simply doesn't transform the coordinates outside of the NADCON grid, though does return a code reminding you that this has happened. (The return code is the # of points transformed, which if less than the # of points you passed in is a sign of trouble.)

My guess is that (most?) everywhere else in the ESRI stack, this return code is ignored, and the transform is simply left as effectively zero outside of the grid area.

This might be as good an answer as any. What should we be doing instead? In our code at the moment we throw an exception, but this is a contagious and awful thing as it means people looking at studies using this transform can't zoom out past a certain extent.

share|improve this question
add comment

2 Answers

up vote 0 down vote accepted

I suppose you could write a custom class that implements IGeoTranformation and maintains two lists: a list of IGeotransformations (NADCON and whatever_mexico_uses), and list of polygons (e.g. US polygon & Mexico polygon) describing the area covered by the corresponding transformation.

Unlike the ICompositeGeoTransformation, which chains its geotransformations, you could implement TransformPointsFF such that it uses the geotransformation based on which polygon in your list the points fall within.

share|improve this answer
    
This is likely the 'best' answer, though with ESRI APIs you can avoid the expensive point-in-polygon test by noting which coordinates were not transformed after each candidate transform. I think you're out of look if you're using ArcObjects, as I'm pretty sure they just swallow the error. –  Sebastian Good Aug 30 '10 at 23:47
    
I wonder how far into GoM NADCON is valid. At some point you'd be better off using one of the "secondary" transforms (see pg 6), but the extents of those aren't documented very well either: apsg.info/resources/Documents/APSG_GOM_Guidelines_3.pdf –  Kirk Kuykendall Aug 31 '10 at 3:13
add comment

It sounds like the software is doing the right thing: not pretending to have information it doesn't when the requested datum shift doesn't extend to the area of interest.

That said, there are other datum shifts which do provide a conversion for areas outside of the continental US, such as these NAD 1927 three parameter transformations though accuracy may be insufficient for your needs, this thread says ~12m accuracy is likely. Without knowing more of what you're trying to achieve, it isn't clear if something like this is appropriate.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.