<div dir="ltr">Hi Even,<div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 31, 2016 at 1:48 PM, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Sean,<br>
<br>
We ended up cancelling the BoF.<br>
I had a discussion with someone (Dmitry perhaps ?) and there was some concerns<br>
expressed by turning on RFC 7946 by default, even in the case of a source<br>
dataset in EPSG:4326. Particularly because of the behaviour at dateline, where<br>
RFC 7946 asks for geometries to be cut and coordinates to be wrapped around<br></blockquote><div><br></div><div>Could I hear more about these concerns? Are there situations where it is more interoperable to not cut antimeridian-crossing geometries? I know of software (<a href="http://geojson.io">geojson.io</a>, for example) that doesn't constrain longitude to earthly values when converting coordinates to Web Mercator, but because this behavior isn't actually specified any interoperability here seems to be coincidental at best.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
One downside of having a new driver is that it creates issues for the read<br>
side of it. Due to the absence of versionning, how would you know if a json<br>
file must be handled by one driver or another ? In some cases, you could know<br>
(e.g. presence of a "crs" object), but generally you would need to parse the<br>
whole file and detect a few hints (like longitudes > 180 or <-180, unexpected<br>
orientation for polygons, etc). So you might end up parsing the file twice.<br></blockquote><div><br></div><div>Right. Also ordering varies in JSON files, so the "crs" object may very well be at the tail end of a large document. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
So I'd be more on the position to have a single driver that supports writing<br>
both "flavours" through a creation option. And probably default to GJ2008 to<br>
avoid breaking existing workflows (perhaps with some warning in release notes<br>
that the default might change in a later release, so people should explicitly<br>
specify the creation option if they depend on the precise flavour)<br>
We could conceptually have a light-weight RFC7946 driver (or whatever we would<br>
call it) that would be just a wrapper around the existing driver and would set<br>
the creation option with the right flavour, but that would probably be a bit<br>
weird that this driver is never used on the read side (due to what I<br>
mentionned above).<br></blockquote><div><br></div><div>This seems reasonable.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
One thing that is not completely obvious is how to handle edition capabilities<br>
(ie when the dataset is opened in open mode). When you re-write the file after<br>
a feature addition/update/deletion, which flavour do you choose ? Probably use<br>
the heuristics I mentionned before to have a best guess, and offer an open<br>
option with the flavour as well.<br>
<br></blockquote><div><br></div><div>Frankly, I think that JSON is too poorly suited to the role of database to bother with the above. Despite that, I think it wouldn't be a terrible burden on those who want to keep RFC 7946 GeoJSON to specify this in a config option so that we could skip the heuristics. We could use the same one as suggested above, I think.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For RFC 7946, there were different opinions if I re-read the thread regarding<br>
if we must turn on automatic reprojection to EPSG:4326, or just error out if<br>
the CRS used at layer creation time is EPSG:4326.<br>
We have already a few drivers whose underlying format is coordinates in<br>
lon,lat and that accept arbitrary CRS at creation time with on the fly<br>
reprojection. One advantage of this is that you can identify more easily<br>
geometries at the pole or the anti-meridian and thus write them correctly<br>
according to the new rules.<br>
But anyway we would also need some heuristics in the case where you convert to<br>
RFC 7946 for example from a format in EPSG:4326 with geometries cut at the<br>
dateline. In the OGR geometry model, there's nothing that explictly tells if<br>
the geometry has been cut or not. So you might need to use the following<br>
heuristics: if a multipart geometry has longitudes both at -180 and 180 in<br>
different parts (ie that the same part of a geometry doesn't have points both<br>
at -180 and 180), then it has been cut.<br></blockquote><div><br></div><div>I don't understand why we would need to know if a geometry has already been cut. Is antimeridian cutting not idempotent? By which I mean that cutting again would be a no-op if the data has already been cut.</div></div><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Sean Gillies</div></div>
</div></div>