render addresses (housenumber/housename)

[tyrasd]

Various improvements regarding addresses:

• add feature type "address points" for addresses mapped as nodes, allows to hide these, e.g. in regions with extremely high density of such nodes. fixes extreme high density of address nodes prevents editing of other POIs #10315
• render the housenumber or housename of address points as dedicated points with a "number plate" outline (compared to the "pin" outline for regular POIs)
• render the housenumber or housename of buildings (and other areas) like the name (when there is no name)

Remaining todos / open questions:

• add to changelog / release notes
• should in case when there are both addr:housenumber and addr:housename, also both be rendered?
• fully document all changes. There are some minor changes e.g. in the labeling code or the address field input handling, but there is one especially "deep" change in history.js: it should be fine (i.e. the intended way this was always supposed to work), but needs some double-checking for potential side-effects
  • fix move operation which is now glitchy probably because of the above mentioned change to the overwrite method
• fix bbox of touch targets (g.layer-touch > rect)

Below are a few example screenshots for different situations of mapped addresses:

1. addr:housename tagged as nodes:
   
2. addr:housename tagged on buildings:
   
3. mixture of address points addresses tagged on buildings with relatively long housenumbers
   
4. mostly addresses on buildings
   
5. housenumbers on building vertices (not tagged as entrance)
   
6. housenumbers on building vertices, tagged as entrance
   
7. addresses as separate points (often more than one housenumber per house)
   

[tordans]

render the housenumber or housename of address points as dedicated points with a "number plate" outline (compared to the "pin" outline for regular POIs)

I am not sure this is an improvement.
Right now, we have something that is easy to understand: Select the Pin-Draw-Tool => Get a Pin Icon and the other way around: See a Pin Icon => This is a node object.
This will be the first time(?) that a node does not look like a note.
We loose the pointy part of the node that tells me where it is located. An area would be located in the center more likely, not below the pin.

==> I think we should look for a way to have this still look like a pin, even though the content of the pin is now longer (the ref/number)

Making this new feature is less of a change IMO especially since the address pin never had a distinguished icon (pin content)

render the housenumber or housename of buildings (and other areas) like the name (when there is no name)

This is this part, right?

This looks like a rendering but to me TBH.
We need to make those look the same as the number pins from my comment above so users understand they are both address notes. But they need to be short.

One workaround could be to cut all of those new address pins after 4 chars and ellipse "…" them and on mouseover they show their full number, name, …
Does not have to be mouseover TBH, clicking would be fine at well.

[tyrasd]

render the housenumber or housename of buildings (and other areas) like the name (when there is no name)

actually, what I meant was when addr:* is on an area (screenshots 2, 4): then, there will be a label inside of the area (where a name would be rendered if there is one). This has the downside that the housenumber is only shown when there is no name tag: For example, when there is building=yes + tourism=hotel + name=XY Inn + addr:housenumber=123, then the label would only show XY Inn. This problem is similar to the case when an address has both addr:housename and addr:housenumber. I've added it to the open questions list above, but maybe these two issues could best be addressed separately in a follow-up PR?

---

One workaround could be to cut all of those new address pins after 4 chars and ellipse "…" them and on mouseover they show their full number, name, …

Good idea to limit the maximum length with an ellipse. It looks like this now:

---

This will be the first time(?) that a node does not look like a note.

Not quite: aside from vertex-nodes, also nodes with a direction tag (e.g. typically found on viewpoints, traffic signs, etc.) are already rendered as circles (plus viewport cone):

The reason to deviate from the "POI" symbol for address nodes was to make them more space-efficient, as the pin shape is already quite spacious, and the rendering of the labels next to the pin does not help either. This is fine for regular points of interests (e.g. a shop, school, landmark, etc.), as it allows to show an icon in the pin and can handle potentially long labels.

look for a way to have this still look like a pin

I played around a little bit with some alternative shapes: making them more pin-shaped by adding a little triangle at the bottom makes them look a bit like thought bubbles, which is kinda cute. But it also adds quite a lot of visual noise for little benefit: addresses are typically not that "pin-pointable" in practice, as they by definition stand in place for a building or similar area.¹

Footnotes

1. Yes, sometimes addresses stand for a particular building entrance, but for those we already use the not-so-much-pinpointable rendering of vertex circles anyway. ↩

[tordans]

Good idea to limit the maximum length with an ellipse. It looks like this now:

Looks good and a lot better to me. Does it have mouseover or do I have to click to see the full name?

Not quite: aside from vertex-nodes, also nodes with a direction tag (e.g. typically found on viewpoints, traffic signs, etc.) are already rendered as circles (plus viewport cone)

Thanks for the reminder, I see your point!

I played around a little bit with some alternative shapes: making them more pin-shaped by adding a little triangle at the bottom makes them look a bit like thought bubbles, which is kinda cute. But it also adds quite a lot of visual noise for little benefit: addresses are typically not that "pin-pointable" in practice, as they by definition stand in place for a building or similar area.

I like this design a lot.

I could see us using it for all pins. It would given them a fresh look and make them more space efficient. It could even work for the direction cone variant, reducing the number of different designs.

[tyrasd]

No, mouseover did not work in my tests (probably due to how the mouse events are handled: there are separate "touch targets" that are independent from the labels). but as that would not be really much faster than clicking on the node to see the value, I think it's acceptable.

I could see us using it for all pins.

🤔 could be worth a try…

[tordans]

@tyrasd I assumed this PR is the source for those rounded-square shapes in https://pr-1555--ideditor-presets-preview.netlify.app/id/dist/#locale=en&map=19.60/14.65605/121.06291&disable_features=boundaries&background=Bing&id=w98724280 ?

I think those should not receive the new layout but stay undefined pins instead.