Talk:San Francisco Building Height Import

Louisville KY

I'd love to know how to do this. We have the same issue in Louisville, KY. We completed a builidng and address import, but now want to add the building heights. We have these now by a builidng id field, and that id field was also loaded into OSM, so we don't even have to conflate, just add new building height tags based on the data.

Please contact me if this goes forward as I'd like to learn how to do this in Louisville too.

-- Yourmapper 20:19, 18 September 2015 (UTC)

Project kickoff

I'm interested in taking the lead on this project. I've successfully written a script to conflate existing OSM building ways with a LIDAR footprint already. There's a few issues I still don't have a clear solution to:

1) Other building import tasks are focused on adding new ways. In our case, we're only modifying existing ways by adding a height tag. The workflow used by the LA and NYC imports is to create a JOSM changeset. Since we're modifying an existing osm entity, we need to include the whole entity in the JOSM changeset - meaning that it would be impractical to pre-generate them (they might be edited upstream between pre-generating and importing). I'm not sure if JOSM has some sort of conflict resolution that would work here. Otherwise we'd have to re-generate all the changesets frequently or on-demand.

2) There are often alignment issues where a single OSM footprint intersects multiple LIDAR areas. The way I've done the conflation requires that the OSM footprint must overlap LIDAR by at least 10 meters. I should probably refine this threshold based on observations.

3) Some entities with a building tag should not have a height, even if they intersect a LIDAR footprint. Most obvious is underground feature like metro stations (if tagged correctly we can exclude). We'd need to have detailed instructions in the tasking manager for cleaning these up.

Bdon (talk) 16:36, 7 April 2016 (UTC)

Regarding issue 1, instead of pregenerating everything, could your script be run locally by volunteers as they download chunks of up-to-date OSM data? Ideally it could even be a JOSM plugin, but I have no idea how difficult that would be to write.

--Alan (talk) 22:37, 7 April 2016 (UTC)

I've been hacking away at the JOSM changefile issue without much success. Another possibility is to generate an imagery tileset of all the LIDAR footprints (with height labels) and deploy a custom iD instance, so that mappers would manually tag each building with the height they see in the basemap.

Bdon (talk) 11:28, 8 April 2016 (UTC)

A custom tileset would definitely be the simplest approach. You wouldn't even need a custom iD instance; the default iD supports adding a custom tiled background layer.

This approach is also the most manual technique, which would appeal to the community members that dislike imports. This would reduce the chance of accidentally messing up existing data.

Maybe this idea is best. No need to overcomplicate things.

--Alan (talk) 17:14, 8 April 2016 (UTC)

My thought was that a custom iD instance would help by disabling everything except buildings, but this also happens to be more complicated to implement than I thought.

Will work on the custom tileset next week. There's around 161,000 buildings I've identified that can be tagged with height, so we should make some estimates around what the average task size should be (# buildings) and how long everything should take, including a 2nd verifier.

Bdon (talk) 01:03, 9 April 2016 (UTC)

If the JOSM changeset was trivial, would that make any difference to the decision-making process here? Assuming the idea of human involvement is to provide oversight, I'm not seeing a ton of difference between a human reviewing computer-tagged height values and a human adding a height tag from a list of computer-generated values. So if it would be useful, I'd be happy to try to work on the changeset problem.

- Meetar (talk) 18:06, 14 April 2016 (UTC)

@Meetar agreed - I've added a basic implementation of creating the JOSM changesets in the git repo, but we need to test it thoroughly to make sure it behaves right in the editor - will put some followup issues in github issues

Bdon (talk) 07:14, 15 April 2016 (UTC)

Additional questions (via John):

Q: Should we use the existing height tag or something like lidar_height? A: We should use the height tag so existing tooling and renders can seamlessly use the data.

Q: How should we handle existing height data? A: I think we should leave heights that are already tagged intact.

Q: Should we add heights to building:part? A: I think so. If there's a very detailed model that we don't want to interfere with, it probably has height tags already. I could be convinced otherwise however.

Bdon (talk) 08:43, 8 April 2016 (UTC)

If building:part exists in OSM (can we check how many of these are in San Francisco?) then it's probably there to describe buildings where some parts of the building have different heights. In those cases, they probably already have a height tag in OSM... or those buildings are already split into parts in the LIDAR data. We should add heights to building:part if they don't have height already, but make sure there's lots of human oversight in those cases.

--Alan (talk) 17:14, 8 April 2016 (UTC)