Public Transit APIs

[Andrew Jawitz]

  Having just discovered the Transport for London node, I wonder if the same method can be adapted for use with the thousands of other cities around the world who have open transit data feeds available?  If properly implemented, NodeRED could be a really powerful tool by packaging the various transit APIs into a standardized and more accessible format.  While many agencies like Boston's MBTA-Realtime, NYC's Bus-Time and the Bay Area BART Realtime provide developer API through a dedicated developer portal akin to the TfL data there are thousands of feeds available in the GTFS format that may not be as prepackaged but nonetheless share a common standard.  

  Providing a standard template for building a Transit NR-Node would make flows less dependent on geography while making it much easier to put local transit data to use in new creative ways.  So if I were to use the BART-realtime feed to create a flow that triggers a smart bulb to flash red when a bus is approaching a nearby bus stop, another user would only need to change a few parameters to use the same flow in say Portland, Maine.

  Is this something that can be done, or am I oversimplifying?

[Dave C-J]

Certainly worth investigating...

a quick look at the GTFS site would suggest it's not actually real time info - more like a good source of timetables etc... so as long as the buses stick to the timetable you may be OK .... maybe...

there is also GTFS-realtime - but not so easy to find feeds for that... though this project seems pretty hooked in - https://github.com/OneBusAway/onebusaway/wiki/GTFS-Realtime-Resources (but is all Java :-)

However given that this post is 2011 - http://google-latlong.blogspot.co.uk/2011/08/introducing-gtfs-realtime-to-exchange.html

and knowing how Google like to drop non-core projects I wouldn't get my hopes up...

We also have the geofence node https://www.npmjs.com/package/node-red-node-geofence - which should help more general solutions of this nature...

[Edward Vielmetti]

Another possible project to hook into is Owntracks

http://owntracks.org/

https://github.com/owntracks/owntracks/wiki/JSON

which tracks personal location. Once upon I time I wrote a little bit of code to parse an Amtrak vehicle location page and feed it into MQTT in a form that Owntracks could read it.

--
http://nodered.org
---
You received this message because you are subscribed to the Google Groups "Node-RED" group.
To unsubscribe from this group and stop receiving emails from it, send an email to node-red+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Edward Vielmetti +1 734 330 2465

edward.v...@gmail.com

[Andrew Jawitz]

I'd definitely be interested in checking out your AM/OWN-Trak code!  

For one thing Amtrak data is frustratingly difficult to work with beyond what can be pulled off their web site using services ala- http://dixielandsoftware.net/Amtrak/status/StatusMaps/.  About a year ago there was some progress when they set up an instance with Google Maps Engine which allowed people to put together unofficial realtime APIs like- https://github.com/kurtraschke/amtk-gtfsrealtime.

Another reason I'd be interested is because I've been working on a vehicle tracking project of my own that would use a version of Owntracks to facilitate communication with an Arduino-based GPS tracker- 

https://groups.google.com/forum/#!searchin/node-red/Vehicle$20Tracking/node-red/vmelHZH74Xo/OF1wMxxpJc0J

I never considered using MQTT/Owntracks with existing data feeds however, but it might make a lot more sense than legacy multimodal transit data integrators like OpenTripPlanner and OneBusAway.

[Andrew Jawitz]

I can give some more background into the state of GTFS and GTFS-RT...  It is indeed correct that GTFS is primarily oriented towards static schedule data and GTFS-RT has been a somewhat flawed release.  From the perspective of the end-user, the difference between static and real-time feeds comes down to what your actually trying to accomplish with it.  Static GTFS was created for trip planning tools like Google Maps, or OpenTripPlanner (which allowed you to combine transit schedule feeds with other datasets including OpenStreetMap,Elevation, bikeshares, carshares etc...) while realtime data standards grew out of OneBusAway which was originally created by a college student named Brian Ferris to help him get around the Seattle Washington region.  Eventually, Brian went on to head up Google Transit and yes...  GTFS-Realtime.  As an open source project, OneBusAway was adopted as the framework for the NYC BusTime API, which is still well regarded for its flexibility.

 The laudable goal of both OTP and OBA was that data integration could lead to better connections between various modes of transportation.  But the resource-intensive nature of the Java-based platforms severely limited their reach.  Most recently, the Java-based dinosaurs have been giving new life in the age of server-side javascript... Developers like Mapzen and Conveyal, whose work with transitive.js and transitland has created a whole new set of tools to work with.

  So as far as data is concerned, there's plenty to work with! I'm just not sure how to go about integrating it into a NodeRED node.  For example Conveyal, has a tool that converts GTFS into JSON- https://github.com/conveyal/gtfs2json and many other similar conversion utilities...