[FR] Keep track of geometry parts when tiled

[AbelVM]

Why

As of today, using MVT, when a geometry overlays several tiles, it gets split into pieces, one per tile. Client-side, the visual effect is nowhere to be found as

It does that by rendering the polygon larger than the tile size and then clipping it, 
so it's not really merging but more of drawing side by side.

But, if any feature extends across several tiles:

• Labels: there would be a label per feature portion

• queryRenderedFeatures and querySourceFeatures both return not features, but features' parts, so you need to postprocess the results to get the right features count

Because features come from tiled vector data or GeoJSON data that is converted to tiles internally, 
feature geometries may be split or duplicated across tile boundaries and, as a result, features may 
appear multiple times in query results. For example, suppose there is a highway running through 
the bounding rectangle of a query. The results of the query will be those parts of the highway that 
lie within the map tiles covering the bounding rectangle, even if the highway extends into other tiles, 
and the portion of the highway within each map tile will be returned as a separate feature. Similarly, 
a point feature near a tile boundary may appear in multiple tiles due to tile buffering.

• Export: there is no way to retrieve the data in the viewport for a given layer, as the features' geometries make no sense without further processing

Proposal

• Store a geometry ID per feature's geometry, to take into account multigeometry features, just the ordinal of the geometry in the original feature
• Store a vertex ID per geometry's vertex, just the ordinal of the vertex in the original geometry
  • outer rings and lines: vertex_id >0
  • inner rings: vertex_id < 0. TBD, but it would be like -1000000 * hole_ordinal - vertex_ordinal (so we can take into account several holes)
  • "synthetic" vertices generated at feature-tile intersection: vertex_id = 0 (so they can be discarded later)

This way, the original geometries can be rebuilt later (at current LoD, indeed)

[HarelM]

Can you clarify how this is related to the style spec? What should a user set in the style to achieve this?
Also how should maplibre know two polygons that were generated through some tile processing tool that do not have any id associated with them belong to the same object? These heuristics should be handled by the relevant client code that would make the relevant assumptions, IMHO.

[AbelVM]

Hmmm, this is the maplibre-tile-spec repository, not style-spec 😅

I'm proposing that MLT fixes this classic MVT issue

[HarelM]

Oh sh@t, my bad...

[AbelVM]

Proposal 0.2

• feature id (already there)
  • geometry id (to take into account multigeometries)
    • ring id (0 for outer ring and line geometries)
      • vertex id

IDs are just the ordinals of the source feature elements. This is somehow a replica of GeoJSON specification, but using ordinals instead of values

[tordans]

Just a quick +1: It would be great if we did not have to generate a separate label layer for all kinds of line and area data whenever we only want one label (eg. for capacities). Especially given that the renderer can be smarter about moving the label (but just one) along a line/area which we cannot do with a fixed single label along the line/in the area.