Working with non-direct routes

[j...@agnew.co]

I was wonder if someone could point me in the right direction. I’m new to using the National Rail data feeds and apologies if this is silly question. I want to be able to search for example KGX -> MBR which would required a change normally in DAR (or YRK). I would like to get a list of possible ways to complete that trip for example.

17:00 KGX -> MBR 20:01 (1 Change DAR)
17:30 KGX -> MBR 21:01 (1 Change DAR)
18:30 KGX -> MBR 21:58 (1 Change YRK)

I’ve taken a look with the OpenLDBWS which works for direct routes but not non-routes. So I did a bit of looking and I noticed they have OJP data feed available but it appears to be little more formal with licence request etc.

I was wondering what is the best way to achieve my goal? any piece of advice would be much appreciated.

Thanks, Jason

[Peter Hicks]

Hi Jason

To calculate a non-direct journey between two locations, you'll need to either implement the logic in the Routeing Guide (plus its comprehensive set of easements - and neither is available under an Open Data style licence at the moment), or use the Online Journey Planner (OJP) feed.

There is a bit more to it than that, but it gets really technical.

Peter

--
You received this message because you are subscribed to the Google Groups "A gathering place for the Open Rail Data community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openraildata-t...@googlegroups.com.
To post to this group, send an email to openrail...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Linus Norton]

Sorry for the shameless plug but...

I have an open-source journey planner you can use if you would like. It's still a bit of a work in progress but you are free to use the puiblic API (within reason). You can check it out in action at http://traintickets.to

If you have any questions on building a journey planner it might be useful to read (another shameless plug!) my blog post on the topic.

Good luck!

[Linus Norton]

I should also add a slight health warning:

It does not currently conform to the National Routeing Guide and is not approved by RSP or any other official body of any kind. 

:)

[j...@agnew.co]

Hi Peter & Linus

Thank your both for replying.

@Peter it’s a shame the data isn’t more open. OJP would be a easiest option but I noticed they mention charges but no prices:

“The RTJP Webservice is charged at cost recovery rates”

@Linus I’m glad for your shameless plug :) it was an interesting read and I’m glad to see your using Silex.

I’m not sure what approach I’ll take - I was bit naive in thinking with the focus on Open Gov (data.gov.uk) these days there might of been a single open API instead of requiring the use of OpenLDBWS and OJP (or constructing your own dataset from timetables).

Thanks again for both your help.
Jason

[Paul Kelly]

On 09/19/2016 12:28 PM, j...@agnew.co wrote:
>
> I’m not sure what approach I’ll take - I was bit naive in thinking with the focus on Open Gov (data.gov.uk) these days there might of been a single open API instead of requiring the use of OpenLDBWS and OJP (or constructing your own dataset from timetables).

Interesting point. If you have a single open API for things then the
technological approaches and algorithms used in implementing that API
are somewhat "baked in" and I'd argue that it isn't then fully open.
This is a problem with some of the TfL APIs, for example.

My personal feeling is that the National Rail data is much more open
because you can get the raw data and do whatever you like with it. For
example, to use your example from last night - you have two journey
opportunities leaving King's Cross at 17:00 and 17:30, and changing at
Darlington and going via Dinsdale to get to Middlesbrough, and one
leaving King's Cross at 18:30, changing at York and going via Yarm to
arrive at Middlesbrough at 21:58.

But you could equally well take the 18:30 off King's Cross and change at
Darlington as per the other two itineraries, arriving at Middlesbrough
16 minutes later at 22:14. But National Rail Enquiries won't show you
that itinerary, even though it's perfectly valid and permitted. You
might have wanted to meet a friend in Darlington to join you on your
journey to Middlesbrough, and got the impression you would need to leave
earlier than the 18:30 to do that.

With the full timetable data available you have much more choice and
power, should you choose to use it.

Paul K

[Peter Hicks]

Hi Jason

> On 19 Sep 2016, at 12:28, j...@agnew.co wrote:
>
> @Peter it’s a shame the data isn’t more open. OJP would be a easiest option but I noticed they mention charges but no prices:
>
> “The RTJP Webservice is charged at cost recovery rates”

I don’t know exactly what the rates are, but I’m led to believe it’s a very reasonable rate since it’s operated by a third party.

I am not aware of a technical reason why the Routing Guide, in electronic format and thus easily parseable, couldn’t be made open. From a different angle, there may be a long-established process in place to certify a routing engine as compliant with the Routing Guide, and this may present an issue.

However, weighed up against this is the possibility of community-driven integration tests which could be run against an implementation of a routing engine to prove it produces the correct result. An automated, non-trivial set of Cucumber stories and scenarios, with glue code written to integrate these to whatever API or front-end is available, could complete the job. It’d also have the secondary benefit of not requiring any manual validation of routing engines.

I am up for taking this on, with some others, as a community project!\


Peter

[Peter Hicks]

Hi Paul

