Opened 4 years ago

Last modified 4 years ago

#5415 new defect

MorphToESRI creates an ambiguous WKT for EPSG:2903 (NM Central HARN , NAD83)

Reported by: roomthily Owned by: warmerdam
Priority: lowest Milestone:
Component: OGR_SRS Version: 1.9.1
Severity: normal Keywords:


We've been building tile indexes for MapServer? and, while testing, noticed an issue when generating a file for EPSG:2903 (NAD83(HARN) / New Mexico Central (ftUS)).

The errors include failing to render the geometries in QGIS and MapServer? dumping the memory map. When looking at the properties in QGIS, the CRS is marked as 2258 instead of 2903. The shapefile is created using the 2903 spatial reference with the morphtoesri output in the PRJ file.

The WKTs:

>>> from osgeo import osr
>>> s2258 = osr.SpatialReference()
>>> s2258.ImportFromEPSG(2258)
>>> s2903 = osr.SpatialReference()
>>> s2903.ImportFromEPSG(2903)
>>> s2258.ExportToWkt()
'PROJCS["NAD83 / New Mexico Central (ftUS)",GEOGCS["NAD83",DATUM["North_American_Datum_1983",SPHEROID["GRS 1980",6378137,298.257222101,AUTHORITY["EPSG","7019"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY["EPSG","6269"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4269"]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",31],PARAMETER["central_meridian",-106.25],PARAMETER["scale_factor",0.9999],PARAMETER["false_easting",1640416.667],PARAMETER["false_northing",0],UNIT["US survey foot",0.3048006096012192,AUTHORITY["EPSG","9003"]],AXIS["X",EAST],AXIS["Y",NORTH],AUTHORITY["EPSG","2258"]]'
>>> s2903.ExportToWkt()
'PROJCS["NAD83(HARN) / New Mexico Central (ftUS)",GEOGCS["NAD83(HARN)",DATUM["NAD83_High_Accuracy_Reference_Network",SPHEROID["GRS 1980",6378137,298.257222101,AUTHORITY["EPSG","7019"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY["EPSG","6152"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4152"]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",31],PARAMETER["central_meridian",-106.25],PARAMETER["scale_factor",0.9999],PARAMETER["false_easting",1640416.667],PARAMETER["false_northing",0],UNIT["US survey foot",0.3048006096012192,AUTHORITY["EPSG","9003"]],AXIS["X",EAST],AXIS["Y",NORTH],AUTHORITY["EPSG","2903"]]'
>>> mte2903 = osr.SpatialReference()
>>> mte2903.ImportFromEPSG(2903)
>>> mte2903.MorphToESRI()
>>> mte2903.ExportToWkt()

Example of the MapServer? error:

*** glibc detected *** XXXX           : free(): invalid next size (fast): 0x00007f242e494610 ***
======= Backtrace: =========/lib/x86_64-linux-gnu/[0x7f243aa2a626]/opt/modwsgi/XXXX_env/lib/python2.7/site-packages/MapScript-6.0.3-py2.7-linux-x86_64.egg/[0x7f2422816e6b]/opt/modwsgi/XXXX_env/lib/python2.7/site-packages/MapScript-6.0.3-py2.7-linux-x86_64.egg/[0x7f2422816e95]/opt/modwsgi/XXXX_env/lib/python2.7/site-packages/MapScript-6.0.3-py2.7-linux-x86_64.egg/[0x7f242284bbdb]/opt/modwsgi/XXXX_env/lib/python2.7/site-packages/MapScript-6.0.3-py2.7-linux-x86_64.egg/[0x7f24228610a5]

We're using osgeo 1.9.1 (python 2.7), MapServer? 6.0.3, and QGIS 1.7.2. Of course, ArcGIS 10 has no problem rendering the shapefile. And there's obviously no issue with creating and using a shapefile in EPSG:2258.

The simplest solution is just not to use MorphToESRI with 2903.

Attachments (1) (777.4 KB) - added by roomthily 4 years ago.

Download all attachments as: .zip

Change History (8)

comment:1 Changed 4 years ago by Kyle Shannon

Could you attach a small dataset that fails to render? It'd be helpful.

comment:2 Changed 4 years ago by Jukka Rahkonen


QGIS 1.7.2 is probably using pretty old GDAL. Could you try how the current QGIS 2.2 behaves?

comment:3 Changed 4 years ago by Even Rouault

I think there are different defects, in MapServer? and in QGIS. For MapServer? I doubt the SRS is the cause of the crash you see... As far as QGIS is concerned, I think it bases its recognition of SRS on the proj.4 string and EPSG:2258 and EPSG:2903 have the same proj.4 string :

  • before morphing to ESRI : '+proj=tmerc +lat_0=31 +lon_0=-106.25 +k=0.9999 +x_0=500000.0001016001 +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=us-ft +no_defs '
  • after morphing to ESRI : '+proj=tmerc +lat_0=31 +lon_0=-106.25 +k=0.9999 +x_0=500000.0001016001 +y_0=0 +ellps=GRS80 +units=us-ft +no_defs '

I'm not sure if the difference between both EPSG code is that significant : NAD83 vs NAD83(HARN) ?

Well, looking at, it seems that we could possibly turn the NAD83(HARN) into "+datum=NAD83 +nadgrids=azhpgn.gsb", but as that grid is not in the base proj.4 grids, I'm not sure this is a good idea.

Changed 4 years ago by roomthily

Attachment: added

comment:4 Changed 4 years ago by roomthily

The current QGIS 2.2 can render the file. The CRS is empty for it, though.

As far as the MapServer? issue being a different bug, it's possible but the only difference that we made between the WMS request against the original, non-functional shapefile and a functional shapefile was removing MorphToESRI from the build process.

comment:5 Changed 4 years ago by Even Rouault

The MapServer? issue should be reported on MapServer? bug tracker, with mapfile, data and request that triggers the crash.

comment:6 Changed 4 years ago by roomthily

Well, sure. And you can police your forum as you see fit.

But in this case, it might be a bit unrealistic to assume that a platform higher up the toolchain will correctly handle an issue like this. Especially if it's not a known issue and clearly not one bothering a whole heck of a lot of people. So in the interest of finding absolutely no information anywhere and feeling a bit community minded, I thought perhaps having some information about the cause and the symptoms at the source would be beneficial. My bad.

comment:7 Changed 4 years ago by Even Rouault

roomthily, you've misunderstood me. I'm also a MapServer? developer. My feeling is that the crash in MapServer? is due to a bug in MapServer?, not in OGR. I can be wrong, but without any direct mean of replicating, it is hard to tell. And the easier it is to replicate, the more likely it is that someone will spend a bit of time to analyze to see what happens.

I will also note that you don't use the latest stable versions of software. Perhaps upgrading to MapServer? 6.4 would solve the crash. And QGIS 2.2 is now out (1.7.3 is pretty old). I'm not sure that this will solve the confusion between the 2 SRS, but better be up-to-date.

As far as the global issue, I'm not sure how and if that can be fixed. SRS issues over the whole software stack tend to be complex ones. I already shared some thoughts above. And on my volunteer time... You can find a list of service providers for OSGeo software at

Note: See TracTickets for help on using tickets.