Landuse should exclude buildings source

[nvkelso]

In working on #186 we've discovered we're duplicating buildings with certain tags into the landuse layer as polygons. We shouldn't be doing that (the building should only appear in the building layer as a building feature, a flattened version of it shouldn't be copied to the landuse layers).

[nvkelso]

I suspect this is the root cause of too many university icons showing up in clusters where OSM has building=yes and amenity=university, but we drop building=yes and end up with amenity=university and an area, which confuses styling down stream.

#16/37.7243/-122.4790

[nvkelso]

It's also a little weird to see kind:university and landuse_kind:university! At least for building labels, maybe for others, does it make sense to drop the feature's kind property if it's the same as the landuse_kind?

See:

• http://vector.dev.mapzen.com/osm/all/16/10471/25342.topojson?api_key=vector-tiles-HqUVidw

[zerebubuth]

There are a few things we could try for this:

1. Dropping the feature's kind when it ==landuse_kind, as you suggest.
2. Don't include buildings in landuse (i.e: if building=* then it's a building, not a landuse polygon).
3. Apply some de-duping filters, e.g: Filter out duplicate POIs #267.

The first option seems pretty quick, so let's start with that.

[zerebubuth]

It sounds like we need to separate out three different things; landuse, building and POI status. Any OSM feature could have a mixture of all three. I've tried to collect together a set of reasonably plausible examples below, along with what we might want them to be exported as in the output.

1. a building with no name has building=yes. This should result in a building polygon in the buildings layer with kind=building?
2. a building with a name has building=yes and name=*. This should result in a building polygon in the buildings layer with kind=building and a label in the buildings layer with kind=building?
3. a building with an address has building=yes, addr:housenumber=*. This should result in a building polygon in the buildings layer with kind=building and an address point in the buildings layer with kind=addr (or kind=address?).
4. a building with both name=* and addr:housenumber=* would result in both an address point and a label being generated?
5. a building with hotel tags has building=yes, tourism=hotel and name=*. This should result in building polygon in the buildings layer with kind=building and a point in the POIs layer with kind=hotel and name=*. We don't consider the name to apply to the building when there are POI tags. But address tags would still generate an address point in the buildings layer.
6. a building with theatre tags has building=yes, amenity=theatre and name=*. This should result in building polygon in the buildings layer with kind=building and a point in the POIs layer with kind=theatre and name=*, just like the previous case.
7. a building with landuse and restaurant tags has building=yes, landuse=retail, amenity=restaurant and name=*. This should result in a building polygon in the buildings layer with kind=building and a point in the POIs layer with kind=restaurant and name=*. The landuse value for this building is ignored, although it may get landuse_kind from being enclosed in another landuse polygon anyway.
8. a building with landuse and theatre tags has building=yes, leisure=stadium and amenity=theatre. What should this get?
9. a "building" with leisure tags has building=yes and leisure=park. It should get a polygon in the buildings table, and a label point in the landuse layer, but no polygon in the landuse layer?
10. a park with a library in it has amenity=library, leisure=park and name=*. It should get a polygon in the landuse layer with kind=park but no label, and a label in the POIs layer with kind=library and name=*.

Does that all sound about right? Are there any other cases we should be considering? Particularly any which would result in a polygon being put into more than one layer?

[nvkelso]

1. a building with no name has building=yes. This should result in a building polygon in the buildings layer with kind=building?

It would, but we strip that out in post processing so there is effectively no kind property on the feature by the time it makes it to tiles as a polygon (unless an amenity & etc value is additionally set). No label_position should be generated for this feature. I think there is one now, Rob was going to change that in the generic logic (to only generate label_position if name, except if pitch or grass with sport tag).

[nvkelso]

2. a building with a name has building=yes and name=*. This should result in a building polygon in the buildings layer with kind=building and a label in the buildings layer with kind=building?

See comment in (1) Above re skipping building=yes in kind calculation. I understand why we do it, but it's also a little weird (to drop it) since we include kind verbosely on any other type of feature in other layers.

[nvkelso]

3. a building with an address has building=yes, addr:housenumber=*. This should result in a building polygon in the buildings layer with kind=building and an address point in the buildings layer with kind=addr (or kind=address?).

This makes sense to me.

NOTE: We revised kind=addr to kind=address earlier in the release.

[nvkelso]

4. a building with both name=* and addr:housenumber=* would result in both an address point and a label being generated?

Yeah. Is the addr:housenumber=* still included on the label_placement for the building so the client could specify that on a second line in the name rendering?

[nvkelso]

@zerebubuth For all of these, does building=yes really mean building=*? I think that's how the logic works now.

[zerebubuth]

For all of these, does building=yes really mean building=*? I think that's how the logic works now.

Yeah, I managed to pick examples with building=yes for all of them... I was thinking that something like this would happen on the polygon:

• if building=yes then output kind=building
• elif building=* then output kind=*
• else don't output a polygon.

[nvkelso]

5. a building with hotel tags has building=yes, tourism=hotel and name=. This should result in building polygon in the buildings layer with kind=building and a point in the POIs layer with kind=hotel and name=. We don't consider the name to apply to the building when there are POI tags. But address tags would still generate an address point in the buildings layer.

What happens when there is also a record for that hotel in the point table? Would we get two label_position features, one for the building and one for the point? I think we only want one, but maybe this is a separate pass to dedup?

[nvkelso]

6. a building with theatre tags has building=yes, amenity=theatre and name=. This should result in building polygon in the buildings layer with kind=building and a point in the POIs layer with kind=theatre and name=, just like the previous case.

Ditto to 5) above.

[zerebubuth]

I think we only want one, but maybe this is a separate pass to dedup?

