Skip to content
Sean Óg Crudden edited this page Mar 8, 2018 · 4 revisions

I have change the GTFSFileProcessor to create a barefoot map file that can be used by the barefoot tracker server. I then changed the AVL processor to send AVL reports to the tracker server (configured with map file) and then ask for the adjusted value to subsequently do normal transiTime spatial/temporal matching on. The barefoot map created is based on the shapes.txt file in the GTFS file. So it snaps GPS locations to transit routes, not to any road.

Next step is to find some data to demonstrate an improvement. I will be looking at data from Atlanta Streetcar as matching presented a problem during the "holding method" trial.

I got around to testing this setup with Atlanta streetcar and to make it more interesting I used data generated from a Traccar server which was fed with GPS from a mobile phone on the streetcar. The mobile phone has the Traccar android app running. This had very good results and appears to do as expected and mitigate issues with matching to the wrong trips.

The setup is different than as described above. I have created a OneBusAway module to create the barefoot map from GTFS. The map is then consumed by a barefoot server and updates from the barefoot server are processed by TheTransitClock. TheTransitClock gets the updates from the barefoot zeromq publish/subscribe socket. There is a new transitlock module that reads from barefoot.