I have been working through address additions using the ESRI National address database feed for Phoenix AZ. While doing this work, it’s very common for me to clean up other oddities in tagging that I run across (typos, old tags that have better modern tags, etc etc). Another user in the area and I are having a discussion about two particular issues [in this changset] (Changeset: 144310324 | OpenStreetMap) but I want to make sure we both have broader consensus before continuing.
There are at least 2 issues that need resolving:
Do we think it is appropriate for buildings in the United States to have addr:country=US or is this tag unnecessary?
Do structures that explicitly not have addresses need any address tagging? I had removed a bunch of tagging (addr:city, addr:postcode etc) from various outbuildings and other structures.
I don’t feel particularly strongly about item 1 but would love to know what the general feeling is. To me it’s unnecessary and given the language in the addr:country wiki page and similar sentiment in the is_in wiki page I presume it could safely be discarded.
For item 2, I feel pretty strongly that items like Way History: 847835130 | OpenStreetMap should not have any addr: tagging. In the same way that tree nodes likely shouldn’t have address tags.
Anyhow, I come seeking wisdom. Thanks for any advice you can provide on the topic.
I’d say it’s generally redundant but harmless. It would matter more if a POI or residence routinely receives mail at a U.S. address or vice versa, or on a U.S. overseas military base that geocodes as part of another country, or on a building that straddles the Canadian border. (Its two mailboxes have been mapped separately for good measure.)
Sometimes a similar question comes up about whether addr:state is redundant too. Technically it is, as long as addr:postcode is present, but there are many more residences and businesses served by a post office across a state line (so that the correct addr:state cannot be inferred from the boundaries). Even for addresses in the middle of a state, everyone expects the state to be part of a domestic address, and there’s a lot more domestic mail than international mail. I added an addr:state textbox to iD’s Address field after observing that, without it, mappers were habitually appending the state to addr:city or even entering it as addr:postcode instead of the ZIP code.
addr:country and addr:state are, in my opinion, not needed and are just noise. We have boundaries for those which give that information. I do use addr:city because postal cities do not always match with boundaries of cities.
With respect to putting any addr:* tags on out buildings, etc. I don’t do it and will usually remove them when I come across them. In my mind the main reason for having address information is for routing and in those cases the end user will be interested in getting to the main building. And having addr:city or addr:postcode by themselves is not useful for routing.
As someone who has worked with postal address normalization for bulk mailing, I would say that although this tag may be “unnecessary” it is still a substantial convenience to have it. I know @Minh_Nguyen said it is redundant but harmless. I’d go a step further and say, it’s redundant but useful. There are other cases where we do things that may be unnecessary but are convenient for data consumers. We could consider this to be similar.
Let’s not limit the discussion to structures. Many natural features imported from GNIS have addr:* tags derived from the GNIS data. These tags are worthless and often misleading. If the feature in question does not have a formal, official address then it shouldn’t have these tags.
I never use addr:country and only personally add addr:state or addr:city when there’s any chance that it could be in doubt. When importing I do include city and state just for completeness. I wouldn’t remove a country tag if I saw it, but I’d also object to someone requiring it for anywhere >100mi from another country’s border.
Outbuildings shouldn’t need any address tags. The example building you linked looks like a pool changing room / bathroom / shower to me, not a house, so I’d tag it as an outbuilding and remove all address tags.
Practically speaking, wouldn’t a data consumer have to cope with missing addr:country tags anyways? It’s only present in conjunction with 7.6% of addr:housenumber occurrences, compared to 60% for addr:state. (I wasn’t kidding about mappers itching for a place to put the state abbreviation!)
Are these real addresses, or just addr:state being used as a synonym for is_in:state? I see only 55 features tagged with a combination of addr:street, natural=*, and some gnis:* tag. But maybe that’s because you’ve cleaned up a bunch already. In fact, GNIS would be a very good source of addresses for certain kinds of POIs in certain states, like fire stations in Indiana, or post offices in the states where The National Map Corps has cleaned them up. The only catch is that the addresses are trapped in the feature description histories, which are no longer distributed through the main GNIS search engine.
I agree that outbuildings normally shouldn’t have addresses, although an in-law unit usually has its own mailbox with a unit number. Proprietary datasets don’t seem to keep good track of these units, so it’s an opportunity for OSM to be locally competitive.
Another note of caution is that buildings are not the only addressable features in OSM. Parks, power substations, and railyards all routinely have street addresses, if not to receive mail then to receive other deliveries or visitors. My city also posts a street address on each of its utility cabinets, matching the parcel it’s on.
In the UK it is not uncommon for garages for several residences to be in a separate block, with each garage having a number corresponding to the addr:housenumber of the residence (I’ve owned a couple of properties like this). I have never figured out a good way of conveying this information in OSM, so have never tried to map it. An added feature is that the parking space in front of the garage is often private to the property (although never marked on the ground).
I don’t know if anything similar occurs in the US.
I don’t think it’s appropriate to have multiple buildings tagged with the exact same address. If the buildings have different unit numbers, that’s fine. But I see a lot of cases where everything from garages to sheds to parking lot carports are tagged with addresses. I think the address should only belong to the main building. If someone wants to route to a business, they could get sent to a “building” that’s just a roof over a few parking spaces that’s all the way across a huge parking lot from the building they were trying to get to.
Also, it just conceptually makes sense to me that address tags should be attached to places that could conceivably receive mail. If a package arrives at 123 Main Street, it will be delivered to the house on that property, not the pool house out back.
That sort of reminds me of this parking lot in front of a small strip mall, where each space is marked for a specific shop along the strip mall. I just tagged the name of the shop on each space, but I suppose a more robust approach for modeling it would be a site relation for each of the shops, with the allocated parking space or spaces as members with the parking role.
This site-based approach would also extend to nonobvious delivery points, like this parking garage under an apartment building that serves as a delivery point for some but not all of the addresses in the building:
Regarding locations with multiple buildings/structures with the same address: It is a fairly common practice in my area for gas stations as they almost always have a convenience market on the same land parcel and usually the market brand/name is different from the fuel brand/name. In those cases I outline the property and set that to landuse=commercial and put the address tags on the property. The buildings then get appropriate tags for based on their use.
Typically the latter. Some of the GNIS imports translated the State code in the GNIS record to an addr:state tag in OSM or the placed the county name from the GNIS record in the addr:county tag. That’s not necessarily harmful for built features which might actually have addresses, except that the GNIS records for these features were poorly maintained and were often incorrect.
The addr:* tags generally don’t make sense for natural features. I remove them on sight for things like natural=water or natural=peak.
The state and county fields from GNIS are also problematic where features are close to or cross administrative boundaries. GNIS populates these fields based on the “primary” coordinate for the feature, not the center or extent of the feature. So the results might not be what what you’d expect based on the actual boundaries.
nwr["gnis:feature_id"]["addr:state"]["natural"]; out count; → 18,440 features.
Sometimes I see the address for the “gas” portion of this on the roof structure commonly covering the pumps. I like your way just fine though, it’s a real annoyance that I don’t think has 1 clean solution.
Thanks everyone for the thoughtful replies. I’ll give this some more time to cook and get more perspectives. My current rough summary is:
For addr:country tags, for feature that have postal addresses, they are harmless and there doesn’t seem to be an appetite for removing them although some mappers do. I am perfectly happy to stop removing these tags.
For outbuildings and small secondary structures (roofs, sheds, carports etc), the community generally sees tagging these with address tags as incorrect mapping.
Additionally, there seems to be a decent cleanup item from old GNIS imports that should probably be reviewed and cleaned up. I can add that to my long list of mapping tasks but of course would be happy if someone else wanted to tackle that. Definitely a good first project for someone wanting to JOSM a bit!
In that case, there’s typically more than one POI, plus the main building (which houses a convenience store and/or car repair shop). I think all the POIs should be individually tagged with an address, even if it’s the same address. I might also tag the main building on the parcel with the address, for the benefit of a building-focused user, but the canopy or outbuilding would only get an address if it happens to be dual-tagged as one of the POIs.
Unlike JOSM’s validator, I definitely don’t think it’s a problem if more than one feature has the same exact address in close proximity. For one thing, duplicate addresses definitely happen in real life. What’s more, the addr:* tags are secondary attributes (except when they stand alone as address points). It isn’t really a problem that this mechanic’s shop and its attached gas station share the same name and operator, or that this gas station is named after its attached tire store, so it shouldn’t be a problem if they share the same addresses either. The calculus would be different if OSM were in the business of mapping parcels comprehensively, but we aren’t.
