If there is a conflict regarding position or tags, they should be resolved by a human mapper. If I were to apply the newer is better approach, we would constantly be reverting back to the positions the operators think their stops are at.
It's important to respect the mappers work, because without mappers OSM quickly dies off. It might be complex to put such a solution in place, but it should be obvious that if data flows in 2 directions, too much simplification doesn't work. Jo 2017-09-27 10:46 GMT+02:00 Safwat Halaby <swiftf...@gmx.com>: > On Wed, 2017-09-27 at 09:12 +0200, Jo wrote: > > Deleting data on OpenStreetMap and replacing it by imported data is > > obviously never the acceptable approach. > > > > What I don't understand is why you don't create something that > > compares the > > latest version of all the bus stops in OSM with the latest version of > > the > > GTFS data from upstream. > > > > Why compare with an inbetween version? > > I'm taking a "Newer is better" approach for conflict resolution. > > Let's say a user made a 2015 edit for a coordinate (We'll call this > version X). And your 2017 database has a different coordinate (We'll > call this version Y). How do you determine which coordinate to keep? > > If you had a 2012 database that would be easy. > > Case 1: > 2012 database: Y > 2015 user edit: X > 2017 database: Y > > This means the Y has not been updated since 2012. Newer is better, so > trust the user edit and set the coordinates to X. > > Case 2: > 2012 database: T > 2015 user edit: X > 2017 database: Y > > This means Y is the newest value, and we should override the user edit. > > Without two database, we'd have to guess or resort to manual user > intervention via fancy web services. > > > > What I think is needed is a (web) service that stands between the > > operator > > data, be it GTFS or DB dumps and OpenStreetMap where comparison is > > made and > > which can be used by mappers to either improve OSM, or to send > > feedback to > > the operators that there are issues with the data they provide. Or > > where > > the operators can request flagged stops in bulk. > > > > I am a huge advocate of simplicity. In my humble opinion, web services > and SQL databases are overkill for what I'm trying to do. Your project > spans dozens of files while mine is a single .js file for the JOSM > scripting plugin, which reads two textual stops.txt files from the old > and the newer GTFS databases. >
_______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
