Open maning opened 7 years ago
negative OSM IDs are relations
Thanks @bdon! I did a matching of the OSM ids from your list and made a TMS for JOSM (_click this link to load in JOSM_).
A few observations below (Cyan-SFOpenData, Magenta-OSM non-matching):
3 adjacent buildings in OSM, single building in SF OpenData.
Misaligned buildings in OSM.
Single building in OSM, individual units in SF OpenData.
Not all mis-matches means OSM data is wrong so each building should be verified with imagery or street level photos (i.e. Mapillary or OpenStreetView). I propose we create a TM project to fix them.
@bdon Can we create a TM project for this? It's more or less the inverse of what we are doing for the height import.
Next actions
cc @chtnha
@maning @bdon is it confirmed that the alignment of the SF open data is accurate? If so, then that should be used as the reference over satellite imagery to realign.
is it confirmed that the alignment of the SF open data is accurate?
@planemad I can't say 100%, but for the areas I've checked, SF Open Data aligns very well to Strava, Bing and SF Lidar TMS. We can use SF Open Data as the main reference but I'd avoid recommending it as a single source of reference.
@planemad refer to @bqb's comments in this issue: https://github.com/osmlab/sf_building_height_import/issues/12
Use 👇 for splitting buildings
Here is video demonstration - https://youtu.be/7GQtNnjIO0Q?t=3m29s
/cc @chtnha @maning
@bdon This is probably out scope of the initial import but can you share the 25% of buildings that don't match? We can definitively improve tracing of these buildings from imagery and probably match our overlap criteria in the next round of import.
cc @talllguy @chtnha