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? 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. The same goes for the lines (route_master) and the various itineraries (route relations). Polyglot 2017-09-27 7:42 GMT+02:00 Safwat Halaby <swiftf...@gmx.com>: > Hi John Whelan, > > As implied in the forum thread, not wanting to destroy user data is > exactly why I'm building a relatively complex script. The naive > approach is to destroy all-bus stops are re-import, everytime a GTFS > update is released. But I don't want that. > > Instead of doing that, the script preserves all user-submitted data > such as shelter, wheelchair, and GPS coordinate fixes and provides > incremental updates rather than the destruction of all bus stops per > import. The incremental updates do not destroy user changes. In order > to achieve that, the older and the newer GTFS database need to be > compared per update. > > Yesterday I didn't have the database which was used in the old 2012 > import, so I couldn't locally test-run my script. which is what lead to > my original question in this thread. But now I managed to reverse-build > the old GTFS database from version 3 of the bus stops in Israel by > downloading the bus stops through the relevant changesets. > > Here's some of the discussion: > > >Here's a merging idea. > > > >Problem: Dealing with conflicts between mapper > edits and gtfs data. > >Solution: "The most recent version is the correct > version" philosophy. > > > >- The first gtfs update would update everything. > Conflicts are > > resolved by prioritizing the gtfs file's version. This > is a > > "necessary evil" but is >only needed once. (edit: I might be > > > able to mitigate this by tracing bus stop OSM history). > >- Some time > passes, and users update some of the bus stops. > >- The ministry of > transportation updates some bus stops in > > its database and publishes a > new gtfs file. > >- The next gtfs update would inspect the difference > between > > the new gtfs file and the older gtfs file. Only bus stops > > > that have had their data (in >the gtfs file) changed since the > > last > file are updated. So, conflicts are resolved by prioritizing > > the gtfs > file version, but only for the bus stops that were changed > > by the > ministry since the last update. The rest of the bus stops > > are left > intact. > > (source: https://forum.openstreetmap.org/viewtopic.php?id=16738&p=3) > > Also, we know the data can be used in OSM. > > https://forum.openstreetmap.org/viewtopic.php?pid=244096#p244096 > > _______________________________________________ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk >
_______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
