Building Footprints vs Roof Areas: Best Practices 2024+

General talk
1

Hello everyone,

I have taken a good look around forums for information on this topic, but can’t find an authoritative source.

Looking for community input!

The Status Quo: 2D

  • Historically, OpenStreetMap buildings seem to have been mostly mapped using the building roof area.
  • This makes sense when digitising via satellite imagery, particularly for machine learning models trained to predict based on the roof of buildings.

digitise-buildings

For example, this answer describes the above.

3D Mapping With Cheap Drones

  • Drones are becoming increasingly affordable, with consumer models that can generate extremely good quality imagery (far supassing anything satellites can achieve), coming well below $1000.
  • This is particularly relevant in areas of the world that have been poorly mapped historically, such as developing countries with no data or data extracted via satellite imagery only.

(post split into multiple parts due to user limitations…)

1 Like
2

What Is Possible Now

  • Using a combination of nadir (straight-down) and oblique (at an angle) imagery, we can easily generate a 3D mesh to an area.

Image-acquisition-from-nadir-and-oblique-cameras-The-coverage-of-nadir-images-is-shown-1

  • This includes the sides of buildings, areas under roof overhangs, hidden buildings under vegetation, etc.
  • With this information, it is quite easy to extract the actual building footprint, meaning where the walls meet the ground.
  • This has been possible for a while now, but the key factor here is the affordability of this approach, which will become increasingly common around the world.
  • A few standards have been made around mapping 3D buildings, such as Simple 3D Buildings, and Proposed Roof Lines in OSM.
1 Like
3

Example 3D building model:

500px-Roof_diagram

1 Like
4

Example of a roof overhang (where 3D imagery would be extremely useful):

IMG_20240323_173615_355
IMG_20240323_173615_3551920×1440 274 KB

(note here we have both an extremely large overhang and overlapping roofs in one!)

1 Like
5

Implications & Question

Typically a national mapping agency would map the building footprints, as opposed to the building roof area - this is the norm for most maps outside of OSM.

Now we have the option to map either the building roof area (to be consistent with the rest of OSM), or map the building footprint (the most accurate data), which should we choose?

1 Like
6

Thanks Sam for bringing up this incredibly important issue, and for doing it in such a clear way with pictures, examples, and an invitation to an open discussion. This is great!

I think we all agree that the ideal would be to map a polygon representing where the outer wall of the building touches the ground. However, working from the imagery that OpenStreetMap contributors can usually access, this is impractical. It’s difficult to imagine how we could accurately estimate the overhang distance between building, roofs and outer walls anytime in the near future.

An idea that occurs to me is to simply embrace the fact that we can effectively digitize roof area, but tag it explicitly as such. In cases where we have 3D data, ground-based data, or some other way to accurately map the “true” footprint (where the outer wall touches the ground) we could tag it as such, and where we cannot, we can explicitly label the footprint is representing the roof area.

This could help resolve an issue that Sam has pointed out: overlapping building footprints are physically impossible, if they represent out of wall perimeter. But overlapping roof footprints are actually quite common, as in the photo he’s shown. This could help with validation; when you have an overlap, but both polygons are tagged as roof area rather than outer wall perimeter, it doesn’t necessarily represent a digitization error.

Keeping in mind that roof area is still useful; even though the outer wall footprint would be a better representation of the building, also, having a representation of the roof area is useful for assessing things like solar energy potential, water, runoff, etc. ultimately, in some cases, we might have to concentric polygons, one representing the roof area, and one representing the outer wall footprint (and someday in the future, hopefully we’ll have actual 3D models of buildings)!

Looking forward to hearing others’ thoughts and ideas on this!

2 Likes
7

Many OSM mappers also aim to map building footprints, not roof areas. A typical workflow is to trace a building’s roof but undersize it to account for overhang, then if any outer walls are visible due the angle of aerial imagery, move the polygon to align with the base of the walls. For example here’s the same building over two different imagery layers with different angles. The polygon is correctly aligned to the footprint, not the roof.

building-polygon-aligned-to-footprint-2
building-polygon-aligned-to-footprint-21700×1421 118 KB

building-polygon-aligned-to-footprint-1
building-polygon-aligned-to-footprint-11317×1082 92.1 KB

Obviously we can only be so accurate with aerial imagery tracing and educated guesses about roof overhang, but it is innacurate to say that roof area mapping is the norm in OSM. That may be the case in some areas, but I’d say those areas have room for improvement.

7 Likes
8

