<div dir="ltr"><br><br>On Tue, Jan 22, 2019 at 10:30 PM Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br>><br>> Hi Markus,<br>><br>> Thanks for your feedback<br>><br>> > Regarding WKT2, a remark from a GRASS GIS developer being a user of<br>> > GDAL/PROJ:<br>> ><br>> > I understand that WKT2 is long overdue and thus should be pushed as much<br>> > and as early as possible. Otherwise it would take a long time and a rather<br>> > long and painful transition process to switch to WKT2. My suggestion is to<br>> > try to keep the painful transition process as short as possible and switch<br>> > to WKT2 ASAP. People like to stick to what they have and what they know, so<br>> > if something better is available, some convincing is needed.<br>><br>> So you would be in favor of making OSRExportToWkt() default to WKT2 ?<br>> (probably WKT2:2018 while we are at it ? Not just the output of gdalinfo /<br><div>> ogrinfo utilities.</div><div><br></div><div>Yes, no half-hearted changes, make WKT2 the default wherever possible.<br></div><br>> I was shy in doing so, because it will likely require updating a good deal of<br>> GDAL autotests, but oh well...<br><div><br></div><div>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)...<br></div><div>></div>> What annoys me a bit more is the case of XML files like GDAL VRT, OGR VRT or<br>> .aux.xml that contains serialized SRS and that I wanted to be backward<br>> compatible with older GDAL versions as much as possible.<br><div><br></div><div>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?<br></div>><br>> > Regarding the BBOX, it should be made clear that the reported extents are a<br>> > suggestion, not a limitation.<br>><br>> The semantics is a bit fuzzy. The WKT standard mentions "Extent describes the<br>> spatial and/or temporal applicability of a CRS, datum, datum ensemble,<br>> coordinate operation or Bound CRS". For a CRS, you can go beyond depending on<br>> the numeric stability of the implementation of the projection method (in case<br>> of a projected CRS). For a coordinate operation, if it involves a grid, the<br>> BBOX should be interpreted in a rather strict way (that's what PROJ master<br>> does internally when computing the most appropriate coordinate transformation<br>> given all the constraints it is given)<br><div><br></div><div>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.</div><div><br></div><div>Markus<br></div><br></div>