RFC: Proposal – building:units:bedrooms:* (apartment unit composition)

General talk Tagging general discussion
,
1

Hello,

I have drafted a proposal to extend building:units=* with structured bedroom distribution keys for apartment buildings.

The proposal introduces:

  • building:units:bedrooms:0=*
  • building:units:bedrooms:1=*
  • building:units:bedrooms:2=*
  • etc.

The intent is to allow mapping of the distribution of studio, 1-bedroom, 2-bedroom, etc., units within a building tagged building=apartments.

This proposal:

  • Extends the existing building:units=* key
  • Uses structured numeric values rather than compound strings
  • Is optional and backward-compatible
  • Is limited in scope to apartment buildings
  • Does not attempt to model market, rent, or occupancy data

Example:

building=apartments
building:units=25
building:units:bedrooms:0=15
building:units:bedrooms:1=10

Wiki draft:

Feedback is welcome on:

  • Namespacing structure
  • Scope limitation
  • Validation expectations
  • Overlap with any existing practices

Thank you for any comments or suggestions.

1 Like
2

You will certainly get questions about where this data is to come from, and how it can be verified by other mappers. Being somewhat familiar with this space, I’m guessing it’s intended to come from official development permits which are public?

Another concern is that counting bedrooms is a rather geographically/culturally-specific phenomenon. In many places around the world, apartments are defined by number of rooms instead (usually excluding kitchens and bathrooms), so an unambiguous number of bedrooms might not be public or obvious. For example Germany, but also Québec. Sometimes the definitions don’t translate cleanly, e.g. when there is a dining room or another room that’s not really suited to being a bedroom.

9 Likes
3

Please also consider that vast majority of uses of building:units=* is in Los Angeles (from a one-time import), and building:flats=* is much more common worldwide, so using flats in the proposed keys might be more international.

3 Likes
4

I have the same concerns as @Jarek: “bedrooms” is not a common measure in many places. Any tagging scheme should be able to accommodate this.

He’s also right, that the correct base key would be building:flats. But instead of having an own tag for each size of flat, I’d suggest having a single tag with all information. For most data consumers it’s a minor detail. Those that are interested can take the effort to parse a slightly more complicated value that contains a list of all sizes and counts.

1 Like
5

I agree with @Jarek that since building:flats being the key to count how many flats/units are within a building, we should use “flats” and not “units”.

What’s the reasoning for going with building:flats:bedrooms:1=* instead of just building:bedrooms:1=*? Or should we use both, depending if the building is an apartment (multiple units) or a house (no units)? okay you say this tagging is not for single-family dwellings. I think if we wanted to extend it to single-family dwellings we could go with building:bedrooms=*

What’s the meaning of building:units:bedrooms:0=* would that be for commercial units that aren’t for overnight use? sorry you answer that is for studio apartments.

Other than that I think this is a good thing to map and the tagging in general seems okay. Having a breakdown of units of each bedroom count is more useful than just knowing the total bedrooms for the building.

Of course this should only be populated with compatible sources (and just because the information is available to the public, doesn’t mean it clears the licensing requirements), and if those don’t exist it might make it difficult to actually map or verify this, but that shouldn’t stop us from mapping it.

If some regions this doesn’t make sense to map, it doesn’t need to be mapped, it could be a regional thing.

1 Like
6

I quite like it. I think unit mapping for apartments is already wildly under-utilised, and data like this is actual useful data.

As others have said though, gathering that data and verifying it could be quite hard. Maybe also include an “unknown” or “unverified” tag? This way someone can search by that unknown, instead of the common assumption in OSM of “If data is there, it must be correct”.

E.g.
building=apartments
building:units=45
building:units:bedrooms:0=5
building:units:bedrooms:1=15
building:units:bedrooms:2=15
building:units:bedrooms:unknown=10

While I half agree with the other statements about trying to define “what is a bedroom” might be difficult on an international scale, I see no issue with going with what a local area uses as its definition. I live in a two bedroom house, despite one room being as study with no bed in it (I sometimes fall asleep in my office chair though!) it is still a 2 bedroom house.

