On Wed, Mar 4, 2015 at 9:34 PM, an OSM mapper wrote: > > The locations need local mapping to get the location perfect. > > Are you intending to feed these local changes back to the data source? > Will the import involve deleting any repair stations in OSM not in the > data source - this doesn't seem like a good idea. > > A qualified yes to that.
This import uses a script meant for synchronizing a commercial data set (like a list of ATM's, radar stations, or chain stores) to OSM. It prepares a changelist file describing any differences for human review. If an item drops out of the company's dataset, the OSM mapper sees that closure. Here if Dero racks removes a location it's because the property owner, their client, told them the site was removed on the ground. The human OSM mapper can decide how to react (e.g. mirror the deletion in OSM, take no action, move the item to Open Historical Map, or tag disused:, or fly to the location and check). In the ATM or radar station case: it's the same thing. For well run corporate data sets the list of open stores, ATMs, or whatever is quite good. If an item drops out of that data it's because the location has closed. But, the human can review it, checking yelp or seeking other secondary sources or local sources for information. For this bike tool data set, OSM changes in the USA have already been sent back to the corporate source: mostly duplicate data points and more precise positioning. In general at the next sync this causes no trouble, the fuzzy match is simply less fuzzy, and no action is taken. Similarly if an item is deleted from the OSM set, a flag will be raised. Here the Dero company would be notified. This has not happened yet. The script was built for a one way synchronization, but seems to work reasonably well for this two way sync.
_______________________________________________ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
