[BUG] MVT ids are not according to OMT schema

[zbycz]

Describe the bug
There is an issue with type encoded in the id field in the MVT tiles. The last number in the id should encode 0=node, 1=way and 4=relation, which is the schema used in Maptiler production and afaik in OMT as well.

@hyperknot noted (issue on OpenFreeMap), that this could be a simple change, as this number is already configurable. So, would you mind changing the default value for the switch from 123 to 124? (via #1042)

To Reproduce
I am not sure how to run or test planetiler. But here is how to test the issue in OsmAPP - it is possible to click many features both on Maptiler and on OpenFreeMap and compare the numbers in browser console: hyperknot/openfreemap#44

Also, note that inconsistent encoding of ids was a more common issue in OMT/Maptiler, more relevant links in the same OFR issue.

Expected behavior
All osm elements have ID like <id><typeId> where typeId is 0=node, 1=way and 4=relation. We use this scheme in OsmAPP.org to make all the features clickable -> zbycz/osmapp#771.

Maybe we could make it even better, and add another typeId=9 for data not coming from OSM. This would help tremendously to make the map more clickable. 🙂 I could create a new issue for that after we fix this "bug".

[msbarry]

Currently planetiler encodes them as node=1, way=2, relation=3, and any other source=0 based on the discussion in #824. 0/1/4 seems like a strange convention, is it documented anywhere? @phanecak-maptiler any idea why they use that instead of 1/2/3?

[phanecak-maptiler]

It is coming from OpenMapTiles: It looks like it was a workaround/solution for the problem of "we need unique and persistent feature IDs", see openmaptiles/openmaptiles#303 , which links to openmaptiles/openmaptiles#378 .

The ability to "guess" the OSM feature type from such IDs is then IMHO sort of "unexpected side-effect" or "undocumented feature". With MapTiler using OpenMapTiles in their portfolio, this behavior is present also in MapTiler's tilesets. And some people/projects later started to rely on such feature, see for example openmaptiles/openmaptiles#1587 (also filled by @zbycz ). Since at MapTiler we do not want to break stuff which works for existing customers, we are sticking with osm_id * 10 and ...+1 for way and ...+4 for relation.

I did follow the discussion about "1/2/3" and some other proposals (see for example openmaptiles/planetiler-openmaptiles#157 ), but since "0/1/4" ID hack was AFAIK not documented in OpenMapTiles as "official feature", I did not have a strong argument either for "0/1/4" or against "1/2/3". (And thus openmaptiles/planetiler-openmaptiles#157 remains unresolved.)

I have only info from git repo digging, since this greatly predates my involvement with OpenMapTiles and also the involvement of colleagues of mine.