1 Like
7

How do you distinguish between as-built, and owner-renovated number of bedrooms (split or combined rooms later)? The latter has more verifiability and privacy problems. Is it available from your government data too?
Implementation details: Comment on naming and format Talk:Proposal/Building units bedroom distribution - OpenStreetMap Wiki

1 Like
8

deleted as offtopic

9

The general idea is interesting, but, as others mentioned, the standard way of counting varies from one region to another.

10

Oh no, please don’t! That would be a total mess of dozens of keys.
If different sections or levels of buildings differ from each other, we already have the building:part tagging scheme.

11

As mentioned by others in this thread, the counting of bedrooms is really more a classification system.

A tag like building:flats:class:<classification>:count=* looks cleaner to me. What exactly <classification> is can then change from region to region (like e.g. zero_bedrooms vs two_rooms or even country prefixed with DE:two_rooms).

From a mapping perspective, mappers can only really map their own homes, so that would be quite privacy-invasive. As such, this data would mostly come from imports, which can be fine, but then there should be users of this data which also take on the responsibility for updating it (e.g. realtors could receive feedback from customers that the data is wrong and then manually correct it).

12

Even two_rooms can mean different things in the same country.

Within a region, there shouldn’t be much of an issue.

13

The counting of floors/levels also varies from one region to another, but it is specified in the osm wiki how to count them to get a unified building:levels data.

1 Like
14

Thank you for the suggestion.

I believe there may be a conceptual mismatch between what this proposal aims to describe and what building::* tagging is typically used for.

The current proposal does not attempt to describe attributes of specific physical floors within a building. Instead, it describes the distribution of dwelling units by bedroom count across the entire building. The bedroom count is a property of the dwelling units, not of a particular structural level.

For example:

building:units=25

building:units:bedrooms:0=15

building:units:bedrooms:1=10

This does not imply anything about which floor those units are located on. A building may have studio units on multiple floors, and one-bedroom units distributed vertically in various configurations. Therefore, introducing a level-based namespace such as building:1:* would change the semantic meaning of the data.

The sidewalk:left:* and parking:right:* patterns describe spatial orientation relative to a linear feature. In contrast, bedroom count represents typology of internal dwelling units and is not inherently spatially ordered in the same way.

Regarding building:1:bedrooms, that structure would imply that the first floor itself has bedrooms as a property, rather than expressing how many units of a certain bedroom type exist in the building. The proposal’s intent is to count unit types, not to describe the number of bedrooms per floor or per unit.

I agree that in the long term, mapping dedicated objects for each floor could allow more detailed modeling. However, widespread floor-level object modeling is currently uncommon in OSM, and this proposal is designed to operate at the same abstraction level as building:units=*.

If there is concern about namespacing clarity, I am open to discussing refinements. However, I believe level-based tagging would represent a different data model than the one being proposed here.

1 Like
15

Thank you for the thoughtful feedback.

On classification vs. bedroom count

It is correct that bedroom count functions as a form of dwelling classification. However, the proposal intentionally uses numeric bedroom counts because they represent a structural characteristic of the dwelling units, not merely a market label.

Allowing to vary regionally (e.g., zero_bedrooms, two_rooms, DE:two_rooms) would reduce interoperability and comparability. One of the primary goals of the proposal is to provide a neutral, machine-readable structure that can be queried consistently across regions.

Numeric bedroom count:

Is internationally understood

Avoids language-specific terminology

Avoids regionally varying housing classifications

Minimises ambiguity in interpretation

Introducing region-specific classification values may increase flexibility, but it would significantly reduce data consistency and cross-border usefulness.

On privacy concerns

The proposal applies only at the building level and does not describe individual dwellings. It records aggregate counts (e.g., 15 studio units, 10 one-bedroom units) rather than linking bedroom counts to specific apartments.

This is comparable in granularity to:

building:units=*

building:levels=*

