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.

2 Answers 2


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.


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.

  • 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. Aug 30, 2010 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 Aug 31, 2010 at 3:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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