Opened 4 years ago

Closed 2 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

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 4 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 Changed 4 years ago by sgillies

Description: modified (diff)

comment:2 Changed 4 years ago by warmerdam

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

Changed 4 years ago by sgillies

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 Changed 4 years ago by sgillies

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 Changed 4 years ago by sgillies

Keywords: geojson annotation added

comment:5 Changed 4 years ago by sgillies

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 ( 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 Changed 3 years ago by Jukka Rahkonen

Is it right that this is a work in progress?

comment:7 Changed 2 years ago by Even Rouault

Milestone: 2.1.0
Resolution: fixed
Status: newclosed

RFC 60 has been merged into trunk

Note: See TracTickets for help on using tickets.