suggestion: adapt to NeTEx/OJP

[skinkie]

I just saw your message on the mailinglist. Are you aware of the data models used in this data exchange standard for journey planning? https://github.com/OJP-VDV/OJP

[juliuste]

Thank you very much for mentioning/referencing this! 🙂 I somehow forgot about your comment here and should have answered earlier, I'm sorry about that 😕

However: I have heard about NeTEx, OJP and the ITS directive, but I have some reasons to continue working on FPTF/FPTI for now:

• Even though most operators we have covered so far are situated in the EU 🇪🇺, FPTF/FPTI themselves are not constrained to the EU, so even after January 2019 there will be operators in other regions which don't provide data in the given format(s) and therefore the need for (inofficial) client libraries by the community will continue.
• FPTF/FPTI is probably best suited for environments close to the end-user (the “last mile” for transit information). To give an example: With loads of operators that provide their data decentrally, we will probably still see journey planning and similar tasks being performed on (less centralized) servers instead of on every end-user's device itself. While those servers can certainly collect their data from the operators in the format enforced by the directive, it might make sense to use a different format in the communication between this server and e.g. an app. FPTF is made for exactly those use cases, so that it can be easily used by developers who don't know much else about the system. This is one of the main concerns I have about the proposed formats (disclaimer: I only speak from previous experience here, I have not had a deep look into the proposal yet), that they are not as easy to use and understand as FPTF.
• As far as I know, the earliest point at which we will see wide-spread adoption of the given format is going to be January 2019, with the possibility of many operators/countries (not sure who is legally responisble in the end) paying fines instead of adopting in time because there might be technical hurdles that cannot be resolved in time (I am especially worried about Germany here). So there is still some time left where our inofficial libraries and with that FPTF/FPTI are quite useful on their own. Of course 4-12 months might not be much from a political point of view, but for fast hacking/prototyping and highlighting use cases for public transit data (which FPTF/FPTI is especially good for), this might actually be quite a long timespan, I'd say.

Of course this doesn't mean that I'm not also excited about the directive and (hopefully) the standardization and data liberalization that come with it. I'm just very curious about the level of adoption we will see come January.

Other FPTF contributors like @derhuerst or @kiliankoe might have different feelings about this, though.

Anyway: I am really thankful to you for mentioning the ITS legislation, I will have another look at everything that comes with it in the near future! By the way: Am I even right about January 2019 being the “deadline” for adoption or did I get this wrong? 😄

[skinkie]

The point is not about making a javascript library other than OJP for client communication. The point is that you are using different object names and API calls. It wouldn't hurt your project to at least use the common international naming. Hence it would show when the architecture of the European proposal do not meet a use case. Hence lets at least agree to use the same vocabulary.

[derhuerst]

To be honest, I find the OJP documentation linked by @skinkie not very accessible. Is there a short overview on the API calls & object names?

[skinkie]

htp://stefan.konink.de/djp.pdf

[juliuste]

As far as I understood the document, there is no vocabulary defined for static data (such as schedule or trip, which is usually rather used for scheduled movements of one vehicle than for journeys).

I therefore sadly don't see a way to rename our methods according to this schema because some crucial vocabulary is still missing in the document.

Thank you very much for approaching us with this document, though! Also: Feel free to reopen this issue if I misinterpreted the document.

[skinkie]

@juliuste it is completely based on an existing standard called "TRIAS" which is transformed to the international TRANSMODEL public transport standard. Of which NeTEx is currently the XML incarnation.

[derhuerst]

Will look into this further soon and give my opinion.

[skinkie]

The point is obviously not "you are doing it wrong" but "you are creating something new, that doesn't make sense with respect to what every transport company is going to implement". So if you need something like JSON, you might be also interested into something like SIRI-Lite.

[pietercolpaert]

I would vote for using JSON-LD with the transmodel ontology instead: https://github.com/oeg-upm/transmodel-ontology/