Creating Building Parts from OpenStreetMap Data

In Overture, 3D building parts must be associated with specific buildings. This relationship is captured in the schema where the building's attribute has_parts is True and each of the building_part features has a building_id pointing to the id of the building it belongs to.

Although OpenStreetMap (OSM) offers a building relation (relations with type=building) to help facilitate this association, it is seldom utilized. We therefore perform 2 steps to associate a building_part to a building:

1. Explicit Assignment (relations)

1. Identify OSM relations with type=building that contain exactly one member with role=outline and at least one member with role=part.
2. Ensure the outline is either a way or a multipolygon relation with valid geometry. This is becomes a building type with has_parts=True.
3. Assign the building_id of the outline to each role=part feature, these are of building_part type features.
4. Identify any other building_part features that are spatially contained by the building outline and assign the building_id to them, even if they are not listed explicitly in the relation's members list.

2. Implicit Assignment (spatial containment)

1. Ignore any outlines/parts ways/relations that were assigned in the explicit method.
2. Identify all ways or type=multipolygon relations with a building tag not equal to "no" as a building.
3. Identify all ways or type=multipolygon relations with a building:part tag not equal to "no" as a building_part.
4. Perform a spatial join to find all building features (from step 2) that completely contain at least one building_part feature (from step 3).
   1. Assign has_parts=True to each building and add the corresponding building_id to each building_part.
5. Omit any parts that are not contained by an outline, as Overture does not allow orphaned parts without a known parent.

---

Finally, we eliminate all parts that are the only part associated with a building and share the same geometry as the building. This step helps filter out many OSM buildings tagged with both building=yes and building:part=yes if no other parts are associated with the building.

Considerations

• Geometric Accuracy: Due to discrepancies in how spatial functions interpret containment across different query engines, a small buffer might be applied to the building geometry to ensure parts are appropriately included.
• Data Integrity: Ensure that all data manipulations preserve the integrity and accuracy of the original OSM data, adhering to both Overture and OSM standards.

Known Issues

• Dual Representation: OSM features with both building and building:part tags are considered both an outline and a part, resulting in two separate Overture features (a type=building and a type=building_part) referring to the same OSM object. Although they are the same OSM object, they will be represented in Overture as two separate objects with different IDs.
• Ambiguous Height Tags: When type=multipolygon and building:part=yes, it is impossible to determine what the height tag refers to. It may refer to the height of the entire building (the highest point of all parts) as stated in the OSM wiki, or in some cases, it refers to the height of the part. It is recommended to either remove the height from such features or split the features into a building and a separate part feature and assign the proper height to each. In these cases, Overture will assume the height is the height of the building as stated in the wiki.
• Tag Ambiguity: When type=multipolygon and building:part=yes, it is impossible to know whether the characteristic tags refer to the building or the building part. It is recommended to either remove the tags from such features or split the features into a building and a separate part feature and assign the proper tags to each. In these cases, Overture will assume that each tag refers to both.