How to deal with tags on points that sit atop buildings?

[ivangayton]

Tags on points or polygons?

As Kristen and Ivan prepared to test the FMTM for building tagging in Boulder, we realized that there's an inconsistency in the way that tags are applied to buildings.

In many cases, the building polygon (the 'way') is tagged with building=<something, often 'yes'> a name, number of levels, etc. This makes it straightforward to add tags to the building.

However, in other cases, the building polygon has few or no tags (not much more than building=yes) but there's a point (standalone OSM node) that is tagged with most of the useful information about the building: the name, the opening hours, etc.

A particularity of the situation along Pearl Street in Boulder is that restaurants appear to be tagged with amenity=restaurant, while shops appear to be tagged with the key shop (as in shop=fabric or shop=gift). So simply pulling all of the amenities from OSM along with the buildings wouldn't catch shops, and we're not sure what other important types would also be missed.

What is the implication for building tagging?

The old OMK workflow generally assumed that it would often be appropriate for building polygons to be directly tagged. This doesn't work well when a building contains multiple amenities (a mall, or a multi-story building with a different business on each floor; that being said, a pile of 2D points doesn't do much better for the multi-story situation either). The current situation requires that we either choose between polygons and points, in which case we'll certainly fail to see/load information from one of the two layers, or bring in both, which seems likely to result in a messy, cluttered task for which it's more difficult to decide if it's properly completed.

There are a few possible approaches to this:

1. Ignore it and tag the building polygons without looking at the tags on the points
2. Import amenities, shops, and whatever other keys refer to points that contain information about the buildings we're visiting, and select those points rather than the building polygon centroids
3. Integrate the tags from the points into the polygons using JOSM or other before starting work on a project
4. Other?

It seems likely that different approaches will make sense for different contexts; wherever a particular style of mapping seems to predominate and the local community seems to be happy with it we probably shouldn't mess with it.

However, we should probably have a think about the various possible strategies, and maybe have a conversation with the data model and data quality people!

[robsavoye]

When I make data extracts from OSM for amenities, I do also add shop=* to try to get everything. I also query all 3 tables, nodes, ways, and relations. It's slower of course, more data to chug through. but otherwise you miss a lot of features. OSM data is so wonderfully flexible!

Usually for the big building containing multiple shops, the building often has a different name, so the tags are on the polygon. Each shop is a POI, ideally the entrance to each shop.

I've also seen the case that a building=yes, probably from an import, also has an amenity POI. Obvious the POI was added later by a ground mapper. I also see this for addresses, as they were a secondary import. I wrote a program a few years ago that would merge all the POIs in a building into the polygon as long as it was one POI per polygon. In some areas I could also merge a POI near, but not in the building polygon, as long as nothing else was nearby. Doesn't work in densely populated areas though.

It is possible to automate much of this conflation process, and reduce the time somebody has to sit in JOSM after processing. OSM dislikes mechanical edits, so it still needs manual validation.

The data models don't care where the tags are. For data quality this may not be a big issue as long as the tags are correct. I can think about bringing that old program back to life at some point. For FMTM it won't be a problem as we have the OSM ID from the data extract, so the conflation is less complicated.

[robsavoye]

Classically, I just hit this problem today making data extracts of my local villages. The building polygon was added by one person, and the tags by others. As they do not have the same OSM ID, you have to be careful. When the POI is in the building polygon, then it's easy to automate merging the two, which of course would to be validated, both before and after. If the POI is not within a building polygon (like the location is where somebody is standing outside), or maybe imagery offsets. It'd be possible to flag those for manual merging. For the data extracts, what happens now is I get two POIs, one with the tags, and the other our building centroid. I managed to delete the duplicates in JOSM.