Better instructions for GTFS export/conversion?

[skinkie]

What instructions are you looking for?

[hypervtechnics]

Like a CLI command or step-by-step instructions. Currently there are no unified steps for conversion from Netex to GTFS. There are some covered as comments in some xml files somewhere in this repository. But those comments are also not that kind of helpful. The whole export seems like a pretty fuzzy and complicated thing to do. Although it's described as very easy on the website.

Can you provide such instructions? Do you have more resources on this topic? Or some hints which are helpful?

[skinkie]

The comments in the XML files present a semantic equivalent how GTFS data could be stored in the NeTEx ontology, we call this a profile. There is no conversion or translation between profiles described. Software packages - even open source - do exist to read a NeTEx profile, for a example the Dutch, EPIP or Nordic NeTEx Profiles and convert them to GTFS.

The main question is: what do you want to do with the data. Not converting it into a gazillion different competing standards. For example the software that I create reads GTFS, DINO, HAFAS and stores this in an intermediate NeTEx representation, so the standards are expressed in NeTEx. It creates transparency and an opportunity to do a transitive conversion between network and timetable concepts.

If you are looking for a GTFS conversion, please ask yourself first: what am I going to use from GTFS in my application. You will directly see that a conversion is not required at all.

[hypervtechnics]

Thank you for your response. Could you provide links for or name some of those open source projects you mentioned?

We want to make OpenStreetMap somehow usable for normal users on the same or even a higher level as e.g. Google Maps. Therefore we are including routing for public transport. We intend to use OTP (I saw you commented on some of the issues there :D) for this which did only support GTFS back when we chose and discussed it. Now we discovered two things: the dev-2 branch which added NeTEx support to OTP and our data provider publishes data now as NeTEx and GTFS. Sadly OTP does not support the EU profile (yet?) and the GTFS files used directly are malformed according to OTP.

Therefore the GTFS conversion got somehow obsolete. We want essentially two things: Routing, search stations and departure monitors for a specific station.

Maybe you can share some knowledge on this topic?

[skinkie]

@hypervtechnics OTP 2.x supports the Nordic profile which on some small bells and whissles is different than the EU-Profile. Norway splits their files into a network, and lines. The EU-profile publishes it in a single file (as far as I saw in Luxembourg, which uses the same software as Germany). Hence your first step is to get into the Entur slack channel where the OTP 2.x development happens to discus the implementation of the EU profile.

Entur uses an older version of http://www.transmodel-cen.eu/implementations/tools/chouette which is heavily modified to fit their needs.

Regarding world scale routing: you wouldn't be able to do that on OTP alone. It's algorithm just wouldn't be suited for it. Country scale tops.

[nick-knowles]

FYI Mapping "classic GTFS" is fairly straightforward as there is a one to one correspondence for most elements. There are some points of confusion though. a) The Gtfs stops maps primarily to a SCHEDULED STOP POINT (i.e. the Transmodel concept of a stop in timetable) , but in the recent additions to the GTFS model they have also overloaded the GTFS stop with physical stop concepts, (i.e STOP PLACE and QUAY, ACCESS SPACE , BOARDING POSITION, and ENTRANCE) but have not articulated the relationships properly, so the mapping gets very intricate (and there are some loophole sin the Google spec - for example how to relate a BOARDING POSITION to a QUAY) . I am working on some detailed examples that show the issues. b) The GTFS stop_times essentially corresponds to a CALL - (I.e. a POINT IN JOURNEY PATTERN + PASSING TIMES) . However Gtfs has no notion of a JOURNEY PATTERN. c) A GTFS calendar corresponds to a DAY TYPE + a DAY TIME ASSIGNMENT for a period. a) GTFS calendar date corresponds. to a DAY_TYPE ASIGNMENT for a specified date