A porte-cochère over a driveway or an attached carport is often mapped as part of the overall building’s area as a first pass, either because the mapper is in a hurry or because the available aerial imagery isn’t oblique enough to clearly discern a missing wall. But eventually we would split it from that area as a separate building=roof or building=carport.

Mapping the overhang separately has some practical benefits, such as making it possible to attach an entrance=main node to a building area at the main entrance. Otherwise, the walkway might have to cross under a building ambiguously and end at a dangling entrance node. An entrance node could help a router send the user directly to the front door instead of somewhere less accessible that happens to be closer to the road. It’d be much more straightforward for a geocoder to associate that entrance with the building if it’s attached to the building.

A walkway, sidewalk, and driveway cross under a porte-cochère that has been mapped as an integral part of a hotel building. The walkway leads to an entrance node representing the main entrance door behind the porte-cochère, but the hotel façade is unmapped at this point, so the node is not connected to anything other than the walkway.
A walkway, sidewalk, and driveway cross under a porte-cochère that has been mapped as an integral part of a hotel building. The walkway leads to an entrance node representing the main entrance door behind the porte-cochère, but the hotel façade is unmapped at this point, so the node is not connected to anything other than the walkway.1600×1200 245 KB

However, beyond that, a data consumer might not be able to infer very much from even a perfectly mapped building footprint. After all, sometimes the “footprint” still opens up on the ground floor, typical in a dingbat:

2 Likes
9

I believe that it really depends on two criteria:

  • The quality of the source
  • The time the mapper is willing to invest

Some mappers only document buildings as points and it is still better than nothing. Eventually, when more detailed data or more patient mapper revisit the area, details can be added to the buildings.

2 Likes
10

Hello @spwoodcock

Thank you for this introduction and request for input.

I really admire your enthusiasm for accuracy and for picking up on this important fact of mapping a roof from imagery.

It would be great to be able to achieve the perfect life size accuracy but this has never been achievable simply because of the size of the storage required to hold it.

