systemed / tilemaker

Make OpenStreetMap vector tiles without the stack
https://tilemaker.org/
Other
1.43k stars 228 forks source link

Cross-Platform Inconsistency in Attribute Handling with Identical Configs on Ubuntu and macOS #731

Open pa5cal opened 2 months ago

pa5cal commented 2 months ago

I have been using tilemaker v3 on a Mac Mini since February without any issues. Recently, I set up the same version on a new machine running Ubuntu 24.04 LTS, using identical Lua and configuration files. However, I'm encountering discrepancies in the attribute behavior of features within the vector tiles.

The intended functionality, verified on my Mac, is for the following code snippet to add attributes only if they exist:

-- Roads ('transportation')
if highway ~= "" then
    -- Write to layer
    Layer("transportation", false)
    Attribute("tag:highway", highway)
    Attribute("tag:oneway", Find("oneway"))
    Attribute("tag:surface", Find("surface"))
    Attribute("tag:access", Find("access"))
    Attribute("tag:bicycle", Find("bicycle"))
    Attribute("tag:foot", Find("foot"))
    Attribute("tag:mtb_scale", Find("mtb:scale"))
    SetBrunnelAttributes()
    SetNameAttributes()
end

On the Ubuntu system, an example feature looks like this:

1251211961 {tag:bicycle=, tag:mtb_scale=, tag:oneway=, tag:surface=, tag:foot=, name=, tag:access=, tag:highway=residential}

Whereas on my Mac, the output for the same feature is more succinct and as expected:

1251211961 {tag:highway=residential}

Any suggestions or corrections are highly appreciated, especially if I have misunderstood something.

systemed commented 2 months ago

This changed in #676 - previously it was undocumented behaviour. An attribute value being the empty string is legitimate in an MVT and so we should really support it.

I do wonder though whether we should maybe introduce FindOrNull, which would return null rather than the empty string for non-existing OSM tags.

pa5cal commented 2 months ago

First of all, and because I forgot to mention this in my previous post: Many thanks to you for this software!

Also many thanks for the quick reply. First of all, I'm glad to read that it's an expected behaviour, even if it requires adjustments on my side now.

Yes, for me the mentioned solution with FindOrNull would be fine.

Thanks & best regards Pascal

pa5cal commented 2 months ago

What I forgot to mention: Is it also possible that the handling of individual POIs with identical attributes has been adjusted?

In other words, were there previously 4 POIs with identical attributes in a vector tile, for example, is there now only a single multipoint with the attributes?

systemed commented 2 months ago

Yes, that's the case (#725). Would it be useful to be able to disable that?

pa5cal commented 2 months ago

Ah, also very good to know.

As you may have noticed, I use the vector tiles from your Tilemaker for my OSM QA processes. In combination with the OSM Id for each feature in the vector tile, it would probably be important to be able to disable this currently.

Because assuming I understand it correctly, would only one ID be saved at the mutlipoint?

systemed commented 2 months ago

Yes, I believe that's the case.

If you want to disable this temporarily, these lines (288-293) in tile_worker.cpp are the ones to comment out:

while (jt<(ooSameLayerEnd-1) && oo.oo.compatible((jt+1)->oo)) {
    jt++;
    LatpLon pos = source->buildNodeGeometry(jt->oo.objectID, bbox);
    pair<int,int> xy = bbox.scaleLatpLon(pos.latp/10000000.0, pos.lon/10000000.0);
    multipoint.push_back(xy);
}