The first one seems to be more intuitive although I find it confusing that a colon is used instead of underscore.
Numbered tags are discouraged elsewhere (name_1) so it would be somewhat inconsistent to use this variant.
Using regular addr:street tag with multiple semicolon-separated values came to my mind too, but this would conflict with the existing usage of this practice. All the samples I checked seem to be addresses where a street has several names (alt_name, old_name, etc.) of which either can be used for addressing, but not both at the same time.
Which tag do you find most suitable?
Edit: Removed poll in light of additional information (see below)
I just had a look at Taginfo statistics. 90% of addr:street:corner uses are in the Philippines while 90% of addr:street2 occurences are in Russia, the first steadily rising in usage and the latter continuously declining.
Investigating more samples it also appears that most usages of addr:street2 are intended as two different options for addressing which is very different from the use case of addr:street:corner.
In light of this additional data the original question appears to be moot.
Would there be any concerns about simply going ahead and documenting addr:street:corner?
Indeed, the Philippines community decided many years ago to tag corner addresses as the combination of addr:street=* and addr:street:corner=*. It would be worth documenting. Many addr:*=* subkeys apply in some countries but not others, so it isn’t a big deal if other countries would prefer not to use addr:street:corner=*.
If it’s a real second address (and not just the name of the street corner), there is an established tagging scheme using “addr2:…”:
Proposed, but never voted on. Currently used close to 20,000 times: https://wiki.openstreetmap.org/wiki/Proposal:AddrN_(2015)
Corner addresses also exist in the United States. For example, an address at the corner of High and Broad streets would be written “High and Broad”. The USPS accepts addresses in this form (but not “High St. and Broad St.”), canonicalizing them to proper numbered street addresses. Regardless, many corner addresses are physical addresses rather than mailing addresses. In my city, some parks don’t receive mail but have corner addresses according to the city and county governments. Some businesses prefer to use a corner address as both a physical address and a mailing address, so it is valid to tag the corner address.
Based on this national addressing standard, over 100 addresses are tagged in the form addr:street=High Street and Broad Street. This is consistent with other mapping platforms, such as The National Map Corps (direct link). I think this is more suitable than splitting out a separate subkey, because the postal service doesn’t consider the two street names to be distinct “slots” in the address format. I agree that High Street;Broad Street would be too ambiguous. It could represent either a POI with two addresses or two POIs incorrectly merged together; both scenarios are far more likely than a single corner address.
Incidentally, addr:street:corner=* appears three times in the U.S., on a firehouse, a park, and a statue. All three were added by a mapper from the Philippines who was probably unaware of the U.S. convention. I’m also unsure that the statue really has an address apart from the park that it’s located in.
Good point, looking closer at the chronology it seems that mappers have stopped using addr:*2 soon after this proposal.
The variant with number before colon has been adopted for new contributions but nobody bothered to comprehensively update the tags from the old scheme.
Shouldn’t that be rather addr:place=High Street and Broad Street, given that it doesn’t describe an existing street but rather a location point (the intersection of the two streets)?
(And, yes, this suggestion is not made entirely without self-interest. With addr:place it would “just work” with Nominatim search.)
It seems 123 Ruby St is the actual address proper? Opal St is only an aid in quickly locating it. Then it should be kept as addr:street=Ruby Street + addr:housenumber=123 for both accuracy and usability. addr:full=123 Ruby Street corner Opal Street is a safe choice, and reflect how it’s supposed to be used. Maybe nearby streets can be used to promote a result in geocoding.
“High St & Broad St” @Minh_Nguyen is another topic. Describing an intersection alone, without number.
I don’t think addr:place=* should be used at all in the mainland U.S., because the standard U.S. address format doesn’t distinguish between streets and places. They’re all considered to be the portion of the delivery address line that goes between the house number and unit number.[1] Sometimes, what looks like a street name might not be an actual street name.
Most of the 11,000 existing uses of addr:place=* in the U.S. are actually postal city names that should go in addr:city=*. Before iD introduced a field with the standard U.S. address format, some mappers incorrectly thought that a postal city should only go in addr:city=* if it names an incorporated city, or addr:place=* otherwise (such as for a town, village, or CDP).
The exception is Puerto Rico, where an urbanization is part of the standard address format, on the line above the house number and street name. These are being tagged as addr:place=*, though perhaps addr:quarter=* would be more harmonious with international usage. Even in Puerto Rico, if an address is associated with a public housing project but not a street, the project’s name is considered to be the street name.
In the cases I’m describing, both “Ruby and Opal” and “123 Ruby Street” are equally valid delivery address lines. The owner prefers the former while the USPS prefers the latter. I’m not describing the more common case where people might describe a location at a street corner for convenience, disregarding its actual address.
Typically, when a delivery point such as a building has multiple valid addresses, my advice has been to map the addresses as separate nodes within the same building. I suppose a shop that uses multiple addresses could similarly be mapped as an area with nodes inside it. But admittedly this approach doesn’t answer the question of how to tag the building or POI itself with its addresses.
The USPS considers the various words in a street name to be components in their own right, such as “North” or “Street”, but we don’t tag those separately in OSM. ↩︎
I think you’ve got that sightly wrong, it is -OSM- that distinguishes between “place” and “street” for the street level localisation in the address hierarchy. That the US, or where I live doesn’t (in addresses) is simply not relevant aka it looks the same on an envelope.
But if you’re routing to the corner of “This Street & That Street”, which of the 4 corners is it going to take you to, or is it going to drop you out in the middle of the intersection?
Perhaps a more accurate way for me to phrase this is that the U.S. does make this same distinction, but not on the mainland. Additionally, addr:place=* has always been hopelessly skunked with postal cities – that is, if addr:city=* is only for places that OSM classifies as cities. By your reasoning, the majority of addr:city=* occurrences in the U.S. need to be retagged to either addr:place=* or a proliferation of subkeys such as addr:hamlet=*, addr:village=*, and addr:region=*, or less commonly addr:island=*, addr:landuse_military=*, addr:monastery=*, and addr:office=*. It starts to resemble an is_in=* tag all over again. For what purpose, I don’t know.
If we were so unconcerned with reflecting the distinctions in each region’s standard address format, and overly concerned with what amounts to an etymology, then we would have to deal with a litany of broken assumptions, such as:
In some older cities or on college campuses, the street may be a named, garden-variety footpath that we’d certainly tag as highway=footway, not highway=pedestrian.
Plenty of streets are numbered highways that we’ve chosen to tag with ref=* but not name=*. Deriving the actual street name from a way ref or route relation would be an effort on the scale of OSM Americana.
In Queens, New York, and much of Wisconsin, a house number is essentially a coordinate according to a local grid.
This is just the tip the iceberg. And just to illustrate that this isn’t merely a U.S. issue: in Vietnam, the average urban address lists somewhere between three and six different streets by number, but it’s all considered part of the house number.
I get that we shouldn’t be overly concerned with matching the postal service’s database structure. That to me is an argument for continuing to represent the full street name as a single tag, rather than breaking it up word by word as the USPS does. It’s also an argument for continuing to keep the house number in a separate tag, very useful for rendering, even though most software keeps the whole delivery line in one database field. But I disagree that it means we need to distinguish the reasons why something goes in the street slot of an address.
That’s what most geocoders do when searching for an intersection. However, I’m not talking about user input. If a building on one corner is tagged with a corner address, then the geocoder would use the coordinates of that building, not the intersection. By analogy, many addresses name a street that isn’t the closest street, but a geocoder should be able to return the coordinates of the feature, not the street named in the address.
Around here (New Hampshire), mobile homes in a mobile home park are typically addressed 17 Wenslydale Mobile Home Park, Townsville, NH 01234 by the USPS. The streets are generally not named, and the mobile home park does not have an overall address (so they aren’t unit numbers). I know of one case where the streets are named and the USPS assigned numbers to the mobile home park anyway. In these cases, I use addr:place.
Heh, I like how the E911 addressing committee goes out of their way to call it “non-compliant street addressing”. Anyhow, it reminds me of cases where the designated address contains a non-obvious street, so something else does instead.
One reason I find the rationale for addr:place=* in the U.S. to be unconvincing is that it seems to be motivated by an assumption that addr:street=* should always match the name=* of a nearby roadway. This has led mappers to work around poor geocoding of vanity street addresses by falsifying the name of an arbitrary parking aisle or parking garage entrance. No one noticed for years, because these sound like plausible street names. The distinction between street and place isn’t especially verifiable. On the other hand, there are vanity parking aisle names that never appear in addresses.
The addr:place=* documentation goes on to suggest that the value should match a nearby place=* node, and that if there isn’t one, we should give up and ignore the validator warning instead of mapping a fictitious place. Why only then? Why must we treat JOSM’s addr:street warning as authoritative but not a corresponding addr:place warning? I was looking forward to retagging this boulevard as a place=locality, but now I’ll have to settle for shop=car.
After all this, the combined names of two intersecting streets don’t sound like such a stretch for a key that’s superficially about streets.
Vietnam, the average urban address lists somewhere between three and six different streets by number, but it’s all considered part of the house number.
Incorrect, house number in vietnam is always an integer or an integer prefixed with an alphabet character such as 12A or 94C. It will go under addr:housenumber. The “slashes” and “many streets” you just talked about belong to addr:street. So if the address is sth like “nhà 20A/31/7/1/24 Đường Phan Đình Phùng”: addr:housenumber=20A, addr:street=31/7/1/24 Đường Phan Đình Phùng.
I was just going off of the predominant tagging style in Ho Chi Minh City: there are xuyệt in about 6,000 addr:housenumber=* but only 250 addr:street=*. It was even more lopsided before thousands of surveyed addresses got mistaken for a botched import and deleted a few years back. (In fairness, it came with some very messy tagging.)
If the local consensus is that the numbers between “số” and “đường” in an address should be split between addr:housenumber=* and addr:street=*, then StreetComplete’s validation rules probably need to be updated again, and the Vietnam tagging guidelines should say something about that before overseas mappers make a mess of things. A renderer would have an easier time labeling addresses based on just a “file name” in addr:housenumber=*, but users would still expect a geocoder to come up with the absolute file path, and I’m not confident that most geocoders would succeed at it.
It’s complicated and depends on the city, and in some cases the ward. Here are some examples from one neighborhood of Ho Chi Minh City:
In prose or on an envelope, this address would be written as something like “số 1982/53A, đường Huỳnh Tấn Phát, khu phố 7, thị trấn Nhà Bè”. To get here, take Huỳnh Tấn Phát street, the main thoroughfare in Nhà Bè town, turn onto alley 1982 of Huỳnh Tấn Phát street, and pass 53 doors until you see the sign for 1982/53A.
These are relatively simple cases. Parts of the city are a warren of deeply nested alleys. Here’s the sign for alley 1716/46/24, which is 24 doors down alley 1716/46, which is 46 doors down alley 1716:
In 2017, there were reports that the authorities were finally doing something to simplify “super-slashy” house numbers containing as many as eight slashes, renumbering the alleys so that the houses could be renumbered too.
At this point, you might be wondering why all this information belongs in either addr:housenumber=* or addr:street=* if it’s just driving or walking directions. Unfortunately, a router cannot calculate these absolute file paths on its own, because there are often many paths to reach the same location. The alleys are numbered according to how the parcels were subdivided over the years to create this neighborhood. Apparently Thailand has a similar system:
Complicating matters, sometimes the house numbers seem to have nothing to do with the nearby alleys:
You’d think this house is the second house on alley 382/51 Huỳnh Tấn Phát street. But there’s no such alley. The street sign tells us it’s actually on alley 1982/53/25, at the intersection with alley 1982/53/25/2. Go figure.
Thank you for the thorough explanation. It’s always fun to learn about different addressing systems.
The whole thing reminds me a bit of the system in the UK, where they also sometimes add the main street and the alley to the address. I wonder if we can find a common tagging system here. They have introduced the concept of addr:substreet and addr:parentstreet for it.
That said, we are so far off-topic from corner addresses now, that it might be worth to move the discussion in an extra thread.