Neither of which is considered privacy-invasive when derived from publicly available or observable sources.

In most cases, the data would come from:

Public planning documents

Development filings

Official housing registers

Published building specifications

The proposal does not encourage mapping of private interior details of individual residences.

On imports and data maintenance

It is true that much of this data may originate from structured sources. However, this is already the case for many building attributes (e.g., unit counts, levels, construction year).

As with any imported or structured dataset, normal OSM best practices would apply:

Community review

Clear documentation

Update mechanisms

Local mappers verifying where possible

There is no requirement that realtors or commercial entities maintain the data. Like other building metadata, it would follow standard community maintenance patterns.

Summary

The intent is not to introduce a market classification scheme, but to extend an existing structural building attribute (building:units=*) in a consistent and internationally neutral way.

If the community prefers a different namespace structure, that can be discussed. However, introducing region-dependent classification values may reduce the clarity and interoperability that the proposal aims to achieve.

I welcome further discussion on how to balance flexibility with consistency.

16

Thank you for raising these points.

On data sources and verifiability

Yes, in many jurisdictions this information is available through publicly accessible sources such as:

Development permits

Planning applications

Zoning filings

Environmental review documents

Official housing registers

These documents commonly include a breakdown of unit types (e.g., number of studio, 1-bedroom, 2-bedroom units).

This proposal does not assume universal availability of such data. Like building:units=* and building:levels=*, it is intended to be mapped where reliable sources exist and omitted where they do not.

Verifiability would follow standard OSM principles:

Use publicly available, documentable sources

Avoid speculative tagging

Reference sources where appropriate

The fact that some data may come from structured public records does not differ in principle from how many building attributes are already mapped.

On geographic and cultural variation

It is correct that some regions classify dwellings by “rooms” rather than explicitly by bedrooms. However, this proposal does not attempt to redefine local classification systems. It proposes recording bedroom count only where that information is available and unambiguous.

Numeric bedroom count is used here because:

It is widely published in many jurisdictions

It avoids language-specific labels

It avoids ambiguous marketing terminology

Where official documents define dwellings by total rooms instead of bedrooms, this proposal would simply not apply unless bedroom count is explicitly specified.

It is not intended to force reinterpretation of regional housing systems.

On ambiguity (e.g., dining rooms, multi-purpose rooms)

The proposal assumes bedroom count only when explicitly defined in source material. It does not require mappers to interpret whether a dining room “could be” a bedroom.

If a planning document specifies:

20 two-bedroom units

10 three-bedroom units

Then those values may be recorded.

If only total room count is available and bedroom count is not specified, no bedroom tagging would be added.

Scope clarification

This proposal is optional and additive. It does not:

Replace room-based classification systems

Require conversion between classification models

Imply global uniformity

It simply provides a structured method for recording bedroom distribution where that information is already defined.

If there is interest in modeling room-based classifications separately, that could be discussed as an independent proposal. The current proposal is intentionally narrow to avoid conflating different housing typology systems.

17

Thank you for the support and the thoughtful suggestions.

On including an unknown category

I understand the motivation for an explicit unknown value, particularly to avoid the assumption that missing data implies completeness.

However, in OSM practice, absence of a subkey generally already indicates incomplete information rather than confirmed non-existence. Introducing:

Copy code

building:units:bedrooms:unknown=*

may introduce ambiguity:

Does “unknown” mean the mapper could not determine it?

Or that the source explicitly states unspecified unit types?

Or that the breakdown was once known but is now outdated?

It also risks encouraging partially speculative completion of totals.

An alternative approach could be encouraging documentation via:

source=*

note=*

or proposal documentation clarifying that breakdowns are optional and may be incomplete

This keeps the tagging model simpler while still acknowledging uncertainty.

That said, I am open to community preference if there is strong support for explicitly representing remainder counts. If adopted, it should be clearly defined to avoid multiple interpretations.

On local definitions of “bedroom”

