Talk:Key:addr:flats

Literal addr:flats=* ?

There were only two nodes tagged with literal addr:flats=* (asterisk). I've removed that tag, as it creates more confusion.

• https://www.openstreetmap.org/node/6363633348/history
• https://www.openstreetmap.org/way/155182669/history

--Richlv (talk) 11:23, 16 March 2020 (UTC)

Exceeding 255 characters

Because OSM tag values are limited to 255 characters this can create a problem with this tag. eg. a 30 story building with unit numbers on level 10 being 1001-1014 repeated for 30 floors has to be expressed as `1010-1014;2010-2014;...`, so for an import I've proposed just using addr:flats2 addr:flats3 etc to split up the values. Not great, but I can't see any other alternative. --Aharvey (talk) 08:30, 18 June 2021 (UTC)

Use without entrance=*

According to https://taginfo.openstreetmap.org/keys/addr%3Aflats#combinations only 50% of addr:flats are on an entrance node. 20% are on a building. So it appears this tag is being used in other non-entrance scenarios. In my opinion the wiki should follow current mapping practice and not stripulate that it's only on building entrances.

In my view addr:flats should go wherever the addr:housenumber is unless there are multiple entrances to a building each with access to different flats. If I've only mapped an apartment building as a single address node but know the flat numbers at that address then I can just include it on the addr:* node. If there is a single apartment building where I don't know the entrance or there are multiple entrances all with access to the units, then I can simply include addr:flats on the building=* way along with all the other addr:* tags.

See also https://github.com/gravitystorm/openstreetmap-carto/issues/4160

---Aharvey (talk) 04:10, 23 June 2021 (UTC)

I agree, and in fact I have frequently used this tag on building areas as well as nodes - I wasn't aware of this stipulation. I think it should be changed to include areas. --Libarch (talk) 09:27, 23 June 2021 (UTC)

As of the date of this comment, if you apply the tag addr:flats to the building way (instead of any entrance), OSM Carto does not render the flats with the building name. Kevinp2 (talk) 17:01, 28 June 2025 (UTC)

flat code with - sign

What should be done if flat code includes - sign, for example range where start code "320-1" and ending code is "320-21". Range is poorly defined anyway, so maybe one should give up?

(case is theoretical but definitely existing somewhere)

Mateusz Konieczny (talk) 13:21, 7 April 2022 (UTC)

I know this is often complained elsewhere. For mitigation, can you expect addr:flats=320-1-320-21 to be a symmetric range? Or can it be addr:*=320 + addr:flats=1-21? Just that they are assigned together for convenience. --- Kovposch (talk) 06:55, 8 April 2022 (UTC)

Two Entrances

What should I do if there are two separate entrances to a number of flats? Should I alos tag this entrance with the same info for addr:flats? IanVG (talk) 21:56, 28 April 2022 (UTC)

In my opinion - yes. It is nor marking flats itself, it is marking what is reachable from entrance Mateusz Konieczny (talk) 19:36, 29 April 2022 (UTC)

addr:flats:level:N=* and addr:flats:level:ref:N=*

In large residential towers, listing out unit numbers easily becomes too overwhelming for a single addr:flats=* tag.

I think splitting the tag values up by floor/level is a good way to keep the tag value easier for mappers to manage, while also adding interesting data for data consumers, without requiring the complexity of full indoor mapping.

Tagging would follow level=* or level:ref=* (mappers preference based on what makes the most sense to use) like addr:flats:level=* or addr:flats:level:ref=* addr:flats:level:<physical floor number>=* or addr:flats:level:ref:<signposted floor number>=* (edited) where the value is the same as addr:flats=* but for that level only, ie. a list of the flat/unit numbers at that building at that level.

While it can be argued this kind of complete address data is not suited to OSM or doesn't belong, I think if we do decide to include it then this is how we could do it in a better way for mappers. Aharvey (talk) 05:00, 18 December 2024 (UTC)

• addr:flats:*=* : Although it seems an obvious choice, I thought it could also mean the level=* or level:ref=* each addr:flats=* range is on
  • addr:flats:level:ref=* : *:ref=* is redundant. It has no use here.
  • addr:flats:level=* : level=* means the levels a feature belongs to. It won't be nice to change the meaning in the suffix.

In my experience, I came across more mistakes in building:flats=* as number of flats per floor. This is likely caused by iD's simplistic label of "Units", and the examples being small numbers that would be mistaken for number of flats per floor in large apartment buildings. addr:flats=* and building:flats=* should find a standard solution.
Inventing something clearer eg *:per_level=* might be more beneficial. In any case, consideration has to be given to floors with different number of flats. It gets complicated.
Besides, this interfaces with floors. For counting all floors, there's already problem with non_existent_level=* , that seems to be incompatible with how level=* is defined against building:levels=* , and the existence of level:ref=* ; different format with other tags; and Talk:Key:non existent levels#non_existent_levels_in_the_US confusion on whether it refers to level=* or level:ref=* . Then we need to specify which floors are non-residential.
—— Kovposch (talk) 08:42, 18 December 2024 (UTC)

Is there an argument that prevents us from having several nodes with addresses, one for each level? That would work with all the existing geocoding software, although it might raise some warnings about duplicate addresses in current QA tools. --Mueschel (talk) 09:10, 18 December 2024 (UTC)

You aren't realizing the scale of the question when you suggest "several" and "one for each level". We are talking on the order of tens of floors. That can be the norm for some cities.
—— Kovposch (talk) 09:50, 18 December 2024 (UTC)

Sorry my examples were not clear I meant addr:flats:level:<level number>=list or range of unit/flat numbers on that level and addr:flats:level:ref:<signposted level number>=list or range of unit/flat numbers on that level. Hopefully the X:level:<level number> would change it so that the tag value represents the value of the key X at that level, not the level number of the feature. Aharvey (talk) 10:20, 18 December 2024 (UTC)

The idea of supporting both level=* and level:ref=* being sometimes you want to know the physical level number for rendering/visualisation, but othertimes you want to know the number you'll see on the elevator button. Because of the way these two tags are described you can have level=2 but the elevator button says 3, hence level:ref=3. Aharvey (talk) 10:22, 18 December 2024 (UTC)

You don't need both of them - the information how numbers and ref's relate to each other is already available from the level:ref tag on the building, there is no need to duplicate this information in the addr:* tags. --Mueschel (talk) 10:41, 18 December 2024 (UTC)

Those tags would only exist if there has been some indoor mapping, which may not be the case. Regardless when mapping I might not know which floor level=0 was set on, so I might just add level:ref=* as I know what the signposted level number is. It's the same reason why in StreetComplete I can't add level=* but I can add level:ref=* to shops etc. I think best to be flexible so mappers can use the one they know at the time. Aharvey (talk) 11:01, 18 December 2024 (UTC)

The rationale is to make it easier for mappers to enter the data, and understand it and change it. 80 overlapping nodes one for each level of the building is not going to be easy to edit/QA. A 2000 character tag value split across 10 key suffixes is slightly better, but still not great. But 80 keys on the one node/way, each with a short value, much easier to work with. Aharvey (talk) 10:26, 18 December 2024 (UTC)

The last sentence still seems ironic. List out every floor is half-way there in terms of scalability, not a very good solution yet.
Number suffix is usually not a good idea. Anecdotally, there's the year suffix for history or life cycle, and there will technically be a slight conflict if someone suggests a floor range suffix addr:flats:level:1-2=A;B
—— Kovposch (talk) 09:22, 19 December 2024 (UTC)