I’ve been mapping several apartment complexes recently, and I’m not sure how to map everything in them. I’ve seen some advice in forum posts and tried to get as much from the wiki as possible, but all the relevant information there is a bit scattered. I’d like to expand the residential=apartments wiki page, but I figure I should ask what others think first since it’s such a common feature.
I’ve whipped up a quick scheme diagram for a fairly common kind of apartment complex in the United States. Here, the whole apartment shares a single street address and mail is delivered to mailboxes in or near the property office; I figure applying the street address to either the office or the surrounding residential=apartments polygon is acceptable. Each building is often assigned a number or letter, so they each should have a ref=*. I’ve sometimes used a name tag for these since ref doesn’t consistently render, but ref really is the more appropriate tag for this.
In this example one of the building has two hallways that units are accessed from, each of which has its own addr:flats=* for the units which may be accessed there. I see some mention of using a site relation in such situations, but I’d prefer to keep it simple.
I saw a post recommending addr:place for buildings in such apartment complexes. Does this seem reasonable to others?
Do you mean that it is one structure, but that there are two entrances and that the residents can only use ‘their’ entrance and not the one on the other part of the building?
Using addr:place would actually break Nominatim in this case.
We don’t have a good addr:* tag right now to say, that something has a street address but is also part of a site or building. At least as far as I’m aware. It is not rare to have something like that, so maybe it’s time to invent one. addr:site maybe?
I mean a site relation could do that, but the wiki page seems to discourage it for this case. I’m not sure that the addr namespace would be the right place for it though. Your idea seems more similar to operator and could probably have its own key.
Anyways, anything else missing from this? I added the building:flats key to the apartments and the addr:*=* for the (may or may not be shared) street address and gave the fitness center its own node to distinguish it from anything else that might be in the property office.
So just put the first thing they don’t share on each building? In this example it would be the flats, but if each building had its own housenumber then it would also be that?
I was talking specifically about the address here. Say you have an address like
Sunset Apartments, Unit 5
315 Peach Street
Darktown
Then the house number refers to the whole building complex but an address endpoint is really at unit level. So the address for your flat could be something like:
According to the wiki, addr:flats is used for “The unit numbers (a range or a list) of the flats or apartments located behind a single entrance door,” and addr:unit “The number, letter, or name of a single unit or flat that exists within a larger complex.” The impression it gave me was that addr:unit isn’t appropriate for lists.
Is there a strong consensus against using addr:flats here? I just checked and couldn’t find any mention in the local tagging guidelines.
A single addr:unit=* value may appear on a building if it is a delivery point and the unit number is the only thing that distinguishes the building itself from other buildings. Conversely, addr:unit=* can contain a list of apartment numbers, on an element that represents the individual apartment unit (or a group of them within a building to the best of our ability). Note that an entrance node doesn’t represent an apartment unit per se.
Otherwise, addr:flats=* is intended for saying which units are contained within a building or behind an exterior entrance. This is a bit awkward because it doesn’t formally correspond to the actual address format. It’s kind of like the inverse of is_in=*, in other words “contains:addr:unit=*”.
addr:unit=* is very frequently used instead of addr:flats=* for this purpose, so data consumers might need to work around it anyways. One issue is that addr:flats=* sounds specific to apartment buildings, whereas unit numbers can occur on many other kinds of buildings too. So address imports have tended to use addr:unit=* for consistency. We could swap one for the other, but the better fix would be to remap the buildings in more detail, with points inside the building representing the individual units.
This isn’t supposed to happen in the mainland U.S. The apartment complex’s name wouldn’t appear in the address at all. But one of the common formats in Puerto Rico does start with the condominium name. As far as I can tell, a handful of addresses of this format are using addr:housename=* or addr:place=* for lack of an obvious alternative. Far more are stuffing this and other miscellaneous components in addr:housenumber=*, probably because iD only offers the standard mainland U.S. fields. Fixing this would be difficult given how many different formats are common in Puerto Rico.