> On 19 Sep 2016, at 13:00, Paul Kelly <pa...@pdkelly.de> wrote:
>
> Interesting point. If you have a single open API for things then the technological approaches and algorithms used in implementing that API are somewhat "baked in" and I'd argue that it isn't then fully open. This is a problem with some of the TfL APIs, for example.

This. And I believe you need both:

* An API to lower the barrier of entry to people wanting to work with data (e.g. somebody who just wants to show departures on a screen)
* Live, bulk data to let people do things with data that you haven’t thought about (e.g. integrating it with other data sources)

I think there’s also a third need:

* A historical store of raw data going back a certain number of months to allow people to analyse the data without having to wait for x months to gather sufficient data



Peter

[petermount]

I think a few of us would be able to chip in on this...

[George Goldberg]

On 19 September 2016 at 13:02, Peter Hicks <peter...@poggs.co.uk> wrote:

However, weighed up against this is the possibility of community-driven integration tests which could be run against an implementation of a routing engine to prove it produces the correct result.  An automated, non-trivial set of Cucumber stories and scenarios, with glue code written to integrate these to whatever API or front-end is available, could complete the job.  It’d also have the secondary benefit of not requiring any manual validation of routing engines.

I am up for taking this on, with some others, as a community project!\

Excellent idea. I'd be very happy to help work on this too if we can get the routing guide data needed out into the open.

--

George

[Linus Norton]

A set of tests would help me immensely. I don't have the knowledge (or access to NRG) to contribute to writing the tests unfortunately but I would be more than happy to take a stab at implementing them if someone is happy to write them. 

--
You received this message because you are subscribed to a topic in the Google Groups "A gathering place for the Open Rail Data community" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openraildata-talk/30EWZT5Vc4s/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openraildata-t...@googlegroups.com.
To post to this group, send email to openrail...@googlegroups.com.

[j...@agnew.co]

Hi Everyone

To clarify my point about a single API, I meant it would be nice to have the entry level API which encourages hobby projects right through to basic applications. There’s a lot of knowledgable people in this group and having access to the raw data allows them build complex applications but for someone new like myself in one day of looking at train data, I haven’t really got that far. If you take an example of a basic mobile or web app you would have maybe 4 features:

Journey Planner -> National Rail OPJ
Departure/Arrival Boards -> National Rail OpenLDBWS
Train Location -> Network Rail Movements
Find Info On Specific Train -> Not sure which I should use?

That currently requires a developer to sign up to multiple services and accept quite a few different terms and conditions. And the National Rail OPJ from what I’ve read has a wait time before you get accepted? and it uses IP access instead of tokens - I plan to request access today.

In an ideal world you’d have an API to cover those basic features above. The developer would be required to sign up for account providing a credit card. They’d be billed per API request to help cover the cost of the service.

Thanks for everyones help so far, I’ve learnt quite a bit from this thread.

Jason

[Mike Flynn]

I'm planning to get started soon on development of a uk rail journey planner.  I haven't yet decided for sure exactly which way to go but was thinking to develop my own, rather that using the NRE api, with the idea of adding a proviso/disclaimer on my website(s) that the calculated routes may not necessarily conform to the National Routeing Guide. I've done something similar with the London Underground and for my purposes, websites, it works reasonably well.  I started out looking at the TfL api but found it was slow, restrictive and dependent and like Paul K says you can do what you like with raw data, essential if you want to compete for organic search.  For my tube site I used the Djykstra algorithm as the basis for determining routes and hadn't previously known of the Connection Scan Algorithm, as used by Linus, and will probably follow this path (pardon the pun :) now.  Looks pretty neat.

As regards a community based effort of creating an open and compatible routeing data set, if this is as I understand what is being proposed, and it fits in with my plans above, I'd be more than happy to contribute if needed.

[James Singleton]

Happy to help too. The OJP API isn't actually that bad. It's still SOAP but uses standard HTTP basic auth, so no passing custom tokens around. I believe they offer a static IP auth version as well, but I haven't used that. It also includes real-time Darwin information so you shouldn't need to make a separate call to the LDB API. You may need to manually fix the auto generated service reference though. If they open it up I'll probably make a JSON proxy similar to how Huxley (https://huxley.unop.uk/) works for the LDB and staff LDB APIs. If you ask nicely they should give you free access as long as it's a light load.

OJP is still much nicer to work with than the SilverRail APIs. Client certificate auth and you have to override the channel defaults as the SOAP responses are huge (megabytes of XML).

You may want to look at http://www.transportapi.com/ which is nice and has a free tier. I've not used it much though.

[andrew.t...@gmail.com]

Just for information of the wider community.

As indicated elsewhere on this thread, ATOC is currently not in a position to open up the OJP API (a.k.a. RTJP web service) as unlike Darwin, which is entirely owned and operated by ATOC, the OJP service is 'powered' by a supplier with whom ATOC has a commercial contract.

Exact costs to use the RTJP web service (which are subject to indexation) can be obtained by contacting ATOC as per the NRE website but for context it is in the order of £40 for per 100,000 enquiries.

Andrew