Finding out the OSM element type of a feature - node/way/relation

[zstadler]

I would like to be able to identify the OSM element of the features received by queryRenderedFeatures. I understand that the feature id captures the OSM id, for OSM-based features, but that id may belong to a node, a way, or a relation.

For example, the origin of features of the "poi" layer in planetiler-openmaptiles could be nodes, ways, or relations.

Is there a way to know the OSM element type, or add it to the tile data?

[msbarry]

This could either be a profile decision or default planetiler decision...

Planetiler makes the feature ID inherit the osm element ID here to ensure the output remains the same for the same input:

planetiler/planetiler-core/src/main/java/com/onthegomap/planetiler/reader/osm/OsmReader.java

Line 638 in 40e64a2

super(elem.tags(), name, null, relationInfo, elem.id());

But profiles like protomaps basemap sets the ID explicitly to also encode whether its a node/way relation:

https://github.com/protomaps/basemaps/blob/9df3dfc64a9f880b7b3b40a0cf80f3489c2d9851/tiles/src/main/java/com/protomaps/basemap/feature/FeatureId.java#L11-L24

https://github.com/protomaps/basemaps/blob/9df3dfc64a9f880b7b3b40a0cf80f3489c2d9851/tiles/src/main/java/com/protomaps/basemap/layers/PhysicalLine.java#L34-L35

So we could change the default planetiler behavior to be more like protomaps (although I'd probably only shift the ID left by 2 bits to save space on varint encoding) or change planetiler-openmaptiles to do something like what protomaps basemap does.

WDYT?

[phanecak-maptiler]

OpenMapTiles is also doing some "hacks" on ID presumably to help distinguish whether the original OSM element is point or polygon:

• https://github.com/openmaptiles/openmaptiles/blob/master/layers/poi/poi.sql#L62
• https://github.com/openmaptiles/openmaptiles/blob/master/layers/poi/poi.sql#L75

But see then also openmaptiles/openmaptiles#1587 since it raises question how "serious" and "maintainable" such feature then could be. E.g. IMHO "yes, sure, can be done; but are we both able and willing to adhere to such API contract in the long term?"

I do not oppose such change, but I do not like it very much.

[zstadler]

But see then also openmaptiles/openmaptiles#1587 since it raises question how "serious" and "maintainable" such feature then could be. E.g. IMHO "yes, sure, can be done; but are we both able and willing to adhere to such API contract in the long term?"

Unfortunately, OMT is not consistent with the approach used in their poi layer. Some layers do not carry any feature id, and some multiple all OSM ids by 10, regardless of their OSM type.

It looks like in Planetiler it is possible to implement this without the need for duplicating the code, and potentially making mistakes, in each layer.

[phanecak-maptiler]

It looks like in Planetiler it is possible to implement this without the need for duplicating the code, and potentially making mistakes, in each layer.

IMHO, yes, it could (and should) be. See for example:

• OpenMapTiles change: openmaptiles/openmaptiles@4d54628
• planetiler-openmaptiles change: openmaptiles/planetiler-openmaptiles@6634955

[zstadler]

I like this direction. As @phanecak-maptiler wrote, a similar approach is taken by some of the original OpenMapTiles layers.

For example, in their poi layer, the OSM ids of nodes are multiplied by 10
https://github.com/openmaptiles/openmaptiles/blob/9f891b625aabc009f0df7d3e14d7d4052c26204f/layers/poi/poi.sql#L62

                osm_id * 10 AS osm_id_hash

OSM ids of ways are multiplied by 10 and added 1, and OSM ids of relations (received as negative numbers from imposm) are multiplied by 1 and added 4
https://github.com/openmaptiles/openmaptiles/blob/9f891b625aabc009f0df7d3e14d7d4052c26204f/layers/poi/poi.sql#L74-L77

                CASE
                    WHEN osm_id < 0 THEN -osm_id * 10 + 4
                    ELSE osm_id * 10 + 1
                    END AS osm_id_hash

I think that the base-10 approach is a bit more human friendly, and the decomposition can be done easily using division and modulo 10. That's even possible using Maplibre style spec expressions:

  [
    "match",
    ["%", ["id"], 10],
    0,
    "OSM node ",
    1,
    "OSM way",
    4,
    "OSM relation",
    "id "
  ],
  ["/", ["id"], 10]

could show something like

[msbarry]

Sounds good to me, implemented the osm_id * 10 + {1 for node, 2 for way, 3 for relation} approach in #826

It looks like that increases tile size a bit (~1%) by making the varint encoding less effective. We can make the difference negligible if we did osm_id * 3 + {0 for node, 1 for way, 2 for relation} instead

see #827 (comment) (*3)
vs #826 (comment) (*10)

[zstadler]

Thanks!
How significant is the 1% increase?

While debugging this experiment I found the * 10 approach very handy. It allows copying the Feature ID from Maputnik, deleting the last digit and using that in openstreetmap.org