mapbox/node-srs

.prj files: ESRI WKT vs OGC WKT

ajashton opened this issue · 5 comments

ajashton commented

Noticed this when testing some UK Ordinance Survey shapefiles in TileMill. These files are projected in EPSG:27700

The WKT definition in the .prj file that comes with the shapefile matches the 'ESRI WKT' text from spatialreference.org. But it seems TileMill interprets this as a 'OCG WKT' because the alignment of the render is off. If I replace the .prj file with the OCG WKT then TileMill renders the shapes correctly.

On spatialreference.org the 'PRJ File' download matches the ESRI style WKT - I'm guessing this is the more common (standard?) format for PRJ files. Is there anything we can do to change the way these files are interpreted to match this? From a users point of view, the SRS auto-detection for these files is wrong even though the .PRJ file is correct.

ajashton commented

@springmeyer I can send you the OS shapefiles if you want

springmeyer commented

Just posting the two WKT files is great, thanks!

springmeyer commented

nevermind, got them off spatialreference. It appears that the problem is that the ESRI variant is not detected as having +datum=OSGB36. Instead the proj4 produced has +ellps=airy.

springmeyer commented

And it appears the difference in the raw WKT that matters is DATUM["OSGB_1936" ... vs DATUM["D_OSGB_1936" ...

springmeyer commented

Okay, I see the full problem now. OGR/GDAL kinda sorta tries to auto-detect ESRI variant projections and then will call morphFromESRI internally to clean things up so that the projection can be understood as OGCish WKT. Node-srs works by first parsing a projection string normally and if that fails (to produce a proj4 value) then node-srs will fall back on forcing parsing as ESRI (which works for a lot of cases). But in this case the differences are so sublte that GDAL happily parses as NON ESRI (because this check does not catch anything ESRIish).

So, solutions are:

  1. GDAL/OGR could be patched to notice D_OSGB_1936 so that morphFromESRI() is called internally
  2. node-srs could detect D_OSGB_1936 and then prepend ESRI:: before parsing
  3. node-srs could just single case handling of this projection problem

#1 is a pain. #2 is confirmed to work in that then the proj4 returned would match exactly the proj4 return from the OGC version, but the downside is that the SRID and AUTH would still be undefined.