Decoder discards additional co-ordinates

[lukeredpath]

Given the Point:

{
    "type": "Point",
    "coordinates": [102.0, 0.0, 0.0, "2011-03-29T08:38:50Z", 3.54, 39.80]
}

Where indices 0, 1, and 2 represent x, y and z co-ordinates and indices 3, 4 and 5 represent custom metadata about a point (in this case, timestamp, speed and bearing), rgeo-geojson discards the additional elements of the co-ordinates array. This is not expected behaviour.

According to the GeoJSON spec, additional elements are perfectly acceptable (emphasis mine):

A position is represented by an array of numbers. There must be at least two elements, and may be more. The order of elements must follow x, y, z order (easting, northing, altitude for coordinates in a projected coordinate reference system, or longitude, latitude, altitude for coordinates in a geographic coordinate reference system). Any number of additional elements are allowed -- interpretation and meaning of additional elements is beyond the scope of this specification.

[lukeredpath]

There is an obvious conflict here in that the OGC spec only allows for x, y, z and m values for a point whereas the GeoJSON spec allows for extra values. Some thought is needed here.

[lukeredpath]

Please see my fix for this in the above commit, and also in my rgeo fork.

[dazuma]

I admit I haven't followed the GeoJSON spec development all that closely, but the language of the spec suggests that the allowing of "additional elements" is simply a hedge for flexibility and future extension-- especially since the spec currently officially punts on the meaning of such elements. It requires that conforming parsers allow such extra elements, but does not specify how or even whether conforming parsers should interpret them. The RGeo data structures are intended to follow the OGC spec as closely as possible, and I'm rather loath to add an extra catch-all array to the RGeo core just because of open-endedness in the GeoJSON spec.

My take is that metadata is more properly modeled as properties in a GeoJSON "Feature" object. For example:

{
  "type": "Feature",
  "geometry": {
    "type": "Point",
    "coordinates": [102.0, 0.0, 0.0]
  },
  "properties": {
    "timestamp": "2011-03-29T08:38:50Z",
    "speed": 3.54,
    "bearing": 39.80
  }
}

Such a format is much more expressive anyway, and probably will make life easier for you as you share data and interact with other GeoJSON parsers.

[lukeredpath]

Whilst I agree that using properties is more expressive, it's not very concise. When dealing with large numbers of points (thousands), the size of the JSON payload increases significantly compared to a simple MultiPoint with extra elements, so I would ask you to reconsider, given that the change is backwards-compatible.

[dazuma]

Hi Luke,

Okay, let me think about this for a little bit. The hesitation on my part here is not the GeoJSON side. We can definitely put something in to interpret extra coordinate dimensions in some way. The real issue is the adding of data to the RGeo core that is beyond the OGC spec. That causes some problems. For example, what should happen to that extra data as we clone, manipulate, or especially perform operations on those geo objects? Or take the RGeo objects that are based on (and are basically wrappers around) GEOS objects. GEOS knows nothing about extra coordinate dimensions, and so such information will get lost when those objects get pushed through GEOS operations.

So your RGeo patch as submitted is incomplete for several reasons. It won't work for GEOS-based RGeo objects (and indeed, if you run the test suite with GEOS installed, the test case that you added will fail for the GEOS implementations). And, it results in unexpected behavior: say you create a Point with extra coordinates, and then you add that point to a MultiPoint. The extra coordinates won't transfer over.

It may instead make sense to handle this completely at the RGeo::GeoJSON level, finding a separate outlet to emit the metadata rather than trying to graft it directly onto the RGeo objects.

One more thing. I thought it would be a good idea to get some clarification on the intent of use and interpretation of "extra" coordinate dimensions, so I asked on the GeoJSON mailing list about it. You can take a look at the list archives to check in on that discussion, or feel free to subscribe and jump in if you so desire.

[teeparham]

Closing as stale / will not fix. Use properties if you have additional coordinate information. Use m and z if you have those.