Defining Building Subtype/Class from OSM tags

[brian-spaulding]

When conflating the OSM data, the building attributes map to the OSM building tag values. However, what about buildings that are really defined by tags other than building?

For example, storage tanks. In OSM, although there is a building=storage_tank, it's use is discouraged. Instead, the convention seems to be to use building=yes and man_made=storage_tank. There is an OvertureMaps Buildings class for storage_tank.

A similar approach is used for radomes, where it is building=yes and tower:construction=dome, or radar dishes, where it is building=yes and tower:construction=dish. OvertureMaps does have a building class for these, but there is a radar class in infrastructure. However, the features do end up in the Buildings theme.

Is there any way to use multiple OSM tags to better set the appropriate subtype and class values? Currently, OvertureMaps data show these with null subtype and class. Are there any plans to add more complex tag mapping when conflating the OSM data?

Some examples:

• https://www.openstreetmap.org/way/311684132
• https://www.openstreetmap.org/way/235874553

[danabauer]

Hi @brian-spaulding. In case you haven't seen it, here's our existing documentation about tag mapping in the building and infrastructure types. Right now we don't have immediate plans to add more complex tag mapping or cross-theme/type tag mapping, but that could change depending on the interests and priorities of Overture's member companies.

[brian-spaulding]

Yes, I had read the schema concepts pages and was actually why I was asking. As the Building page points out, "most commonly, the value is simply, building=yes". If you're rendering this in 2D, a simple outline of the building footprint might be acceptable. In 3D, if you are just rendering as simple extruded polygons, this still may be the case. However, if you're trying to render in 3D as any kind of realistic way, this really is not good enough.

In OSM, sometimes the combination of tags provides the semantics of what that building is rather than just the simply looking at the building tag. So, using that information, having more options in the Overture Building schema, and using multiple attributes to more precisely define the Building type/subtype/class or, alternatively, being able to carry more of the OSM tags into the Building object would be useful.

In the storage tank example that I had referenced, https://www.openstreetmap.org/way/311684132, the OSM data has 16 tags, with building=yes and man_made=storage_tank so you can determine that it is not just a generic building. However, in the current Overture data, it is just type=Building, with the majority of the other attributes being NULL.

Note that, because of the other data that Overture conflates, the Building does have a height, which is missing in the OSM data. So, it would be extremely useful to have all the OSM data plus the other conflated data in the object.

[danabauer]

Thanks, @brian-spaulding. As part of GERS (Overture's Global Entity Reference System), we release bridge files that link Overture buildings to OSM buildings by ID. This should help you capture the additional OSM tags that are not included in Overture's published data.

[brian-spaulding]

OK, interesting. Yes, we might be able to make use of that in a pre-processing step. Thanks.

[danabauer]

Great! Let me know how it works for you.