I agree that local definitions should prevail. The proposal does not attempt to redefine what constitutes a bedroom internationally. Instead, it assumes that if a source describes units as “two-bedroom” or “three-bedroom,” that classification can be recorded as-is.

As with your example, whether a room is currently used as a study or contains a bed is irrelevant. What matters is the structural classification used in official or published documentation.

The proposal does not require mappers to interpret floorplans. It relies on explicit classification in source material.

Summary

The intent is to provide:

A structured extension of building:units=*

Numeric, internationally neutral values

Optional usage

Compatibility with local housing terminology

Questions about completeness and uncertainty are important, and I appreciate the suggestion. The priority is maintaining clarity and avoiding additional ambiguity while still being practical for real-world mapping.

Further discussion on whether an explicit “unknown remainder” improves or complicates the model is welcome.

1 Like
18

Thank you for raising this — it’s an important distinction.

As-built vs. later renovations

The proposal is intended to reflect the structural configuration of the building as defined in authoritative sources, not ad hoc interior modifications by individual occupants.

In practice, this means:

Using officially recorded unit typology from development approvals, planning permits, or housing registers.

Not attempting to capture interior changes made by individual owners or tenants.

Not surveying private interiors.

This mirrors how we already treat other building metadata:

building:units=*

building:levels=*

start_date=*

These typically reflect officially documented structure rather than undocumented alterations.

If a building is formally renovated and permits update the number or type of units, then the tags could be updated accordingly — just as we would update building:flats=* after a legally permitted conversion.

Informal interior changes would not be mapped.

Verifiability and privacy

The proposal does not involve mapping the bedroom count of a specific, identifiable dwelling. It only records aggregate counts at the building level.

For example:

building=apartments

building:flats=45

building:flats:bedrooms:1=20

building:flats:bedrooms:2=25

This does not reveal which unit has which layout, nor who occupies it.

Where government datasets publish unit typology as part of development or zoning records, that information is already public. In many jurisdictions, this is standard in planning approvals.

If such data is not available or verifiable in a given region, the tags simply would not be used.

On implementation and naming

The current naming (building:units:bedrooms:*) was chosen to:

Clearly extend building:units=*

Avoid compound string parsing

Preserve numeric bedroom counts

Maintain international neutrality

If there is strong consensus that the namespace should be adjusted for clarity or consistency with other multi-level patterns, I am open to refinement. However, level-based tagging (e.g., building:1:*) would model floor attributes, which is a different concept than building-wide unit typology.

The proposal aims to stay at the same abstraction level as building:units=*.

In summary, the intention is to model officially defined building configuration at an aggregate level, not to track interior modifications or private living arrangements. If the community feels additional clarification is needed in the proposal text to prevent misinterpretation, I am happy to incorporate it.

19

Ah, OK, I’m not going to bother talking much to an LLM.

This proposal seems to suggest tagging what’s easy to tag, rather than what’s useful.

If you want to do data collection and collation on unit size distribution, it might be easier for you and for others to do it outside of OSM.

2 Likes
20

I want to clarify something up front: there is a human behind this proposal.

I am using an LLM as a drafting tool to help structure and refine ideas, but the proposal itself reflects my thinking, judgment, and intent. The model helps turn rough ideas into coherent text; it does not originate the concept or make decisions on my behalf. I remain fully responsible for the substance and direction of the proposal.

Regarding the substance of your comment:

The goal here is not to tag what is merely easy to tag, but to extend an existing structural building attribute (building:flats=*) in a consistent way where reliable, public data already exists. The proposal is intentionally narrow and optional. It does not require speculative surveying, nor does it attempt to model interior layouts at flat level.

If the community ultimately determines that this type of data belongs outside OSM, that is a valid outcome of discussion. However, OSM already stores comparable aggregate building attributes (levels, flats construction year), and this proposal is positioned as an extension of that same abstraction level rather than as a new conceptual direction.

I’m happy to continue discussing the merits of the idea itself. If there are specific technical concerns with the tagging structure or scope, I’d appreciate engaging on those directly.