Eliminate redundant <coordinates> tags from <multipoint> child points

[prushforth]

The request from OGC Testbed 15 has been made to eliminate redundant child <coordinates> elements from the <multipoint> element schema, as they add no information yet add a lot of data overhead to the payload.

[jerstlouis]

To clarify, the request would be to support a single "coordinates" tag within the "multipoint" containing all the points within it.

[prushforth]

One problem with this proposal is that there would be a single DOM node for the <multipoint> <coordinates>, so individual points could not be addressed declaratively. If the individual points are marked up as <coordinates>, they would retain a DOM node existence, and be addressable with CSS selectors.

The choice to make <coordinates> a repeatable element reflects the design of GeoJSON, in which the coordinates member is an array of positions. So we made <coordinates> repeatable (as close to array as markup allows). The only place we were forced to deviate from that was in multipolygon, because the nesting of content is too deep, and so we have to have an intermediate <polygon> element to separate the repeatable coordinates elements.

You could argue that you could make <coordinates> a single node containing the many positions of the <multipoint> and when necessary wrap the individual points in <span> or other markup as we are hoping to do with position sequences in <polygon> boundaries and <linestring> segments.

The objective of MapML isn't to minimize content overhead, but is to enable DOM access to the Simple Features model where necessary. We think that when vector features are delivered in large volumes, there are better ways (like tiled vector data) to support that.

[jerstlouis]

The question is whether you want to create these extra nodes for multipoints, which are all coordinates of a single feature. If each of these points is meant to be uniquely styled / accessed, then they could still be multiple "point" features instead.

For the GeoJSON parallel, the MapML design does not map that clearly. The points on a linestring do not repeat "coordinates" in MapML, while in GeoJSON you still specify one coordinates array per point. Same for polygon where a single contour has a single "coordinates" in MapML, where in GeoJSON each coordinate would have separate arrays. So in MapML sometimes "coordinates" refers to a single point, sometimes it refers to a line string or contour, and this is somewhat confusing (especially if you try to map it directly to the GeoJSON data structures). The way I see it the geometry type that deviates from GeoJSON model is not multipolygon, it is multipoint.

So what I was proposing is to be self-consistent with this approach that a list of multiple coordinates for a single geometry type be part of a single "coordinates" tag (Multiple "coordinates" are of course still required for Polygon, MultiPolygon and MultiLineString).

[prushforth]

The way I see it the geometry type that deviates from GeoJSON model is not multipolygon, it is multipoint.

I see what you mean, I think.

Just to clarify my own understanding of the markup. A MultiPoint and LineString are similar in GeoJSON:

{
         "type": "MultiPoint",
         "coordinates": [
             [100.0, 0.0],
             [101.0, 1.0]
         ]
}

vs.

{
         "type": "LineString",
         "coordinates": [
             [100.0, 0.0],
             [101.0, 1.0]
         ]
}

whereas they are currently marked up differently in MapML:

<linestring>
    <coordinates>-75.705138 45.39178 -75.705238 45.39278 -75.705338 45.39378</coordinates>
</linestring>

vs.

<multipoint>
  <coordinates>-75.705138 45.39178</coordinates>
  <coordinates>-75.705238 45.39278</coordinates>
  <coordinates>-75.705338 45.39378</coordinates>
</multipoint>

in the proposal they would be made similar and hence more like GeoJSON:

<linestring>
    <coordinates>-75.705138 45.39178 -75.705238 45.39278 -75.705338 45.39378</coordinates>
</linestring>

vs.

<multipoint>
  <coordinates>-75.705138 45.39178 -75.705238 45.39278 -75.705338 45.39378</coordinates>
</multipoint>

Would appreciate some +1's or -1's with comments on this issue. I am ready to make the changes. I will add a checklist on what has to change if we go ahead.

[jerstlouis]

@prushforth correct. +1 from me :)

[prushforth]

• [x] notify the public list of pending changes
• [x] change the spec
• [x] update the schema
• [x] propagate schema changes to validator
• [x] update the mapml-leaflet-client
• [x] release new version of mapml-leaflet-client
• [x] update GeoServer

[prushforth]

Closing, hopefully everything works per ideas