I’ve noticed that bus stops are something that Sydney’s OSM is quite lacking in - and over the years I’ve added a couple bus stops if I’m editing something else in the area. A couple months ago, I started using the GTFS feed for some data analysis I was conducting, and am now quite well versed in the intricacies of it. I’m also a frequent bus user and have travelled quite a large number of routes - I thought I’d put that to use and finally add the missing bus stops.
As per the Import Guidelines, I’ve documented my proposal here and done Route 753 as an example.
The import would not be a blind all-at-once, but rather in groups of 10 or so routes at a time, so that I can ensure nothing weird happens.
I’ve created and maintain PTNA supporting QA on OSM public transport relations. GTFS is also supported and since Jan 2024 a comparison between GTFS trips and OSM routes can be done as well.
I can easily add Sydney for the OSM data. For GTFS: it depends on the license of the data. Is the license compatible with OSM? I didn’t check that yet.
With that in mind, I have a couple of thoughts on this:
These imports could remove some outdated stops that are already part of route relations, so there might still need to be some editing of routes.
There’s a user called Lockstar who has also been systematically fixing Sydney’s bus route relations recently (Changesets by Lockstar | OpenStreetMap). It would be worth reaching out to coordinate efforts.
Toni:
As TheSwavu mentioned, the Waiver has been signed and opendata for nsw is available for use on OSM. Your addition of Sydney would be very welcome!
Gillifrey:
Yeah, I’ve used that wiki page in my method too
As you mentioned, the code in that repo is some 2 years un-updated though, and I’m more familiar with Python than Ruby so I’m not interacting with it much. Regarding:
With the conflation method I’m using now, in general no bus stops will be removed. The most destructive thing that could happen is a rename, so that should be fine?
That’s great, I’ll send them a message! I was apprehensive about the volatility of bus routes, but I guess it’s fine then.
This only works for the dump of GTFS data across all modes of transport for the entire state of NSW though, not tailored specifically for Sydney Metropolitan Bus routes.
This file also contains School Buses, so you’ll have to prune those as well.
I’ll nevertheless take the GTFS data “as is” and store that as “AU-NSW-TfNSW” - same procedure as for CH, NL and other countries which provide nation-wide GTFS data.
The analysis will be called “AU-NSW-Sydney”, covering all types of public transport in the Sydney metropolitan area, New South Wales.
Unfortunately not, unless I decide to remove all bus stops in an area and replace then with new ones. That is probably too destructive especially for the pre-existing relations.
It’s good practice to keep the history of objects, will your proposed conflation process ensure that existing bus stop objects are retained and not deleted in favour of new ones placed by yourself?
Can you document the policy around conflicting tags and locations?
In my view, existing tags, especially if from a survey should be preserved and instead a new note / changeset comment could be raised to question the difference.
Where the location differs, I think it can be improved if the imagery is clear.
Hi Sudface,
Fully support the approach to apply a consistent upload of bus stop data. Some things to consider - field checking/local knowledge will be needed for some locations as the dataset is not completely spatially accurate. Some sites also have a lot of data already entered (such as shelter, bench, lighting, accessibility info etc) - need to make sure this info that exists is not lost. Many stops too have relations with bus routes - will this be preserved for existing stops?
