Colour separation of buildings with/without addresses

[Maschga]

Hi!

Use case
I want to add to every building in my village an address. However, this is quite difficult as every building is displayed in the same colour, regardless of whether it has already been assigned an address when using this address-feature (see the image below):

So I have to zoom to every building and look whether it has already an address.

Proposed Solution
I suggest a colour scheme like it is used when displaying the foot walks:

• Building has an address: blue or green
• The user specified that the building has no address: black
• Building has no address: red

Thank you very much for this great app!
~Maschga

[mnalis]

Makes sense to me; not only would it be useful, but that is how most other Overlays behave (show in red missing data), e.g. Buildings Overlay...

• related discussion: Coloring for address overlay #5422 (I think there might have been another discussion/issue too, but am unable to find it, if it did exist)

[riQQ]

Related

• Address heatmap when zooming out in Address overlay #5452

[tommycrock]

I think this would be great. At the moment the main use I have for the address overlay is to temporarily hide the address quests so I can add building levels to an unaddressed building.

To add some details to the behaviour, it should basically follow the same rules as the address quests, which I think are to only show certain types of building as missing an address and to treat as completed ones with an addressed entrance node.

Perhaps different colours could be used for buildings with address on node rather than whole building, as well as other suggestions I made in the discussion linked by @mnalis.

[Maschga]

I couldy try to make a pr for this.
It is very similar to the buildings-layer.

[matkoniecz]

Main problem is handling of address nodes - which is also valid methods, often necessary one

[Maschga]

Why is that a problem? Can't such a node be automatically assigned to the building on which the node is located?

[westnordost]

Short answer: No, and that is why I am closing it as a will not fix. Sorry.

Long answer:
1.
Not just like that. There is no logical relation between the two, other than that the node is geographically located within the building or on the building outline.

This kind of geospatial analysis is done for the creation of the address quest: The quest is not created for buildings that contain an address node or that have an address node on their outline (among other things).
But for quests, this is done once, and in the background during download. For the overlay, it would need to be done on-the-fly for whatever data is currently in view. Each edit does trigger this anew.

Note also that nodes within building outlines are not the only thing that would make it OK for buildings to have no address assigned to it. The area around it may already be tagged with an address. (E.g. the whole property of a school is tagged with an address, rather than the individual buildings.)
There are even more things to consider. See the source code for the ´AddHousenumber.kt´ quest.

Even if the performance was no issue, the other show stopper is the following: When displaying an area in the overlay, there will be some buildings on the outer border of the displayed area. Such buildings are only partly within the to-be-displayed area. These buildings will still be in the displayed data in their entirety. However, there may be address nodes that are inside the building but outside the displayed area. When these nodes are outside the displayed area, they are not in the data that would be analyzed for which buildings contain address nodes.
In short, there'll always be buildings at the border of the displayed area that are displayed in red, even if they might have an address node within their outline. It would lead to interesting (flickering) effects when scrolling past these buildings. Buildings at the edge of the downloaded area will always have this issue.
This would 100% appear like a bug to users. (Because it kind of is....!)

Many buildings legit just don't have an address. Garages, sheds, roofs, some nondescript industrial building on factory grounds, etc.
If they were displayed in red, there should be a some possibility for the user to make the red go away. For the quests, this is no issue: The housenumber quest is only created for building types that usually have housenumbers and the user has the option to answer that the place has no housenumber because the building type was tagged wrongly.
Most importantly, the quest is not displayed for ´building=yes´. Now, if the overlay didn't mark buildings with ´building=yes´ with missing addresses in red, it would make the coloring somewhat moot because the majority of buildings are tagged like that.

[matkoniecz]

ad 4) these non-adressable buildings could be shown in gray

but 1, 2,, 3 remain without good answer

[Maschga]

Thank you very much for this detailed answer!

[HolgerJeromin]

What about:

• Buildings/ways with address: green
• Buildings/ways without address: grey no highlight
• Address nodes: quite big green circle (3 meter radius?)

So with the density of green area you can guess if there is something missing.

[tommycrock]

So I think you're suggesting only highlighting presence of address tags and not their absence, whether on nodes or ways. That would still be a big benefit for visualising the current state of mapping compared to no highlighting. It sounds like it would deal with all of the problems 1-4 also?

[westnordost]

That big circle is not really possible, unfortunately. It could only be a small circle, the size of e.g. the building icons in the building overlay, which would also not be displayed if too close to other such small circles and it would make the actual housenumber label display below this "icon".
So with these caveats, I am not sure if it would still be a positive impact?

[tommycrock]

