Associate properties with a particular geometry

[aznan2]

While GeoJSON doesn't disallow geometries to be placed in a Feature's "properties" property, the Feature's main geometry must be placed in the "geometry" property. Any other geometries are mostly ignored by readers. Often, this constraint is too restrictive: a single real world object may consist of several different geometries, none of which is a "main" geometry, and each with its own set of information tied to it.

This is one possible way to go about it:

Apart from a geometry object or null, a Feature's "where" property may instead be an array of geometry references. A geometry reference takes the form of a JSON Pointer which points to a geometry placed somewhere else in the Feature object. As JSON Pointers always start at the document root, moving a Feature into a FeatureCollection necessitates updating all its geometry references. To prevent this, a Relative JSON Pointer may be used instead.

Example - Click to expand

A real property that consists of two areas. One area is a normal land area and the other is an area on water, represented by lines following a stream. The stream has a fork in it, with each fork's geometry collected at a different time, with different precision.

{
  "type": "Feature",
  "id": "b66a6e18-d6cc-48ee-80ee-f93d6406392c",
  "geometry": null,
  "where": [
    "1/properties/areas/0/geometries/0/position",
    "1/properties/areas/1/geometries/0/position",
    "1/properties/areas/1/geometries/1/position"
  ],
  "properties": {
    "realPropertyName": "Fiskefastigheten 1:1",
    "areas": [
      {
        "type": "land area",
        "livableArea": 89.5,
        "geometries": [
          {
            "position": {
              "type": "Polygon",
              "coordinates": [
                [
                  [100, 100],
                  [100, 200],
                  [200, 200],
                  [200, 100],
                  [100, 100]
                ]
              ]
            },
            "timeOfCollection": "2021-11-23T15:19:43.123Z",
            "positionAccuracy": 0.1
          }
        ]
      },
      {
        "type": "water area",
        "livableArea": 0,
        "geometries": [
          {
            "position": {
              "type": "LineString",
              "coordinates": [
                [100, 300],
                [100, 400]
              ]
            },
            "timeOfCollection": "2021-11-23T17:01:33.123Z",
            "positionAccuracy": 0.1
          },
          {
            "position": {
              "type": "LineString",
              "coordinates": [
                [100, 350],
                [150, 400]
              ]
            },
            "timeOfCollection": "2003-05-06T12:13:51.123Z",
            "positionAccuracy": 0.25
          }
        ]
      }
    ]
  }
}

Better than nothing, but that approach does not solve for cases where information should be associated with part of a geometry - for instance, data related to a single wall of a building polyhedron or where you want accuracy metadata for each point of a polygon. In that case, it may be better to keep the geometries in the "where" property and reference them from the properties instead.

I would love to hear thoughts and ideas about this.

[cportele]

Thank you for the suggestion. I also work with some datasets where features have more than one geometry property. That said, so far the decision was to focus in the first version of JSON-FG on the most common situation - one geometry per feature. Or if there are multiple geometry properties, one is the primary/main geometry and others can be put in the properties object. I still think that this is the right scope for the first version/part of JSON-FG and if there is enough demand for such a capability, it should be a future extension.

In addition, for datasets for which multiple geometry properties are the standard case, there may already be specialized JSON encodings. For example, CityJSON for 3D building/city models.

A concern with the technical details is that I have not seen many uses of Relative JSON Pointers yet or support in implementations. But that may be because I have not (yet) looked closely enough and testing could clarify how easy it is to implement.

It would be good to get other views on this.

[pvretano]

I agree with @cportele, the primary case is for features with a single primary geometry and all other geometries put into the "properties" section. The GeoJSON/JSON-FG specifications defines how to specify the primary geometry (i.e. geometry/where) but geometries in the "properties" section are out-of-scope. That is to say that the specifications do not describe how to include other geometries in the properties section ... although neither GeoJSON nor JSON-FG preclude it.

As for when we do get around to supporting multiple geometries, I would leave the "geometry"/"where" key(s) as defined -- in other words the data creator needs to designate a primary geometry that is the values of the "geometry" key or the "where" key (or both according to the rules of JSON-FG) -- and then add a new top-level element like "geometries" to be able to include multiple geometries. My first thought was to make the "geometries" element an object where each key in the object identifies each geometry but on further reflection, I think I like @aznan2 approach of relative pointers into the properties section; this allows the multiple geometries to be organized in whatever way makes sense for the data creator or use case at hand but still allows the geometries to be easy identified from the top-level geometries array.

[cportele]

Meeting 2022-01-22: For Part 1 we stick to a primary geometry and primary time information. This would be a future extension (using an additional member).