Giter Site home page Giter Site logo

tmelliott / transitr Goto Github PK

View Code? Open in Web Editor NEW
21.0 4.0 0.0 5.35 MB

An R package for constructing and modelling a transit network in real time to obtain vehicle ETAs

R 48.62% C++ 49.59% Shell 0.27% M4 0.70% Makefile 0.18% JavaScript 0.54% C 0.01% TSQL 0.09%
transit gtfs gtfs-realtime r

transitr's Introduction

transitr

Travis build status codecov

The goals of transitr are to make it easy to load GTFS data into a database, construct a transit network of roads and intersections, and model vehicles in real-time from an API feed to update the network and generate ETAs.

install

transitr is not (yet) on CRAN, so for you would need to use devtools:

devtools::install_github('tmelliott/transitr')

usage

Still under development! This here is just for demonstration of what it could be like at some point in the future.

library(transitr)
library(magrittr)

## Create a database, construct network, and connect to a realtime feed
dbname <- "realtime.db"
nw <- create_gtfs("https://cdn01.at.govt.nz/data/gtfs.zip", db = dbname) %>%
    construct() %>%
    realtime_feed("https://api.at.govt.nz/v2/public/realtime/vehiclelocations",
                  with_headers("Ocp-Apim-Subscription-Key" = "mykey"),
                  response = "protobuf")

## Set the parameters and then run the model
nw %>% 
    set_parameters(n_core = 2, 
                   n_particles = 500, 
                   gps_error = 5) %>%
    model()

Once running, you can launch a new R session and view the shiny app:

transitr::view_realtime("realtime.db")

mock data server

In order to facilitate model development and checking, there's also a mock data server in the simulations directory.

To install:

cd simulations
yarn 

## or if you don't use yarn
npm install

To start the server, you need first an archive of vehicle position feeds,

ls archive | grep vehicle | head -n 5
# vehicle_locations_20180911050001.pb
# vehicle_locations_20180911050031.pb
# vehicle_locations_20180911050102.pb
# vehicle_locations_20180911050132.pb
# vehicle_locations_20180911050201.pb

yarn start
# yarn run v1.9.4
# $ node mock_server.js
# Mock GTFS server running on port 3000!

Now you can run the model with the local server, which will automatically serve the next file with each request.

## assumeing you've constructed with simulation flag:
## $ make FLAGS="-DSIMULATION"
## simulation history will be saved in a `history` directory
dir.create("history")

## set some process ID for the server to recognise (allows running multiple simulations simultaneously)
pid <- "test1"
nw <- load_gtfs("fulldata.db") %>%
    realtime_feed(sprintf("http://localhost:3000/%s/vehicle_positions", pid),
                  response = "protobuf") %>%
    set_parameters(n_core = 1,
                   n_particles = 2000,
                   gps_error = 10)

nw %>% model()

transitr's People

Contributors

tmelliott avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

transitr's Issues

Particle mutate up to event (not timestamp)

In the case that Event is a GPS position

  • travel until delta = 0

In the case that Event is a stop time update

  • travel at least until delta = 0
  • continue travel ahead until particle arrives at (and departs, if departure Event) e.stop_index

When commencing an iteration

  • remove delta_ahead from delta to wait for vehicle to catch up to particle
  • if departure_time > _timestamp, randomise remaining dwell time (allows resampled particles to diversify)

Other

  • if at a stop, be sure to set departure_time when leaving stop

Handle pre-arrival observations

Oftentimes when a vehicle approaches an intersection/stop, it registers as "at the stop" before it actually arrives, and a subsequent observation places it "behind", thus breaking the algorithm because the buses can't go backwards again.

Separate model file to allow easier model specification

Look into using configure --model=model1.cpp or similar for a compile-time model spec.

Is there a way to provide a runtime model spec? i.e., allowing R users to use the package without compiling it each time the model is changed?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.