The reality of this is unachievable. To get the kind of accuracy you are talking about would require each individual building to be accurately measured and surveyed by a land surveyor fixing accurate coordinates for each corner of the building and the angle at the corner to align the walls. Why? Because each building can have a different size roof overhang depending on the style of the roof and the architecture of the region. Even then it is often impossible to identify where the sloping roof continues over a porch (veranda) or a car port (as can be seen in the pictorial examples given by Minh-Nguyen above.

We have to ask, are we producing a useful map or a survey accurate chart (database)?

I have in the past already stated that I believe that if we train AI to map from imagery we are teaching it rubbish. The correct route to take is to teach it to map from accurate data (e.g surveyed plans). The we will be achieving something that is far more reliable and accurate than reproducing the same errors from imagery that us humans also produce.

Am happy to discuss this issue further with you.

2 Likes
11

Very valuable responses - thank you everyone so far!

So to summarise the general sentiment: accuracy of OSM features has no strict standard, as it depends on what the user is able to produce. We probably don’t need surveyor-level accuracy for now, but definitely strive to be as accurate as possible! It’s great that OSM is very flexible.

Possible solution: correct tagging

  • The user can map to any level of accuracy, as long as it’s tagged correctly.
  • Tags can be building=roof, building=carport, etc, as mentioned by @Minh_Nguyen

So depending on the input data, we could go from a simple building=yes tag → subdivided building into parts:

image
image979×391 19.3 KB

1 Like
12

As @IvanGayton mentioned, we could feasibly have this scenario of roof overlap:

image
image802×405 27.8 KB

@IvanGayton if you have any good screenshots of building footprints derived from drone imagery (i.e. removing the roof in the 3D model), it would be very useful for clarification / illustration of my point above (showing what is possible) :pray:

1 Like
13

Hi,
I don’t want to jump into the whole discussion, but I want to mention one thing:
Maybe it’s just your graphic, however, if you want to tag the roof and the lower levels separately, you should use building:part= instead of a pure building=*.

1 Like
14

Thanks for the extra context @Robert46798!

So for the above, if we used:

  • building:part=detached
  • building:part=roof
  • building:part=carport

The reference suggests we should also include an outline for all combined parts.
Would building=yes be appropriate?

Then all of the above polygons should also have the type=building tag.
Is this correct?

15

In addition to the comment of @Robert46798, I would also like to point out that, in my opinion, there are two ways of dealing with such situations - as far as I can see, neither of them is clearly recommended or undesirable. However, both should only contain one single building=* geometry, which is differentiated by any number of building:part geometries:

  • The building geometry includes all parts of the building, including overhanging or protruding building parts (which should be marked as building:parts with building:min_level and/or min_height or for which it is clear from the tagging e.g. building:part=roof that they are not in contact with the ground).

  • Individual overhanging/floating building parts are mapped outside but adjoining the building geometry and grouped with it via a building relation. (I would say that this variant is rarely used).

grafik
grafik900×487 54.4 KB

In variant 1, the building outline corresponds to a kind of “projected” area of all parts of the building, in variant 2 the building outline corresponds more to the footprint (but does not have to). In any case, the OSM building data should not be understood as footprints. In the Neuköllner Straßenraumkarte, for example, a very high-resolution local OSM map, I render footprints and floating building parts separately, but have to generate them using post-processing:

grafik
grafik1040×484 79.5 KB

However, the documentation on this specific issue is not very detailed and sometimes contradictory - so I would say there is potential for clearer documentation and possibly standardization.

building=detached would be good, as the building outline should carry all the “general” characteristics of the building. After all, the building as a whole remains a detached house. The total height, (highest) number of levels etc. should also be tagged there. building:parts then only carry attributes that deviate from this “general” value.

type=building is only used in building relations (see above: variant 2). Usually you don’t need them if the building is not an extremely complex structure with many different parts.

2 Likes
16

The OSM features wiki says:

“In OpenStreetMap, a building is a man-made structure with a roof, standing more or less permanently in one place”

“The most basic use is building=yes, but the value may be used to classify the (architectural) type of building”

And then explains that you can use building=hospital , building=house, etc, so you can describe its function.

I think that if the building is not defined as “where the walls meet the ground”, is not wrong to use the roof and even to include other parts of the building that are uncover but are part of the main building. Then, for a more detailed mapping, you can use building:part like building:part=roof or building:part=retail for describe it’s function.

1 Like
17

With the OSM volunteer mapper who, in many cases, will not understand any of this subdivision of a building we are going to have cases where they will delete the complex subdivision and redraw a single building=yes. That is what is being taught to new mappers.

For more complex detail like this I would suggest this “expert” detail should be moved to a separate instance of OSM like an OpenBuildingMap. There we can have far more complex building data without the concern that it will be changed or removed by others.

And for accuracy of a building have we considered how to identify and add cellars or underground parking which would also be a part of the building. Even with oblique drone imagery we will not be able to identify whether a building has this addition.

Please do not get me wrong, I am all for accuracy in mapping. I am just concerned that this is taking it out of the realm of ordinary mappers and the original concept of a base map that everyone can use.

This level of detail will be useful to some map users but will be “clutter” to most.

2 Likes
18

Who is teaching this procedure? To me it sounds like vandalism. It is clearly stated that you may not delete things that you do not understand.

Don’t remove tags that you don’t understand

Sometimes you will come across elements with tags that have no meaning to you. This doesn’t automatically mean you should remove them. They may have been added for a specific purpose. If you think they might be junk then try to contact the author. See also: Chesterton’s fence on Wikipedia.

Don’t remove objects that you don’t need or like

Be brave in what you add but careful in what you delete. Someone added a catenary mast or a manhole? And you think it’s stupid or unnecessary because it doesn’t display on the map? Inaccurate mapping is not forbidden, but you certainly should not work the other way and remove details that someone else added. It is known that not everything is always needed by everyone, but you should not remove something just because you do not need it / you think it is stupid / the validator ordered it so.

from Good practice - OpenStreetMap Wiki

6 Likes
19

Please no!

The original concept of OSM was not “a base map that everyone can use”. The original concept of OSM was to provide geodata without the restrictions that are “holding back people from using [it] in creative, productive, or unexpected ways”.

Personally I don’t need the super-detailed building data either, but I deal with that by algorithmically simplifying it, not by trashing the source data and therefore holding back people from doing creative, productive and unexpected things with it.

(Here’s an example of Reims Cathedral with a building-specific simplification process applied. The algorithm will be in a future version of tilemaker. :slight_smile: )

output copy
output copy1200×918 38.6 KB

(edit: this same argument back in 2009)

6 Likes
20

My apologies, I did not elaborate.

Beginners are taught to map what they see on the imagery. They see the single roof and that is what they map. We do not teach them to delete data. iD Editor does not have the luxury of a “replace geometry”.

They do NOT vandalise the map. I deal with and assist and help mappers at all levels. Not many started out knowing everything there is to know about OSM mapping but still do add some extra data to the map and some do go on to become more discerning in their mapping.

4 Likes