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 sgillies)

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)

ticket_5310.diff (6.0 KB ) - added by sgillies 10 years ago.
Add an annotation interface to features and use it to carry extra JSON data between the JSON reader and writer

Download all attachments as: .zip

Change History (8)

comment:1 by sgillies, 10 years ago

Description: modified (diff)

comment:2 by warmerdam, 10 years ago

Sounds good to me. It sounds like Sean is planning to prepare a patch in the next few weeks.

by sgillies, 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 sgillies, 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 sgillies, 10 years ago

Keywords: geojson annotation added

comment:5 by sgillies, 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:6 by Jukka Rahkonen, 9 years ago

Is it right that this is a work in progress?

comment:7 by Even Rouault, 8 years ago

Milestone: 2.1.0
Resolution: fixed
Status: newclosed

RFC 60 has been merged into trunk

Note: See TracTickets for help on using tickets.