[PATCH] Allow users to force a call to morphFromESRI() in importFromWkt()

[Kyle Shannon]

I have run into datasets that sometimes have ESRI WKT embedded, but the driver doesn't necessarily call morphFromESRI(), and a proj4 definition can't be created. This means warping/reprojection won't work. Simple config option/patch to allow this in OGRSpatialReference()::morphFromESRI(), perhaps I should add it to setFromUserInput() as well. I'll commit if there are no objections, and there isn't a mechanism that I missed that would do the same thing.

[Even Rouault]

I'm wondering if this couldn't be guessed to some extent. For example, AFAIK, ESRI datum names always start with "D_" and they have no AUTHORITY nodes. The name of nodes have never spaces too. At least that's what morphToESRI() does. It also seems that GCS names always start with GCS_ (​http://resources.esri.com/help/9.3/arcgisserver/apis/rest/gcs.html, confirmed also with ​http://webhelp.esri.com/arcims/9.3/general/mergedprojects/ArcXMLGuide/elements/pcs.htm and ​http://webhelp.esri.com/arcims/9.3/general/mergedprojects/ArcXMLGuide/elements/gcs.htm), but this last rule isn't necessarily always followed by morphToESRI()

But the automation should probably not be done in importFromWkt() itself, since we want to be able to loss-lessly import/export ESRI WKT. So perhaps a isESRIWkt() method that would be used by the drivers that can encounter it (assuming they are not too many) ? Or perhaps if we want to be more general a guessWktVariant() that would return OSR_OGC_WKT_1 or OSR_ESRI_WKT (and could later be extended to OSR_OGC_WKT_2 if we ever support it)

If that sounds too complicated / not reliable, your patch is OK.

[Kyle Shannon]

Even,

That's probably a better way to handle it. I may leave the force option in as well, but I will work up a IdentifyEsri() or some such function that checks datum names, as you mentioned and maybe PROJCS names. Thanks for the input.

[Even Rouault]

Unmilestoning

[Even Rouault]

This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to ​https://github.com/OSGeo/gdal/issues if it is not already reported there.