Trace or import data?
The considerations necessary to determine wether to trace over a dataset to include it in OpenStreetMap or to import the dataset into OSM have to be made on a case by case basis.
Example SF Building Height Import
Common case for an import with a lot of data already in OSM
Compare height from external source for existing OSM buildings
Create a changeset file
Import using Tasking Manager
Important note
In general, the OpenStreetMap community is very skeptical of data imports, due to many years of bad experiences with outdated 'official' datasets in stark contrast to the community's large scale success with ground truth (Wikipedia) and local community knowledge. Below we're sharing a growing collection of examples for datasets of value to be included in OpenStreetMap and how they were processed. The OpenStreetMap wiki on import guidelines holds much more information on this subject. Here's also the extensive catalogue of data imports into OpenStreetMap.
Open datasets of value for OSM
What? | Why? | Import / trace over | Further reading |
Trees | Database of trees in a city are kept to enable management of the entire tree stock for reasons of heritage, aesthetics, planning and safety. | ||
Location of assets (bus stops, EV charging stations, sensors, monitoring stations...) | To keep track of changing locations, or new locations being added | ||
Building footprints | building inventory, completeness | LA Building imports wiki documentation, SotM US presentation | |
Building heights | building inventory, 3D visualization, completeness | ||
Infrastructure (roads, bicycle network, etc) | |||
Transit network information | Maintaining in-house transit network data updated by adding new/modified features from OSM | Trace over to adjust data | see Milan case study |
Last updated