Create instructions for manual importers
almccon opened this issue · 8 comments
We need to develop instructions/guidelines to give to the volunteers who will be importing the data chunks.
In particular we should create a list of things they should check for before importing. For example:
- Use satellite imagery to confirm the buildings still exist (a concern because we're using data from 2008)
- Check for existing buildings and addresses: 1a) Manually conflate the best features from each. 1b) Where possible, preserve the original OSM feature for better tracking of object history
- Check for FIXME tags (we might add these for overlapping addresses: see #9)
- ...?
We should check the documentation (github repos and wiki pages) for previous building/address imports, such as NYC, DC, Seattle, etc., to see if we can base these guidelines on existing work.
We should also keep in mind that this instructions-for-manual-importers document will also be part of the materials we should present to the imports and imports-us lists for review.
I got started here: https://github.com/osmlab/labuildings/blob/master/IMPORTING.md... feel free to add anything more you like here, @cityhubla
Awesome, I added language on what to do with newer buildings not found in the imported and existing data tying in with issue #11. We should at least prepare this process if we end up using the 2008 data.
Should we have importers flag or tag the new buildings? I'm unsure if this is the way it should be done. Tagging them with a source attribute that this is manual should help if we have to go back to check on a completed task with issues.
Hmm. On the one hand, if people verify the newer building is there using Bing (or whatever other data source) they can add source=Bing, if the building doesn't already have a source tag. But on the other hand, if the existing building in OSM is fine as-is, then maybe people shouldn't touch it. Remember that if the person doing the manual import modifies an existing building, then their name will show up as the last editor of that building... it might cause other people to assume that the building came from the import, even though it didn't.
Oh, but I suppose that there will be many cases where the person doing the import will add address tags to existing buildings, so they will end up modifying the feature that way anyway.
Here's a map that lets you see which existing OSM buildings do not have addresses: http://www.itoworld.com/map/9?lon=-118.24536&lat=34.04698&zoom=14
In this case, all of those gray buildings will be modified anyway if we add addresses to them. Even if we don't modify their shapes.
Interesting, this map is helpful, would it be helpful to add language in the "Conflating with existing data," to filtering specific attributes on the existing in JOSM? like displaying which ones don't have addresses. Granted, there are few buildings in the region that have been added to OSM, but having this would help importers on what to check for.
If an importer finds a new building that is not in the import or existing in OSM, what options are there to have them add the address? We could refer to the "Ground truth the data" section or find another source that has the new address (City of LA's ZIMAS system or the LA County Assessor)
The PDX building import has good instructions: https://github.com/pdxosgeo/pdxbldgimport/wiki Not all of it will be relevant to us, but we should take a good look at it.
Added import guidelines that have been drafted and updated to the importing.md file of this repo.