rGTFS
Tool to compare planned GTFS with real GTFS (rGTFS) extracted from GPS data.
Working API
import rgtfs
# Generage Realized Trips from GTFS
rgtfs.generate_realized_trips_from_gtfs(gtfs_path)
# Treat Rio de Janeiro BRT realized trips
rgtfs.helpers.treat_rj_brt_realized_trips(brt_raw_realized_trips_path)
New Tables Documentation
Realized Trips
| Field Name | Type | Required | Description |
|---|---|---|---|
| vehicle_id | ID referencing vehicles.vehicle_id | Required | identifies vehicle |
| departure_datetime | Datetime | Required | Time at which the vehicle departs from the first stop |
| arrival_datetime | Datetime | Required | Time at which the vehicle departs from the stop |
| departure_id | ID referencing stops.stop_id or garages.garage.id | Required | Departure unique identifier. Can be a stop_id or a garage_id. |
| arrival_id | ID referencing stops.stop_id or garages.garage.id | Required | Arrival unique identifier. Can be a stop_id or a garage_id. Can be empty if trajectory_type is garage_to_stop. |
| distance | Float | Required | Distance travelled in the trajectory in seconds |
| elapsed_time | Integer | Required | Trajectory duration in seconds |
| average_speed | Float | Required | Trajectory average speed in km/h |
| trajectory_type | Enum | Required | One of the followin trajectory types: 1. complete_trip: A complete one-way trip. Departure stop and Arrival stop should map to the first and last stop of the trip respectively. 2. not_complete_trip: An incomplete one-way trip. Departure stop should map to the first stop of the trip, but the trip was sundelly aborted so it has no Arrival. 3. garage_to_stop: A trajectory between a garage and a stop or otherwise. One of the stops should map to a garage_id. |
| trip_id | ID referencing trips.trip_id | Optional | Trip unique identier. Only applicable for trajectory_type: complete_trip and not_complete_trip |
| trip_short_name | Trip name | Optioanl | Public facing text used to identify the trip to riders, for instance, to identify train numbers for commuter rail trips. If riders do not commonly rely on trip names, leave this field empty. A trip_short_name value, if provided, should uniquely identify a trip within a service day; it should not be used for destination names or limited/express designations. It can be used if trip_id is not available. |
How to go about it
Set standards of how the GPS data should look like. What are the accepted columns? How should the feed be structured? What is the best fit with GTFS?
What are the expected results?
-
Retrospective GTFS, rGTFS, which is a GTFS of what actually happend on date YYYY-MM-DD
- Fully dependend on GPS. It'd have to create the shapes, stops, lines, etc
- Based on planned GTFS. It'd use the current GTFS shapes, stops and lines to support the algorithm
-
Comparisson between GTFS and rGTFS
- Difference in bus frequency/waiting times
- Difference in the fleet. What are the lines larges fleet difference?
- Ponctuality score.
How the module should look like?
- io (read and write to GTFS)
- GTFS object
- rGTFS builder to GTFS object
Similar Projects
Related projects by other people:
- https://github.com/CUTR-at-USF/retro-gtfs/tree/GTFS-Realtime (a fork of this code extending it to GTFS-realtime data sources)
- https://github.com/WorldBank-Transport/Transitime
3 maintainers
Metadata
3 maintainers
Release files for rgtfs 0.1.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| rgtfs-0.1.0.tar.gz | 10.1 kB | Without provenance | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| rgtfs-0.1.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 20.2 kB
Release files / rgtfs-0.1.0.tar.gz
| Download URL | rgtfs-0.1.0.tar.gz |
|---|---|
| Size | 10.1 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
53075eb57f2495644478888300d19e473deff7c4fa1211a2c3bafa8bcaacfc07
|
|
BLAKE2b-256 checksum How to use checksums |
d2790b851461f7dcc6911513e08251cc9409a58948235441e03cf04204c9aa5d
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
poetry/1.1.6 CPython/3.9.2 Darwin/18.2.0
|
Release files / rgtfs-0.1.0-py3-none-any.whl
| Download URL | rgtfs-0.1.0-py3-none-any.whl |
|---|---|
| Size | 10.1 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
a706db5854b6310348c11868e5bf51b704a7508d21309bd318527e420ac8a891
|
|
BLAKE2b-256 checksum How to use checksums |
0d1ab1c37f401940b2da79575c441555dcd97ed174263b8ea683ecaaa9172c35
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
poetry/1.1.6 CPython/3.9.2 Darwin/18.2.0
|
Security for rgtfs 0.1.0
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.