I think so too. If there's something in the points table and in the polygons table, that implies that it's duplicated in the original OSM data (as an individual node and also a way/relation). Ideally the data would get fixed, but there'll be some weird corner case where that's not possible, and so it's better to de-dup later on when we've got all the label points together in the same place, as we're post-processing them.

[nvkelso]

7. a building with landuse and restaurant tags has building=yes, landuse=retail, amenity=restaurant and name=. This should result in a building polygon in the buildings layer with kind=building and a point in the POIs layer with kind=restaurant and name=. The landuse value for this building is ignored, although it may get landuse_kind from being enclosed in another landuse polygon anyway.

Yep (and that's what default OSM rendering does).

[nvkelso]

8. a building with landuse and theatre tags has building=yes, leisure=stadium and amenity=theatre. What should this get?

• We should get a POI that is kind=theatre (stadium is less important than amenity in the coalesce here... which is the same logic in the osm.org renderer now – see how they accomplish that).
• We will get a polygon in the buildings layer that has kind=theatre.
• There should be no label_position in for the building in the building layer.
• There won't be a kind=address address point for this in building layer (no house address is set).

[nvkelso]

9. a "building" with leisure tags has building=yes and leisure=park. It should get a polygon in the buildings table, and a label point in the landuse layer, but no polygon in the landuse layer?

You managed to find the high line in NYC, which is like a data unicorn!

• Agree: It should get a polygon in the buildings layer
• Agree it should get a label_placement and it should go into the landuse layer so it can draw with an icon, abstracting the data weirdness from developers.
• Since this feature has layer=1, it seems weird to put it into the landuse layer. But what if there was no layer defined (default ground level)?

Since it has other attributes like building:color, building:material and roof:material we assume that someone really meant it (as a building). But if it were just building=yes and leisure=park, that seems weird (but weirdness we ignore?).

[nvkelso]

10. a park with a library in it has amenity=library, leisure=park and name=. It should get a polygon in the landuse layer with kind=park but no label, and a label in the POIs layer with kind=library and name=.

Did you mean it also has building=yes? In that case, I don't expect to see this building appear in the landuse layer (only in the building layer polygons). If it doesn't have building=* then sure, landuse only. If it's coming from buildings then this label position would end up in POIs because it's got the amenity tag.

[nvkelso]

Another strange case:
https://www.openstreetmap.org/way/32113743

Here there's an landuse area that has area=yes for the school grounds, with a name. Should this get a label position? What kind value?

[zerebubuth]

Action item: If we're putting a POI sourced from landuse or buildings into the POI layer, let's include both it's source area (already happening) and mark it as label_position=yes (todo).

I don't understand the rationale behind this. If we have a POI then why do we care whether it has come from a polygon or a point table?

Is there something that label_placement=yes is used to signify other than the source table of the data, as that really should be an implementation detail that we don't expose. At the moment it's correlated with area, but only because we don't (yet... #348) have a good way of figuring out how to assign building area to POIs.

(As a side note, started #347 to track using representative_point for calculating POI positions from polygons.)

[zerebubuth]

Regarding case 3 above, looks like the address label position 2525 in this tile should be marked kind=address, but is only showing up as a property attribute on the polygon with kind=building.

I'm getting this locally:

  {
    "type": "Point",
    "properties": {
      "source": "openstreetmap.org",
      "kind": "address",
      "addr_housenumber": "2525",
      "addr_street": "Van Ness Avenue",
      "id": 69707523
    },
    "coordinates": [
      676,
      797
    ]
  }

So something is going on. Not sure if it's a code difference between dev and my local machine, or a database difference. Will investigate further.

[zerebubuth]

So something is going on. Not sure if it's a code difference between dev and my local machine, or a database difference. Will investigate further.

This tile looks good in dev as of last night's deploy. So either there was a temporary regression which got fixed, or something weirder is going on.

This might be an excellent candidate for a "unit test".

[nvkelso]

@zerebubuth Here's an interesting case where no name, the building is tagged as an appartment, and it has an address=1595. Should the kind=address or kind=appartment?

http://vector.dev.mapzen.com/osm/all/19/83848/202601.topojson?api_key=vector-tiles-HqUVidw

{
type: "Polygon",
properties: {
kind: "apartments",
area: 544,
addr_street: "Greenwich Street",
height: 14,
volume: 7616,
source: "openstreetmap.org",
addr_housenumber: "1595",
id: 243508784
},

UPDATE: I've worked around it in the stylesheet.

[nvkelso]

I've gotten around the label_position thing by using $geometry: point paired with area: true which works in Tangram JS / WebGL and is soon to work in Tangram ES (PR landed Thursday?).

[zerebubuth]

Here's an interesting case where no name, the building is tagged as an appartment, and it has an address=1595. Should the kind=address or kind=appartment?

http://vector.dev.mapzen.com/osm/all/19/83848/202601.topojson?api_key=vector-tiles-HqUVidw

I'm seeing two features there:

  {
    "type": "Polygon",
    "properties": {
      "kind": "apartments",
      "area": 544,
      "addr_street": "Greenwich Street",
      "height": 14,
      "volume": 7616,
      "source": "openstreetmap.org",
      "addr_housenumber": "1595",
      "id": 243508784
    },
    "arcs": [
      [
        2
      ]
    ]
  },
  ...
  {
    "type": "Point",
    "properties": {
      "source": "openstreetmap.org",
      "kind": "address",
      "addr_housenumber": "1595",
      "addr_street": "Greenwich Street",
      "id": 243508784
    },
    "coordinates": [
      807,
      43
    ]
  },

Which is what we agreed before. The addr_housenumber is left on the building polygon in case it's useful to some renderers, but generally it should be ignored if the kind=address points are being rendered.

[nvkelso]

I see the same thing now, and it's to spec, so nothing more to see here.