Specifying both :label and :type seems a bit redundant - it would be better to have just one that isn’t an acronym. If I’m understanding “Beispielstraße 101/3/15” correctly, the labels are optional and the address could also be displayed as “Beispielstraße 101/Staircase 3/Door 15”? I would have thought that labels being optional would be region specific. In Australia they’re always optional - is there a case where it wouldn’t just follow a regional preference, and would that actually need to be tagged?
I also would have thought that the separator would be region specific, possibly even depending on being a full/display address you might find on a website vs. a shorter, abbreviated address you might find on letters? It’s already expected that data consumers format addresses differently depending on country.
I suggested :label/ a pre-formatted tag as I imagine there would always be some address out there that just does not follow any standards. As an example, there is a business park that does not follow the AU NZ addressing standard, by assigning sub addresses with duplicate numbers, that also uses non-standard unit types: East, West, and my favourite, Powerhouse.
I know, practically all of my suggestions here make things slightly more difficult for data consumers depending on how many regions they want to support - but it does make editing easier.
Using something like :value to specifically say “group” sounds like a good idea. I’d be surprised if there was a really long unit number that couldn’t fit in 255 characters and therefore needed to use addr:unit:N, but seperating addr:unit:N= from addr:unit:N:*= is clearer, and could be a good convention to establish if it’s possible the shorter key could have a different meaning.
That’s technically true. I’m just concerned it would be unintuitive and potentially error-prone if we make the semicolon in foo=* mean something totally different than the number in foo:#:*=*. Most of the existing indexed subkey schemes are outgrowths of semicolon-delimited lists that have the same semantics.
Maybe it’s no big deal. For the U.S., my bigger concern is that, in principle, nearly every instance of addr:unit=* is a case where we should apply whatever new scheme we come up with. Should addr:unit=* remain for backwards compatibility? In the case of multiple secondary addresses, should it continue to contain shorthand? For example, if the secondary addresses can be written either “Building 12, Suite 3” or “#12-03”:
The shorthand is technically not allowed by the postal service, so CASS-compliant software will try to expand it (as a best effort). Regardless, it makes for a more succinct map label. Maybe instead of old-style versus new-style, we can think of these two syntaxes as being for map labeling versus geocoding.
I don’t think we should start translating addresses between languages, but follow regional formatting by default. :type is an optional specifier for the type of unit, with a fixed set of documented values, so that consumers can parse the meaning of each unit segment, such as if it refers to a building, floor, door, etc. A navigator app could translate “Go to floor 3 in building A” instead of showing “Go to Edf. A, 3° piso”, just by reading the :value and :type tags
I’m not so sure guidance instructions should be based on address tags anyhow. There’s no guarantee that we can take the secondary address so literally. For example, in the address “123 Back Road Lower”, the secondary address “Lower” could refer to the ground floor of a two-story building, which would normally be called the first floor, or it could be the basement. The button on the elevator panel probably won’t read “Lower” due to building codes. Besides, the floor could be useful for wayfinding even if it isn’t formally part of the address. level:ref=* would be more useful for the floor number in human language, while ref=* on the building would be more useful for the building number.
The secondary address designators are unusual in that they appear literally in the address. All the other address components are associated with words that we don’t write out, at least in the U.S. For example, we never write “Street” in front of the street name. There are more routine examples of explicit designators in other countries. For example, Vietnam formally puts “Số” before the house number. The postal authorities also accept “No.” when writing the address in English. It would be up to the geocoder to know about this as part of the national address format.
Maybe we can require addr:unit:#:label=* but leave addr:unit:#:type=* as an option. While we can’t expect a geocoder to infer the order of secondary addresses in an address, maybe we can get away with tagging only the local-language designator and relying on it to infer any translation, or vice versa. We already do so for cardinal directions accompanying route numbers in highway destinations. For the U.S., label is more meaningful than type, since the designators aren’t supposed to be translated – “Building” and “Edificio” aren’t interchangeable.
I just realized that we’re basically discussing a special case of generics and specifics in toponyms. Generics are sometimes crucial, sometimes not, and regardless people will omit them in some situations. Name tags give us a very strong precedent to just dump the whole series of secondary addresses into addr:unit=* as unstructured text, expecting renderers and geocoders to parse out anything of particular interest. I’ve seen some experiments to annotate the unstructured names with dedicated subkeys for directionals or specifics, but they haven’t taken off because data consumers have mostly gotten by without.
addr:unit=Building A, 2nd Floor, Suite 7
addr:unit:short=A-207
addr:building=A
addr:floor=2
addr:suite=7
addr:unit=Lot 9, Space 22
addr:lot=9
addr:space=22
addr:unit=Pier 49 Side
addr:pier=49
The subkeys are only there to guide data consumers for formatting purposes but not to reconstruct the full form. Wikidata takes the same approach when it comes to addresses overall: street address (P6375) takes the full form, and qualifiers such as house number (P670) and floor number (P5423) guide users to understand the structure better.
In all these examples, addr:unit=* contains some information that we don’t have structured tagging for. Data consumers will see more clutter, but at least they don’t see dataloss. If a shorter form is known, it can be given as addr:unit:short=*. Realistically, not every secondary address has a short form, other than routine abbreviations of the sort that data consumers already recognize in name=*.
I realize this is a completely different direction than what we’ve been discussing in recent days, but I wanted to raise this possibility in case we have any second thoughts about the direction we’ve been heading down.
That was a purely hypothetical example. I simply combined a fictitious house number and fictitious street name with “Lower”, one of the approved secondary unit designators in English that doesn’t require a number or letter to follow it. Other such designators include “Basement”, “Side” (as in side entrance), and “Rear”.
Some here may remember that Mapbox’s old headquarters location was at 1714 14th Street Northwest Rear, the “Rear” referring to a garage facing a back alley, sharing a parcel with the fitness gym facing 14th Street NW. That’s how Mapbox registered their address with various authorities, but in principle they could’ve gotten even more specific until they took over Development Seed’s upstairs office: “1714 14th Street Northwest Rear, 1st Floor”.
So, I hadn’t read the whole thread, but read many of the early posts and jumped to the end when I saw that this is a long-running discussion. My gut was to basically do your suggestion here where you duplicate only the subaddress, since it’s specifically to provide compatibility with users who need the full subaddress, and not just a structured building or unit to use for geocoding.
I had thought of it in reverse though, thinking addr:unit could stay as-is because of history, while addr:subaddress or addr:unit:full would get the full subaddress including the words - the same as what you put in your addr:unit in the examples.
Just to be clear, the scope of this discussion is just about secondary addresses as in units. addr:*=* keys relate to each other differently from country to country. After all, in some countries, addr:district=* comes before addr:province=* while in others it comes before addr:city=* (or after in East Asia). Likewise, I’m not expecting that any subkey for units is being used in exactly the same manner everywhere. However, it would be nice to be able to reuse well-established keys like addr:unit=* and addr:floor=*.
The bigger issue is that the USPS has approved “Unit” itself as a secondary unit designator in English. It doesn’t mean the same thing as “#”, what we use when we don’t know the designator. So if we do rely on subkeys per designator, we still need to distinguish between this usage and existing usage that has omitted the designator just because we didn’t used to think it was important. Is that what you’ve been using addr:unit:ref=* for?
Regardless, even if we decide against the designators as subkeys, there’s still a possibility of using addr:unit=* and addr:unit:full=* or addr:unit=* and addr:unit:short=* plus addr:#:label=* and addr:#:value=*. We’re facing a choice between one set of complications and another.
As if this weren’t complicated enough, the USPS apparently has not only P.O. Boxes but also P.O. Drawers. contact:pobox=* didn’t seem descriptive enough, so I temporarily went with contact:podrawer=* on this school.
