Import stops and routes of Sibiu(Romania) city public transport

Hello, I am proposing to import the bus stops and routes dataset, sourced from Tursib, the public transport company of Sibiu, from Romania.

Documentation

This is the wiki page for my import:

The source dataset’s (from the GTFS file) is publicly available on their website(at the bottom of the page):

I have prepared a OSM file with the data:
https://truesoft.ro/tursib.osm

License

The permision is included in the wiki page.

Abstract

The dataset contains the newest information about the ~500 stops and 57 routes for Sibiu and the metropolitan area.
As I am a beginner in working with OSM, I need some help about what are the next steps to upload my changes. Any feedback is welcome.

1 Like

Before importing any data, it is wise to check for existing data in OSM just to avoid adding e.g. a bus stop which already exists.

I can add your area and ‘network’ to PTNA and an analysis of the GTFS data.

I already checked the existing data, I have the ids for the stops that are only updated. For the rest of them I put negative values in the file.

Yeah, great! I just discovered the OSM file. What a huge amount of work!

I’ll configure PTNA tomorrow afternoon/evening.

1 Like

Kindly see the announcement on PTNA: news for Public Transport Network Analysis - #621 by ToniE, releasing the ptna’s analysis support for osm and gtfs data for RO-SB-Tursib

Could you please check whether the search area for Overpass-API and Planet extracts are big enough? The blue and the black ones are relevant. If not, I can change that from city of Sibiu to county of Sibiu.

There are some stops which are outside the black area; the furthest to the east is (45.799310688401,24.354523569346) and to the north-west is (45.882351, 24.054979)

That shouldn’t be a problem if they are referred to in a route relation (member of).
Overpass-API and Planet extracts find all member nodes, ways and relations (only Overpass) of the route relations.

PTNA handles also only those stops which are members of route relations. PTNA focuses on routes.

What are the next steps that I need to do?

Well that depends on the *.osm file.

The legal aspects have been clarified, so it’ll be OK to use the data.

You wrote, that existing stops get more data, will not be deleted and replaced by new ones - great!
Also, did you create the *.osm file manually? I ask, because of the existing nodes, … and keeping their IDs.

It seems, that this is still what we call “a semi-automated import of data”.
There are some rules and procedures to follow, mainly announcing, communicating and describing the import and documentation.

The PTNA will help you afterwards in finding errors and pitfalls in mapping according to the PTv2 spec.

I made a small program which I extracted the existing nodes into a table - id, name and coords.
Then I matched them with the table of the GTFS stops.
Then I made another program which generated the osm file using the GTFS data. When a node existed, I kept its id. Otherwise I created a negative one. Similar with the routes.
For the future, I will use the new field gtfs:stop_id if something needs to be updated.

Sorry for the delay.

What was your tolerance in detecting whether a GTFS stop is the same as an existing OSM stop?
Look here at GTFS stop #12 (scroll down) of bus 1, which in my eyes is the same but > 120 m away.

Also, which OSM objects did you identify as a bus stop?

  • only those having highway=bus_stop set?
  • what about those with public_transport=stop_position without a highway=bus_stop?
  • same for public_transport=platform?

Those public_transport are defined by PTv2 for objects at a bus stop.

How do you handle existing route_master and route relations? There are some, see the PTNA report.

For that particular example(stop #12), the correct one is from GTFS. The OSM coordinates must be some old ones. With Google Maps sattelite view, you can see the signs on the road that there is the stop.
I fixed the other stop(#1) with 136 m difference and updated the file.

The condition I used initially to select first the nodes was: highway=“bus_stop” OR public_transport is one of [“platform”, “stop_position”]
I used the existing route_master and route relations(to take the ids)

Thanks, that approach really sounds great and straightforward.

There will always remain some edge cases which need a review after the import.
The bus stop icons on the Carto (standard) map style can be used, and there is also the Transport layer on osm.org both for a visual review.

Ahm, let me ask one more question.

How did you handle the way members (those which are not stops/platforms) of the existing OSM routes, the shapes? Did you compare them with the GTFS shapes? That’s quite tricky selecting the right OSM streets and bring them into the correct sequence (for PTv2).

The ways would be updated in the second phase. The stops were the most important for the company. Some ways of the routes are very different than the old OSM ones.

1 Like

Should I start to upload only some of the stops and routes first?

Yes, it would be good starting with 10 or so first routes and their stops.
In the other side, if this goes well, the adding the remaining ones could cause other problems.

A complete revert is always possible, so why not adding all in one go?

I’ve uploaded them using JOSM. Please, if you can have a look, as it is my first time using this program.

Looking briefly at the PTNA report, it seems that you’ve created new route_master relations and did not consider the existing ones. I can’t say more, I don’t have local knowledge. But there seems a lot to do now.