Hi, I also use umap which requires me to sign into OSM before starting. I have noticed that some roads are disappearing doesn’t matter what zoom function i use and the cache and cookies are clear. Also tried restarting the computer . Does anyone know what the problem is and how to fix it

Isn’t obvious question - are they still in OSM?

Which uMap instance exactly are you using, and which background tiles?

(It is apparently not the standard layer as that doesn’t display names in the Latin alphabet here. I see a reference to openstreetmap.de in the attribution).

1 Like

Looking at this a bit further, it seems to be specific to tiles from the German Map Style (not particularly related to uMap).

It doesn’t appear there have been any recent changes to the map data that would cause this.

The only difference I can see between rendered and non-rendered sections of the highway EO90 is that the missing sections don’t have a maxspeed tag. Maybe this style relies on maxspeed for some rendering decisions? (That’s pure speculation though, I don’t know anything about this style, and I haven’t looked for similar missing roads in other locations).

1 Like

There’s a subtle bug hiding in the German Map Style Lua script, which your uMap instance uses as its default tilelayer.

The script walks through every tag on an OSM object and rewrites certain tag values using a generated localized name string (gen_110n_name). If an object has tags like ref, source, name, and highway, the script touches each of them in sequence, and whenever a tag requires localization, the script updates the Lua table that stores all tags.

That’s where the problem starts.

OSM tags inside the script live in a Lua table indexed by strings, so ordering depends on the table’s internal hash layout rather than numeric keys. Lua’s hash table can reshuffle entries whenever it grows during a hash-slot-shortage situation. When the script updates a tag mid-iteration, the underlying table may rehash itself, altering the traversal order.

Imagine the table initially hashes as: ref → source → name → highway. The script processes ref, then source, then reaches name. Updating the name forces the table to grow (My guess is that, in this name-localization context, the table grows when a new name:country_code tag is added), and if (by some bad luck) there are no free hash slots left, Lua rehashes the keys into a new order, for example: source → highway → name → ref. The loop then continues from where it left off (name → ref), landing on ref again while skipping highway entirely. Result: the ref tag is processed twice and highway vanishes from the final render.

Whether this happens depends on hash capacity. Lua sizes the hash portion in powers of two (1, 2, 4, 8, 16, 32, …). If an object has five tags, Lua picks the next power of two (8) leaving three empty slots. Objects with long tag lists usually get large tables with plenty of spare slots, so they rarely trigger a rehash. Small objects get tiny tables with only a couple of free slots, making them much more likely to hit this edge case.

TLDR : German Map Style’s Lua script has a bug in how it handles tag iteration on mutable Lua tables. Switching your uMap tilelayer to any other style probably avoids the issue entirely.

2 Likes

is it reported already on their issue tracker?

I just filed it.

3 Likes

thank you very much-done