[gdal-dev] RFC 73 (aka gdalsrsbarn) available for review

[Markus Metz]

On Tue, Jan 22, 2019 at 10:30 PM Even Rouault <even.rouault at spatialys.com>
wrote:
>
> Hi Markus,
>
> Thanks for your feedback
>
> > Regarding WKT2, a remark from a GRASS GIS developer being a user of
> > GDAL/PROJ:
> >
> > I understand that WKT2 is long overdue and thus should be pushed as much
> > and as early as possible. Otherwise it would take a long time and a
rather
> > long and painful transition process to switch to WKT2. My suggestion is
to
> > try to keep the painful transition process as short as possible and
switch
> > to WKT2 ASAP. People like to stick to what they have and what they
know, so
> > if something better is available, some convincing is needed.
>
> So you would be in favor of making OSRExportToWkt() default to WKT2 ?
> (probably WKT2:2018 while we are at it ? Not just the output of gdalinfo /
> ogrinfo utilities.

Yes, no half-hearted changes, make WKT2 the default wherever possible.

> I was shy in doing so, because it will likely require updating a good
deal of
> GDAL autotests, but oh well...

These tests need to be updated at some stage anyway, when WKT2 becomes the
default. OTOH, it is also a question of balancing the workload for the
developer(s)...
>
> What annoys me a bit more is the case of XML files like GDAL VRT, OGR VRT
or
> .aux.xml that contains serialized SRS and that I wanted to be backward
> compatible with older GDAL versions as much as possible.

I guess for the time being there needs to be a switch to select WKT1 or
WKT2. With WKT2 being the default, some backward compatibility switch for
WKT1 would be needed. You have already described "an enhanced version of
exportToWkt() [that] accepts options to specify the exact WKT version used,
...". Maybe a generic config option would help users to switch back to WKT1?
>
> > Regarding the BBOX, it should be made clear that the reported extents
are a
> > suggestion, not a limitation.
>
> The semantics is a bit fuzzy. The WKT standard mentions "Extent describes
the
> spatial and/or temporal applicability of a CRS, datum, datum ensemble,
> coordinate operation or Bound CRS". For a CRS, you can go beyond
depending on
> the numeric stability of the implementation of the projection method (in
case
> of a projected CRS). For a coordinate operation, if it involves a grid,
the
> BBOX should be interpreted in a rather strict way (that's what PROJ master
> does internally when computing the most appropriate coordinate
transformation
> given all the constraints it is given)

The "fuzziness" seems appropriate since numeric instability is usually
occurring gradually and not suddenly when you leave the BBOX. Regarding
grids, a strict interpretation makes sense AFAICT. For CRS, users must
decide (as they already do) about the risk of numeric instability. For
example, Germany is covered by two UTM zones, but even official datasets
are happily mapped country-wide into one UTM zone, with the definition of a
UTM zone being pretty clear. Maybe with the help of a suggested BBOX users
become more aware that a selected CRS is not the best choice.

Markus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20190123/74ca6144/attachment.html>