<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jul 25, 2016 at 4:39 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi Sean,<br>
<span><br>
> The GeoJSON WG's draft-ietf-geojson,<br>
> <a href="https://datatracker.ietf.org/doc/draft-ietf-geojson/" rel="noreferrer" target="_blank">https://datatracker.ietf.org/doc/draft-ietf-geojson/</a>, is in the RFC Editor<br>
> queue and will be published soon. I'm considering whether adoption of the<br>
> updated GeoJSON (registered media type: application/geo+json) and support<br>
> for the older GeoJSON format (no registered media type) might be helped by<br>
> creating an entirely new driver.<br>
><br>
> A separate driver would keep the existing driver from becoming even more<br>
> complicated, yes? We would also have an opportunity to remove unnecessary<br>
> configuration options and support for other JSON formats that aren't really<br>
> GeoJSON.<br>
<br>
</span>I'm not completely sure we need a new driver just to support the revised<br>
geo+json spec. It is still mostly compatible with the original spec, right ?<br>
<br>
>From what I can see, the differences / new specifications are :<br>
- SRS fixed to CRS84<br>
- antimeridian cutting<br>
- right hand rule of polygons<br>
- bbox and the poles&antimeridian<br>
- the media type<br>
<br>
Am I missing something ?<br></blockquote><div><br></div><div>Two things (the full list of changes is at <a href="https://tools.ietf.org/html/draft-ietf-geojson-04#appendix-B.1" target="_blank">https://tools.ietf.org/html/draft-ietf-geojson-04#appendix-B.1</a>):</div><div><br></div><div>1. GeoJSON objects MUST NOT contain the defining members of other types. For example, a GeoJSON Feature must not have a "features" member. I don't see this coming up when converting from other formats, but OGR's GeoJSON driver should filter these out of native data when writing GeoJSON.</div><div><br></div><div>2. Implementations SHOULD NOT extend position arrays beyond 3 elements. The OGR driver should not by default write anything other than X, Y, Z. If it currently writes X, Y, Z, and M, the M should be omitted.</div><div><br></div><div>There's one informative change in <a href="https://tools.ietf.org/html/draft-ietf-geojson-04#appendix-B.2">https://tools.ietf.org/html/draft-ietf-geojson-04#appendix-B.2</a> that is relevant. When GeoJSON output is CRS84 only we can certainly reduce the default coordinate precision from 15 to 6 or 7.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
On the reading side, I think the existing driver requires little modification<br>
(extending "Accept: text/plain, application/json" to "Accept: text/plain,<br>
application/json, application/geo+json" for http:// or https:// datasource<br>
names) , so essentially the writing side would be affected.<br>
<br>
Regarding:<br>
- the right hand rule of polygons, it could be a new behaviour in all cases (<br>
the shapefile driver e.g. modifies the winding order to comply with the shapefile<br>
spec )<br>
- SRS fixed to CRS84, it is a matter of automatically reprojecting the input<br>
data to it if it is not CRS84, like done in the KML driver. That could be a<br>
default behaviour, with an option to use the deprecated crs object if really<br>
needed.<br>
- antimeridian cutting: can make sense as a default behaviour if the target<br>
SRS is CRS84. With the difficulty in doing the cutting properly ( ogr2ogr -<br>
wrapdateline heuristics can perhaps be improved )<br>
- bbox and antimerdian: if the geometry has been cut by the geojson driver, it<br>
is obvious to make the bbox conformant to the requirement. If it has been cut<br>
in a previous stage ( e.g in a geo+json->geo+json conversion), then you need<br>
to detect that the geometry has been cut ( its extent is -180 180) and then<br>
detect the extent of its parts<br>
- bbox and the poles : if the geometry is already in CRS84, then it looks like<br>
it should be just a matter of computing the bbox in the standard way from the<br>
geometry coordinates. If the geometry must be reprojected, then the issue is<br>
more the reprojection of the geometry itself :<br>
<a href="https://lists.osgeo.org/pipermail/gdal-dev/2016-July/044776.htm" rel="noreferrer" target="_blank">https://lists.osgeo.org/pipermail/gdal-dev/2016-July/044776.htm</a><br>
<br>
None of that really seems to call for forking a new driver.<br></blockquote><div><br></div><div>Automatic reprojection to CRS84 would break existing systems that counted on preservation of CRS. Addition of a configuration option like OGR_GEOJSON_2008=TRUE would help, but this would still be a breaking change, would it not?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
In the new spec, elevations are explictly ellipsoidal heights. In the old<br>
spec, it wasn't explicit. Although I'm not sure all elevations passed in a<br>
(x,y,z) triplet with x,y being in CRS84 are really ellipsoidal heights in<br>
practice, this is probably out of scope of the driver ( unless it would be fed<br>
with a SRS that would explictly specify the VERTCS and thus vertical datum<br>
transformation could potentially be done )<br>
<span><br>
><br>
> Does anyone feel that the existing driver code *would not* be a good place<br>
> to start and that we shouldn't arrive at a new driver by copying the<br>
> existing GeoJSON driver and removing unneeded code?<br>
<br>
</span>What could possibly justify a new driver to me is a driver that would support<br>
reading geojson files of arbitrary size without fully ingesting them into<br>
memory. That would have probably quite a big impact on the existing code base,<br>
especially since GDAL 2.1 where the driver assumes in-memory ingestion to be<br>
able to provide the update support.<br></blockquote><div><br></div><div>I do not know how OGR supports in-place update of GeoJSON, but I'll take your word on it.</div></div><div><br></div>-- <br><div><div dir="ltr">Sean Gillies</div></div>
</div></div>