NOTICE: is no longer in use from 1st March 2024. Please use the OpenStreetMap Community Forum

I'm attempting to use OpenStreetMap to maintain the canonical geography for the bus routes for our transit system, and would like to export from OSM into a CSV for creating the shapes.txt file for the GTFS feed for the system.

I've created relations for each route:

What I need to do next is to find a way to export the points along these routes as a simple series of lat/lon points, in the right sequence. Each way in each route is tagged with "forward" or "backward" so, in theory, all the data needed to do this is present in OSM.

I've experimented with using for this, converting the relation for each route into a GPX. I then extract the track points from the GPX to make the CSV.

This works well for simple routes with a single track, as in this example for relation ID 3425884.

But for more complex routes, where there are ways that appear more than once in the same route (for example, driving up a road, turning around, and driving back the same road), I'm running into problems.

For example, in this GPX created from relation 5838068, the track segments appear out of route order, and so the resulting CSV file (which I extract from the GPX simply by extracting the lat/lon from each trkpt, in the natural order of the file) does not contain the points in route order, and when previewed in the it looks like this: rendering the route

If you compare that rendering to the rendering of the route in the OSM Relation Analyzer you will quickly see where things are going wrong.

I'm looking for help in either solving this issue improving the approach I've taken, or in identifying a different approach.

asked 13 Jan '16, 20:04

ruk's gravatar image

accept rate: 0%

rel2gpx has been designed for bicycle and hiking routes and it generally gives good results for linear routes without loops. In cases where the ways in the relation can not be assembled together to form a single line, it results in a collection of GPX tracks that have to be postprocessed manually if one wants to have a GPX track, for example to navigate along with a GPS device.

The different rendering by the schedule_viewer and the OSM relation analyzer is duto the fact, that rel2gpx results in six segments and apparently schedule_viewer interconnects the segments by straight lines to have a single line. If you leave out these interconnections, the rel2gpx GPX file is rendered the same way as does the OSM relation analyzer.

I am not familiar with public transport relations but I think that rel2gpx is not the appropriate tool for your purpose. There a are probably specific tags for this kind of relation which allow to create a list of points on the line in the correct order.

permanent link

answered 14 Jan '16, 07:16

rainerU's gravatar image

accept rate: 0%

There is the very old OSM2GTFS, but keep in mind what will be done with the GTFS path data. If it ends up in Google, that would probably violate the OpenStreetMap license. OSM2GTFS is very basic, and consider that it will likely require a software developer to produce good results.

permanent link

answered 14 Jan '16, 11:34

Mike%20N's gravatar image

Mike N
accept rate: 17%

I ended up hacking together a solution in PHP (sample code here) that uses the OSM API to grab the full XML of each relation, and then assembles the points, traversing each way forward or backward per the role assignment in the relation.

permanent link

answered 14 Jan '16, 22:00

ruk's gravatar image

accept rate: 0%

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 13 Jan '16, 20:04

question was seen: 6,935 times

last updated: 14 Jan '16, 22:00

NOTICE: is no longer in use from 1st March 2024. Please use the OpenStreetMap Community Forum