Picking up where #653 left off...

We want to add root_id for building and building_part features within building relations.

@meetar pointed out the Bank of England building at http://tangrams.github.io/explorer/#17.0/51.5143/-0.0890/osm_relation/true:

In our tiles, the inner and outer shapes here seem to be split into two features, correlating to
https://www.openstreetmap.org/way/4959510 and https://www.openstreetmap.org/relation/553472, but with no root_id or other node which would associate them with each other.

@zerebubuth followed up with details:

Looks like there's a whole mess of things going on with the BoE building:

• Relation 553472 is a multipolygon relation, with building=yes, amenity=bank and osm2pgsql puts it in the polygons table.
• Way 4959510 is an outer of the above relation, but since it has different tags from its relation, (building=public), osm2pgsql cautiously retains it. This means there's a second polygon in the polygons table with the same outline as relation 553472 but without the holes.
• Relation 2917677 is also present and although it doesn't have any tags itself, osm2pgsql processes it to "steal" the tags from its outer (way 220644664), so it also ends up as a building.

I think we have two different issues here:

1. Relation 553472 and way 4959510 are both included as buildings due to a combination of tagging and how osm2pgsql interprets that tagging.
2. Relation 2917677 is an additional building on a similar footprint to relation 553472, which seems like it should be linked to the latter although it's not a building:part, and there's no relation linking them or containing them both (e.g: a "site" relation).

If this isn't a widespread problem, I'd be tempted to call it a data issue rather than introduce a special case to handle it. Although it would be nice to be able to present problems like this in a way that makes it easy for people to find and fix.