[gdal-dev] Error Handling (or not) in GTIFSetFromOGISDefn

[Even Rouault]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20161214/80f11754/attachment.html>