GeoJSON object equality

Question

I've searched both the 2008 spec and RFC7946 and can't find anything about when two GeoJSON objects would be considered equal. I wonder if anyone can enlighten me?

It seems to me the options are:

1. Two GeoJSON objects that contain the same geometry are never equal, and are both distinctly unique features.

2. Two GeoJSON objects are equivalent if their geometry coordinates are exactly equal, irrespective of their geometry type.

3. Two GeoJSON objects are equivalent only if their geometry - both coordinates and type are exactly equal.

Option 1 poses questions on handling assertions about the same geometry from multiple sources, as well as uniquely identifying them.

Option 2 poses questions regarding handling multiple geometry type declarations, which effectively becomes a multi-valued property

Option 3 poses questions about a GeometryCollection asserting multiple geometries that contain the same coordinates but different types

The GeoJSON-LD proposals appears to suggest a combination of all three options are possible via @id, which means equality is outside of the RFC spec and not defined without an external property.

I have been encoding all my geometries as unique base64 data:urls with the polyline algorithm which works well, and have allowed geometry type to be multi-valued and merged all other properties.

My thinking is both the properties object and any foreign members are explicitly outside of the spec so can be safely merged, though I'm not sure how correct the semantics of that are.

Example below:

[{
    "type": "Feature",
    "geometry": {
        "type": "LineString",
        "coordinates": [[123,456],[456,789],[789,012],[012,234]]
    }
    "properties": {
        "name": "Bob",
    },
},
    "type": "Feature",
    "geometry": {
        "type": "LineString",
        "coordinates": [[123,456],[456,789],[789,012],[012,234]]
    }
    "properties": {
        "name": "Jane",
    },
},
    "type": "Feature",
    "geometry": {
        "type": "MultiPoint",
        "coordinates": [[123,456],[456,789],[789,012],[012,234]]
    }
    "properties": {
        "name": "Fred",
    },
},
    "type": "GeometryCollection",
    "geometries" : {
        {
            "type": "Polygon",
            "coordinates": [[123,456],[456,789],[789,012],[012,234]]
        },
        {
            "type": "MultiPoint",
            "coordinates": [[123,456],[456,789],[789,012],[012,234]]
        }
    }
    "properties": {
        "name": "Mary",
    },
}]

I don't have the rep to add tags for JSON-LD or GeoJSON-LD, perhaps someone else could for me.

Answer 1

I am not sure if there can be any universally correct answer.

1. Feels unreasonable because if you read the same data from the same service two times I really feel that you get duplicates.
2. Could be reasonable sometimes, because point (0 0) can be expressed as Point, MultiPoint, or GeometryCollection. Saying that a MultiPoint and Polygon are the same, I would say no. And if you want to send updates to the remote service the wrong types will probably lead to an error always.
3. Feels most right for me

Most common case for 2) are for sure polygons/multipolygons and it might be worth considering that they are the same.

BTW. polygons in your example are invalid, they are not closed.

Answer 2

I agree, after much navel gazing I have come to the conclusion that Option 3 and always is the only sane answer.

My logic was that after considering the GeometryCollection I realised the collection is making a statement about the collection of geometries it contains, not about the individual geometry elements, the statements are only valid in that context.

In the same vein, a feature makes statements about a geometry not a set of coordinates. The geometry type gives the coordinates context for those statements.

This makes sense as there is no reason to believe that a property about a LineString geometry should apply to MultiPoint geometry with identical coordinates because their geometry context is different.

It's a shame the geo: URI scheme can't be extended to support the concept of polylines, so I'm stuck with hacking the data scheme to encode the coordinates with a ridiculously long media-type + parameter, to give me a unique geometry URI:

data:application/geo+json;geo=ls,mkmyHhg`@wiAyiKldA{jEf_D`{@b{@dmF??