I am a student at the University of Tennessee - Knoxville, and recently discovered StreetComplete. It’s been quite fun! I have used OSM on a few separate occasions in the past, but helping contribute (in albeit small ways) has had my thoughts on it much more lately. One thing I’ve run into however as I’ve used StreetComplete is that the bus stops listed in Knoxville on OSM are not often in accurate places. I am aware of at least one instance of major routes changes being made in Knoxville a year or two ago, and it seems as though, while many stops are still correct, albeit their information sparse, lots of other stops listed no longer exist, or have only partially correct information, or various FIXME-like tags.
In my pursuit in trying to figure out how I might rectify this, I found that the local transit operator Knoxville Area Transit offers GTFS data. This is great, and the gears started spinning, but with each idea came a set of questions I wasn’t sure how to answer, and so I come looking for advice. (I am aware that as this is an import, I would need to follow the Import Guidelines. I am confident I can do that, not a problem, including reaching out to KAT and asking for permission to use the data in alignment with the ODbL)
My initial thought was somewhat “nuclear” which is to say I figured the easiest choice would be to delete all bus stops in Knoxville and replace them with the GTFS info. This would remove all incorrect stops, and correct/remove any data that was incomplete or otherwise wrong. The primary con to this as I see it is that there is likely some data attached to at least some of these stops that is worth preserving (StreetComplete data, such as tactile paving, presence of a bench/trash can/street lamp, etc.) The bigger issue that I realized as I viewed this data was that it left out bus stops/routes operated by the University of Tennessee, and the university does not (at least publicly or accessibly) offer GTFS data. And, some of these stops do appear in OSM. I’ve emailed “a” UTK email about this, hoping at least for a response. In the meantime:
If I do not receive permission from KAT about the GTFS data, there’s nothing more to do (although the website makes me optimistic)
If I receive permission from KAT, and I do not receive the data/permission from UTK, then what’s the next course of action? I’ve tried using OSM-GTFS, which was nice, but felt lacking compared to GO-Sync, but I ran into technical issues with GO-Sync, particularly with the map not loading, making it really hard to fix conflicts. Neither GTFS-OSM-Validator - OpenStreetMap Wiki or GTFS-Janitor worked for me.
If I receive the data and permission from KAT and UTK, I suppose I’d try uploading that data together into GO-Sync and OSM-GTFS to see if it’s any more manageable. The longer I have the idea of “nuking” the map in my head, the dumber it sounds - I’d have to imagine there’s a nice way of updating that information while maintaining the valuable tags that may be present, but that’s beyond my current ability as a rather limited/somewhat new OSM contributor.
Hope my thoughts aren’t too absurd. Would love to hear more about what I could do, and I’m loving that I could find something so much more meaningful to contribute than “What is the surface material of this road” lol
Just to be clear there’s a big jump between contributing with SC and doing an import, too large really. You definitely need to get some wider experience contributing to OSM before considering that, for example by simply fixing the bus stops you know are wrong/whatever.
That said, do you have any numbers on how many bus stops there are in total/missing?
PS: in general it is considered bad form to simply delete existing objects, particularly when they might only need some minor work to correct them.
Not only that - the stops are members of relations representing the bus routes, e.g. the example here is part of 3 route relations. If you delete the stops you will lose that information and will need to add the new stops back into the relations in the right order, which is often one of the more time-consuming parts of mapping bus stops. I’m not sure if the tools you mentioned handle the relations aspect.
As mentioned in the previous post, it would certainly be worth fixing and adding some stops manually to see how it all fits together, with an editor that allows relations to be edited (so not StreetComplete).
As @SimonPoole said: simply and blindly deleting data, replacing it from an import is a bad idea.
Secondly: I haven’t seen error-free GTFS data yet, so an import could make things worse.
What I can see from PTNA’s report for US-TN-KAT, route relations are still mapped according to the older scheme (aka PTv1) and not PTv2. But that does not affect stops and platforms, it does affect route-relations and how they are mapped.
GTFS’ understanding and specification of routes and trips is much closer to OSM’s PTv2 though.
PTNA does not (yet) provide GTFS data analysis for US-TN-KAT. Would be nice to know whether their license is compatible or whether we can get a waiver from them (“use of GTFS is OK for OSM”).
I understand that, I didn’t mean to barge in and suggest I was ready for anything. I’s also understand if more experience is recommended, but I have contributed in other ways before, just not a significant amount. There are some stop near me that are definitely non-existent that I guess I might start with. In total, it’s hard for me to say what the total difference is unfortunately. OSM-GTFS suggests there are 515 stops that appear in the GTFS data and OSM data, 201 strictly in GTFS, and 601 strictly in OSM (although at least some of those are UTK stops, and it doesn’t seem like I can load two GTFS files at the same time)
Ah, I hadn’t thought of relations. I knew a mass deletion was probably not the correct choice, which is why I’m hereto see what course of action might be better. I wasn’t sure if JOSM could load GTFS data, and couldn’t piece it together myself, which is also why I turned here, and the aforementioned programs
Oh that’s so interesting, I assumed that since the data was coming directly from KAT, it could be trusted well enough.
I suppose at this point, it’d be better for me to just take it slow and try not to tackle this all at once, at least based on the suggestions listed here. I was given the GTFS data from UTK, and I’ll see what I can gather from that. Thanks all!
The relations already mapped might be helpful to you as a way of organising your work. The number of stops may seem daunting, but the number of routes is manageable (27 mapped currently).
For example, if I was starting from your position, I might try to systemically survey one route, perhaps by riding some sections and walking some sections. Comparing what you observe with the “official” data for the same route may tell you a lot, e.g. are the GTFS positions generally reliable? Is there some pattern to differences between GTFS and current OSM data? That might help you decide on an approach to importing the other routes.
Ideally, any import process should be able to identify existing currently-mapped information and test that information for validity against the reference data and then choose to either skip over or augment it. If you develop an import process that also matches and validates existing data, then there is a hope that you can re-run it again and again in the future to capture upstream changes in the reference data.
If building a repeatable and update-able import process, there really isn’t a significant cost to trying out the editing steps manually to practice the workflow (which will be automated in the future). Any time spent manually practicing the process is simply discovery toward understanding the logic needed for the future automated process, which should then be able to skip over or update the manual work later.
GO-Sync - OpenStreetMap Wiki is very valuable in that pursuit, although like I said, I had some issues with it. I may try again on a different computer and see if that helps for some reason, but I expect it won’t. The original authors have only an archive of their repo, which says to me that they’re no longer maintaining it, while the fork the OSM Wiki links to did not work for me, although I could take a closer look at the error and see what the deal is (that said, my Java experience is about 6 years old ) But it did just about exactly what you describe, albeit not in a particularly easy way, for me at least
) But it did just about exactly what you describe, albeit not in a particularly easy way, for me at least