Unify building parts with building

[rmarianski]

In the buildings layer, it would be useful to know the building that all the parts were associated with. This can be done by seeing if the building:part overlaps a certain amount with any buildings in the
tile.

[nvkelso]

This can be tracked directly with the building relation per building part. SF example: Ferry Building.

We added root_relation_id for transit stations in v0.9, let's reuse the property & extend the logic for buildings.

[rmarianski]

The problem is, at least in nyc, the buildings and their parts aren't always linked with a relation. For example: http://www.openstreetmap.org/way/160967745

[zerebubuth]

Yup, the logic required is more similar to #142. We might be able to use the "base" building outline as the "root ID", depends on whether we find that many building parts overlap multiple "base" buildings.

[nvkelso]

Related: #886

[nvkelso]

It's sounding like we should say root_id (and rename the transit root_relation_id to root_id).

[nvkelso]

@meetar I remember you were interested in this one? Can you please have a look at dev tiles to verify this one this week?

New source url setup to use is:

• http://tile.dev.mapzen.com/vector/v1/all/{z}/{x}/{y}.mvt

[meetar]

This is great news!

I see some things which make sense here, such as features with a building_part: yes tag plus a root_id tag pointing to the root feature.

But then I see some others which simply have an osm_relation: 1 tag instead, such as 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.

Should this kind of situation have been fixed in the changes mentioned above, or is this a separate issue?

[rmarianski]

So far it only unified building parts with the building they overlap with. Sounds like in addition to that logic, we'd want to also link buildings / parts to any relation that they are a part of? And I assume that we'd prefer to use any relation as the root id in ambiguous cases?

[zerebubuth]

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.

[meetar]

Ah ha – The tagging looked odd to me but I couldn't tell how, thanks for
unraveling it. I can do some more investigating to see how common that kind
of thing is, I believe I ran into a few others like it but I didn't keep
track… but I concur, adding ad hoc logic will give us an infinitely-long
rule set.

On Tue, Aug 30, 2016 at 7:37 AM, Matt Amos notifications@github.com wrote:

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

• Relation 553472 https://www.openstreetmap.org/relation/553472 is a
  multipolygon relation, with building=yes, amenity=bank and osm2pgsql
  puts it in the polygons table.
• Way 4959510 https://www.openstreetmap.org/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 https://www.openstreetmap.org/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
  https://www.openstreetmap.org/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.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
#653 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAcEwnX48rCGvAUZCrz9-UYy01Sz8Pjmks5qlBXvgaJpZM4H9NNU
.

[rmarianski]

That all being said, if we had a relation with multiple buildings, would we want them all to be linked? As it stands now they will not be. The current logic will only link building parts with the largest overlapping building.

[nvkelso]

@rmarianski by relation with multiple buildings do you mean @zerebubuth's example Relation 553472 as a multi polygon relation? I think we should add logic for that case.

[nvkelso]

I've verified Rob's basic work, let's split off the Bank of England work into a new ticket (#1032).