Opened 10 years ago
Closed 8 years ago
#5310 closed enhancement (fixed)
GeoJSON driver should pass through non-standard object members
Reported by: | sgillies | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | 2.1.0 |
Component: | default | Version: | unspecified |
Severity: | normal | Keywords: | json geojson annotation |
Cc: |
Description (last modified by )
The easiest way to extend the GeoJSON format is to add new members to Feature objects. Consider styling: better not to add styling parameters to a feature's properties where they may collide with or drown out feature attributes. Currently, the OGR GeoJSON driver filters out features members not specified in the GeoJSON or EsriJSON docs (plus a couple GeoCouch-specific members) and makes new feature properties the only practical way to extend GeoJSON. This is not an ideal situation.
Let's let non-standard members pass through when using ogr2ogr and other tools to transform GeoJSON files and help developers experiment with extending the format.
Attachments (1)
Change History (8)
comment:1 by , 10 years ago
Description: | modified (diff) |
---|
comment:2 by , 10 years ago
by , 10 years ago
Attachment: | ticket_5310.diff added |
---|
Add an annotation interface to features and use it to carry extra JSON data between the JSON reader and writer
comment:3 by , 10 years ago
I had a couple tries at at this. In ~1, I wrote an OGRGeoJSONFeature class with a pszJsonText member but ran into trouble in ogr2ogr.cpp. Use of OGRFeature::CreateFeature as a factory for new features in TranslateLayer() seems to block the use of derived feature classes (at least for me as I'm not a very good C++ programmer). In the end, I've added an annotation interface to OGRFeature. The OGRGeoJSONReader class stashes the JSON text for Feature objects in the annotation and the OGRGeoJSONWriter class goes back to the annotation to look for an initial JSON object. This allows JSON objects not defined in the GeoJSON spec to pass through ogr2ogr.
comment:4 by , 10 years ago
Keywords: | geojson annotation added |
---|
comment:5 by , 10 years ago
Chatting with Even in IRC, here are a couple bits of this that could be improved:
metadata about format/media type/provenance of the annotation to prevent other writers from tripping over "foreign" annotations. Maybe we add a "note type" member bearing the media type of notes, "application/json" in the GeoJSON case. If another member is ruled out, I could pass JSON data in the note as a data URI (http://tools.ietf.org/html/rfc2397). This is an encoded string that carries its own media type.
I could delete some JSON data members before stashing the rest in the note. The properties and geometry ones in particular. They'll be overwritten by values coming from the OGR feature and so there's no point in saving them.
comment:7 by , 8 years ago
Milestone: | → 2.1.0 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
RFC 60 has been merged into trunk
Sounds good to me. It sounds like Sean is planning to prepare a patch in the next few weeks.