At the moment the places overlay has the icon with label offset to the right. Would that not be possible? Hiding when there's too many is kind of expected I think (and consistent with places).

[westnordost]

What would not be possible?

[tommycrock]

I may have misunderstood. I thought you were saying the icon would always cover the label, not just when dense.
I meant can't the label be offset.

[matkoniecz]

which would also not be displayed if too close to other such small circles

Is it possible to disable collisions for them?

[westnordost]

No, it would be like for the Places overlay. There is an icon (in that case - a blue circle of fixed size) and the label, i.e. in this case the housenumber is beside or below that. The overlay can neither control whether the label is shown next to or below the icon, nor can it control whether there are collisions or not. IIRC it could be that the collisions are disabled at a certain fixed zoom level.

[mnalis]

I understand that migration to Maplibre will allow SC to "cluster" closeby quests (which I imagine would look like as a circle with number inside or similar?)

Perhaps similar approach could be used here too? Not as visually ideal as "bigger circle" for "more addresses" of course, but would still be more useful indicator than just regular ("hide collisions") approach?

[tommycrock]

If it was possible for behaviour to be more like quests - much smaller spot to indicate 'something' when the full quest icon can't be shown - fewer cases of hiding would occur. If they were green (or blue etc) they would be distinguished from quest spots.
Also, it seems collisions often result in both/multiple icons disappearing and not leaving one, which doesn't seem ideal, but perhaps this can't be modified in the current environment (maybe this is what @mnalis is describing).
These would both seem like improvements for the places overlay too.

[HolgerJeromin]

That big circle is not really possible, unfortunately.

Lines are possible.
How does a line with two very similar points render?
A 3m linecap (wording from svg) should render similar as a circle and lines do not collide.

[westnordost]

The current behavior is that you can add POIs in overlays starting on zoom level 18, the POIs are shown starting on zoom level 18 and stop hiding each other when they would otherwise overlap on zoom level 20. After discussing it with @matkoniecz , I agree that the current behavior should be replaced by never hiding POIs when they are too close to another.
Otherwise, users might add POIs at zoom levels lower than 20 because they don't see them on the map.

So this is how it would look like:

blue_address.mp4

In the MapLibre version, the address label would be below the blue circle and the blue circle would not have a white outline, IIRC.

It can not be controlled per-overlay at which zoom level the icons should start to display, which is why when you zoom below zoom 18, areas that have been mapped with address nodes rather than addresses on the buildings look like areas in which the addresses are missing. Does that defeat the purpose of coloring the addresses blue?

[tommycrock]

I would think it would be helpful in all overlays to have an indication that there's something there below zoom 18, as is the case for quests. Could it not be reworked that overlay nodes fall back to a small dot icon at lower zoom levels?

[HolgerJeromin]

So this is how it would look like:

I like it!
Adding existing addresses at higher zoom is imo no issue

[westnordost]

Thanks @HolgerJeromin . Waiting for more feedback on #5748 (comment)

[tommycrock]

Thanks for the mock-up. I think it's useful having the addressed areas marked out even if addressed nodes seem missing at zoom<18. It still gives a better hint than currently where all addresses disappear at those zooms. Where there is mixed area and node addressing, it makes sense to use a blue icon to visually tie the addressed elements together. I wonder if it would seem like clutter in places where only nodes are used for addresses, but it also clarifies this is a node placed here. If the colour also gave some feedback about the SC editable tags in the address it would increase the benefit. You currently need to click on a node to see if the street (or place) is set, and whether there's a corresponding housenumber if named.
[Edited]
It would probably make sense to disable editing (at least missing) building addresses at zoom<18 however to avoid people adding apparently missing addresses based on colour.

[mnalis]

It can not be controlled per-overlay at which zoom level the icons should start to display,

Is it:

• current StreetComplete code doesn't support this, or
• current StreetComplete code doesn't support this and it's too complex / not worth it to add such support, or
• upstream (MapLibre/Tangram) library doesn't support that so SC can't support it even if it wanted to?

which is why when you zoom below zoom 18, areas that have been mapped with address nodes rather than addresses on the buildings look like areas in which the addresses are missing. Does that defeat the purpose of coloring the addresses blue?

Waiting for more feedback

IMHO It's still an good improvement over current non-colored version; although it would be much nicer if point-addresses were somehow shown even in zoom < 18 (e.g. as mentioned in comment #5748 (comment)).

[Maschga]

Hi, wanted to ask how the issue is progressing. I like the implementation of westnordost.

[westnordost]

Okay, there wasn't much feedback on my suggestion, but all was positive, so I'll merge that. We'll see how it is received by the broader user base.