Andrew, > > I'm passing a WKT CRS into GTIFSetFromOGISDefn(). The WKT is valid in that > it conforms to the OGC representation v1.0 (12-063-r5). The function > mentioned above parses the WKT into nodes properly, but the code that tries > to interpret the actual WKT can't deal with the new specification. > However, it doesn't error. Instead, it sets a bunch of value to be > "user-defined" and results in Geotiff keys that don't map to the input CRS. > > Is there a reason that a "bad" CRS is mapped as a user-defined value rather > than returning an error?
GDAL doesn't handle WKT 2 yet (the parsing of the WKT as a OGRSpatialReference object happens to work as both WKT 1 and 2 are serialized in similar way), so the current behaviour is not surprising. GTIFSetFromOGISDefn() should indeed probably error out if it identifies the WKT as WKT v2. Note that we don't want to reject all WKT that we don't recognize entirely, since the code can for example handle a WKT (v1) with a projection method it doesn't recognize as a ESRI WKT PE string. > Is there a plan to update WKT code to handle the > new specification? Nobody is working on it as far as I know (it has been proposed as a potential subject in past GSoC programs), but that would be indeed neat to consider it. The big question is : how ? One of the possibilities would be to map WKT v2 as WKT v1 on ingestion, so that only affects a single part of the code. Another possibility would be to accept both in all places where GDAL handles WKT / OGRSpatialRefrence, but that means updating all drivers that map WKT to their own internal representation. None of them are really satisfactory. Or a third one would be to make WKT 2 the internal representation and WKT 1 just on import/export borders, but that also requires updating various drivers, and there would be some loss of information as WKT 1 has for example the TOWGS84 node that doesn't exist in WKT 2. Even -- Spatialys - Geospatial professional services http://www.spatialys.com
_______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
