Don't mind me, I'm just thinking out loud about the GeoJSON format.
A GeoJSON Feature Collection is an object with a "features" key and the value
for the key is specified to be an array of Feature objects. Is the order of
Features significant? In the context of my previous post,
should a zero or empty RFC 6902 diff between this
{ "type": "FeatureCollection",
"features": [
{ "type": "Feature",
"id": "foo",
... },
{ "type": "Feature",
"id": "bar",
... } ] }
and this, where the feature array has been reversed,
{ "type": "FeatureCollection",
"features": [
{ "type": "Feature",
"id": "bar",
... },
{ "type": "Feature",
"id": "foo",
... } ] }
be expected? Strictly speaking, no, because in JSON (see json.org or ECMA 404)
An array is an ordered collection of values.
whereas
An object is an unordered set of name/value pairs.
My question is related to one asked on the IETF's apps-discuss
list in
January. Should we expect to be able to patch GeoJSON documents using the ids
of individual features? Being able to do so is more or less the reason why
GeoJSON Features have unique ids, but it's clear to me that a generic RFC 6902
won't do. As James Snell points out in that thread, more expressive paths will
be required.
In my previous post on this topic (see link at the top of this one) I looked at
the addition of a new feature to the tail of the features array. The JSON patch
in this case was very simple. But what if that feature had been inserted at the
head of the features array? Is the resulting patch going to be something that
reads like "push back existing items and add new item to the head?" The result
from python-json-patch isn't pretty.
[
{
"path": "/features/0/geometry/coordinates/0",
"value": -122.65496134757996,
"op": "replace"
},
{
"path": "/features/0/geometry/coordinates/1",
"value": 45.5212590460849,
"op": "replace"
},
{
"path": "/features/0/properties/Notes",
"op": "remove"
},
{
"path": "/features/0/properties/Name",
"value": "Three Friends Coffeehouse",
"op": "replace"
},
{
"path": "/features/0/properties/Address",
"value": "201 SE 12th Ave, Portland, OR 97214",
"op": "replace"
},
{
"path": "/features/1/geometry/coordinates/0",
"value": -122.67516911029816,
"op": "replace"
},
{
"path": "/features/1/geometry/coordinates/1",
"value": 45.55673233031101,
"op": "replace"
},
{
"path": "/features/1/properties/Notes",
"value": "usually busy, outlets on side wall only",
"op": "replace"
},
{
"path": "/features/1/properties/Name",
"value": "Albina Press",
"op": "replace"
},
{
"path": "/features/1/properties/Address",
"value": "4637 N Albina Ave Portland, OR 97217",
"op": "replace"
},
{
"path": "/features/2",
"value": {
"geometry": {
"type": "Point",
"coordinates": [
-122.68242716789246,
45.56997505986905
]
},
"type": "Feature",
"properties": {
"Notes": "",
"Name": "Arbor Lodge",
"Address": "1507 N Rosa Parks Way Portland, OR 97217"
}
},
"op": "add"
}
]
Unless I misunderstand RFC 6901 and RFC 6902, the following ought to be
possible.
[
{ "op": "move", "from": "/foo/1", "path": "/foo/2" },
{ "op": "move", "from": "/foo/0", "path": "/foo/1" },
{ "path": "/features/0`",
"value": {
"geometry": {
"type": "Point",
"coordinates": [
-122.65496134757996,
45.5212590460849
]
},
"type": "Feature",
"properties": {
"Name": "Three Friends Coffeehouse",
"Address": "201 SE 12th Ave, Portland, OR 97214"
}
},
"op": "add" }
]
Making concise patches won't be trivial, that seems clear, and the ideal patch
style for GeoJSON could differ from the ideal style for other applications.
I'm certain that we'd need to get to patches like the latter to make GeoJSON
patching something that developers would consider adopting. JSON PATCH provides
a useful grammar but by itself isn't enough. There's more work to be done.
Did we ever consider making FeatureCollection's features key have an object
value? I'll look in the GeoJSON list archive when I have time.
