Render addr:flats

[richlv]

Would be great to render addr:flats. This would be useful for: a) Navigation, especially with longer buildings: https://www.openstreetmap.org/#map=18/56.89848/24.08783 . b) Advertising OSM and Organic Maps. c) Finding out what detail should be collected for additional mapping.

A couple additional locations that could be used for testing: https://www.openstreetmap.org/#map=19/56.98855/24.22514 https://www.openstreetmap.org/#map=18/56.98722/24.24143

[biodranik]

How do you think it should be rendered to avoid cluttering?

[richlv]

Perhaps at a bit lower zoomlevel than housenumbers, and, if possible, losing in collision detection to housenumbers? Don't know much of the technical detail, but maybe something similar to bench and entrance rendering is possible (they show up later than housenumbers already).

[pastk]

We have a rule for addr:flats rendering but its not working somehow

node|z19-[entrance]::flats
{text: "addr:flats";font-size: 12;text-offset-y: 10;}

[pastk]

I tried changing z-index, applying priority hacks, removing all other labels etc. by I couldn't get the flats displayed. The data is there definitely as its displayed in PP, but it couldn't be used in styles for some reason.

At the same time a ref=* tag from the same entrance node is displayed even if I remove it from the drawing rules! I guess this is because ref falls through into name which has some hardcoded priority?

entrance;[entrance];;ref;addr:flats;882;

A sample node with both addr:flats and ref: https://www.openstreetmap.org/node/3008659645

@vng could you help here please?

[richlv]

Checking the latest version, addr:flats still not showing up - as @pastk said it is supposed to render, anybody with an idea what's wrong?

[vng]

addr:flats rule exists, but is never exposed and needs additional processing in core.

[richlv]

Is this processing a notable amount of code? As a non-coder, I can only find some places with addr:flats, often referenced together with "entrance" :)

[richlv]

Entrances are now rendered with a dedicated icon - could it mean that rendering addr:flats is closer? :)

[biodranik]

@richlv aren't addr:flats values already rendered?

[richlv]

Nope, checking after every update. OM 2023.01.24-5 with latest data does not render them. Tapping on an entrance does show flat range, but that's not quite there yet :)

[biodranik]

They are already visible when an entrance is selected, right? Isn't it enough? Navigation can take it into an account also without rendering on the main map.

[richlv]

Not quite - it's very hard to discover, and one cannot even tell whether the entrance has flat ranges mapped or not without manually opening every single one. This makes it less likely that users will find out about the map containing this information. Similarly, for mappers, it is unfeasible to check nearby entrances to see which ones might need surveying. The best would be rendering them as with openstreetmap-carto and JOSM.

[biodranik]

@pastk can we render addr:flats only on zoom 20?

[richlv]

Heya, not sure how could I see zoomlevels in the app, but these numbers seem to be at least as important as the entrance icons themselves.

[pastk]

@pastk can we render addr:flats only on zoom 20?

I was thinking of z19- (entrances are z19- also, except main ones which are z18-). I didn't see any place where flat numbers are mapped so tightly as to create cluttering issues.

[bdosorio]

For similiar coordinates (56.89861° N, 24.08767° E) OsmAnd matches similarly to openstreetmap.org rendering. OsmAnd OSM.org in Firefox OM

[pastk]

Following "duplicate" address nodes all have different flats ranges:

Check https://www.openstreetmap.org/node/8399611658

So it'll look much less confusing and much more useful if we add flats ranges to the render.

[pastk]

And addr:unit here: https://www.openstreetmap.org/node/8796908919