Localise subhousenumber housenumber formatting

[andrewharvey]

The following two lines hardcode the specific formatting of housenumber subhousenumber

StreetComplete/app/src/androidMain/kotlin/de/westnordost/streetcomplete/util/NameAndLocationLabel.kt

Line 184 in ddd637e

val houseNumberEx = if (subHouseNumber != null) "$houseNumber $subHouseNumber" else houseNumber

StreetComplete/app/src/androidMain/kotlin/de/westnordost/streetcomplete/util/NameAndLocationLabel.kt

Line 202 in ddd637e

houseNumber != null && subHouseNumber != null -> "$houseNumber $subHouseNumber"

However from the iD address_formats.json globally this formatting varies and is oftern times the other way around and using a slash like subhousenumber/housenumber. This should be localised according to the user's locale.

[matkoniecz]

This should be localised according to the user's locale.

Maybe rather location's locale?

[andrewharvey]

Maybe rather location's locale?

I guess it depends if you're going for something like

1. the OpenStreetMap Carto style which renders each region localised, making the map appear more akin to "on the ground", but harder to make sense of across regions and locales
2. the Americana where you choose your locale and the whole world is rendered in that locale, which makes it appear different on the ground to on the map, but easier to understand and make sense of for people from different locales.

I think both have their place. For a SC aimed at editing the data, perhaps (1) makes sense so that we have the match between map and on the ground.

[matkoniecz]

I looked at https://github.com/openstreetmap/iD/blob/develop/data/address_formats.json and it seems to be about full address formatting - not just housenumber/subnumber

[matkoniecz]

@andrewharvey

However from the iD address_formats.json globally this formatting varies and is oftern times the other way around and using a slash like subhousenumber/housenumber. This should be localised according to the user's locale.

where you see this slash info in this config file?

[andrewharvey]

where you see this slash info in this config file?

it doesn't say what kind of separator is typically used, be that a / or , or or -, but it does show the order, in particular if unit precedes or follows housenumber.

[andrewharvey]

I looked at https://github.com/openstreetmap/iD/blob/develop/data/address_formats.json and it seems to be about full address formatting - not just housenumber/subnumber

Correct, but it still shows the typical order of unit and housenumber.

[westnordost]

We just need a tiny bit of info from that JSON since we never show any full address and not even housenumber + street anywhere in the app, if I remember correctly. So, maybe we can just put the part of the information from that json we need into some utility function

[westnordost]

A solution is testable for example here: https://www.openstreetmap.org/way/1361684535

I had a go at this. But I am not satisfied with passing the country code everywhere (because the house number is shown in so many places...).
Also, the implementation linked below is not finished yet, I'd still need to determine the current country for each marker, which would be a bit painful to do for each point individually. See AAddLevelForm.kt and MainActivity.kt:

https://github.com/streetcomplete/StreetComplete/compare/localize-unit-number-order?expand=1

I noticed that the end result is somewhat inconsistent, and has been before, actually.

The normal map, when the address overlay is not active, will never show addr:unit, as that's just the data coming from jawg.io. Only when switching to the address overlay, or opening a quest and looking at the name and location label shown below the quest title, one will see the unit.

To be honest, I am considering removing rendering the addr:unit at all again. It was only introduced to mitigate an issue where a user inadvertently changed some house numbers to their respective unit numbers via the address overlay, because on-site he only saw the unit numbers on the different building entrances but no house number, so he assumed the previously mapped house number must be wrong. So, the reasoning to show addr:unit at all (on the map) was to avoid this kind of misunderstanding.
A better method to avoid this misunderstanding, however, would be, to actually show and allow to enter the addr:unit in the address overlay and subsequently the housenumber quest form (#6766). For this, the order of the text fields doesn't even matter much, as long as the fields are clearly labeled.

---

Looking at other maps and tools,

• JOSM only shows the house number
• iD only shows the house number
• osm-carto shows both, but always the house number first, then the unit number
• jawg.io only shows the house number
• versatiles only shows the house number
• shortbread only shows the house number
• maptiler only shows one house number and doesn't display others with the same house number but a different unit number