Evaluate of how to handle the id column

[mactrem]

• Allow any data type (currently only UInt64)?
• No dedicated id column in a tile, instead part of the properties?

[nyurik]

Are you talking about Tile ID or Feature ID? If feature ID, than having no dedicated ID in a tile would significantly affect MapLibre - there are a lot of APIs that assume that each feature has a conceptual ID. But for the referencing tile itself, than yes - any way of addressing a tile you may like would work i guess?

[mactrem]

No, i'm talking about the feature ID, since also in the current MVT spec the ID is optional have a look at the proto file. Currently i use the approach to have a dedicated id column with a fixed UInt64 datatype. The advantage is that in most cases the id column can be very efficent RLE/Varint encoded see https://github.com/mactrem/cov-tiles#id-compression. However, there seems to be a need for generic data types, as pointed out for example in this interesting discussion in the MVT repo or also Overture is using string IDs.
I understand your point that the lack of a dedicated ID column causes problems in the current MapLibre ecosystem. So i'm tending toward the usage of a dedicated optional ID column but with a variable data type, with the recommendation to use UInt64/Int64 for size and performance reasons. @nyurik what do you think?

[msbarry]

FWIW I tried mapping overture string IDs to 64-bit longs using an fnv1a hash and there are no collisions for now at least.