Collapse multi-value housenumber values

[ZeLonewolf]

For house numbers which have many values, common practice is to map them as semi-colon separated (location):

I propose that these be combined to a more readable string with an en dash in between such as 58-66.

[1ec5]

In the example above, should it be “58–66” or “52–66”?

[1ec5]

The range separator is an en dash in many Western languages, but it isn’t universally used as a range separator. For example, the range separator would be a wave dash (〜) in Chinese and Japanese, and a tilde (~) in Korean. In these languages, an en dash would be easily confused with 一, the Hanzi character meaning “one” or “a”, although my understanding is that Chinese and Korean are somewhat laxer about allowing an en dash for numeric ranges. CLDR has a listing of the industry-standard range separators, although I suspect this part of CLDR hasn’t received as much scrutiny as other parts.

Clients may be able to format localized ranges more effectively. Perhaps there should be separate properties for the beginning and end of the range, the end being optional.

[ZeLonewolf]

I think the options are:

1. Put the dash between the first and last item, regardless of value.
2. Attempt to sort the items in ascending order and put a dash between the sorted first and last item.
3. Introduce new attributes for the first/last or smallest/biggest (depending on which approach is taken) and then the client can choose their own separator.

As much as this is a corner case, I think sorting introduces its own problems, such as non-numeric characters, which might appear in other corner cases.

Introducing new attributes is a fine solution, but would be a breaking change that would have to wait for OMT 4.0.

[ZeLonewolf]

I've prototyped a change that will handle non-sorted multiple-value housenumbers:

Please let me know if it's worth pursuing this or if the issues described above make this a non-starter. Without find/replace or split/join in maplibre-gl, end users don't have the ability to collapse multi-value house numbers on the style side.

[TomPohys]

Thanks! Could be possible to use sorted (52-66) (your option 2)? The range sign is OK. The PR is welcome!

[1ec5]

FYI, some places use hyphens in individual addresses. Queens, New York, is probably the most well-known example. There are many multi-address buildings there, but they’re generally mapped as one node per address. If you parse - ranges in addr:housenumber, it probably won’t make a huge difference if the hyphen becomes an en dash in every Queens address. But I don’t know if you’d get as lucky in other places that use this system.

Dashes in individual unit numbers would pose more of a problem if you extend this approach to addr:unit or addr:flats, since many multi-building complexes use a “building number dash door number” format for unit numbers. But a proper fix needs to be at the data level. I don’t think there’s an established fix there, other than to use to or – instead of - as the range separator in the raw data.