Giters

OneBusAway / onebusaway-gtfs-modules

A Java-based library for reading, writing, and transforming public transit data in the GTFS format, including database support.

Home Page:https://github.com/OneBusAway/onebusaway-gtfs-modules/wiki

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

RFC: GTFS-Flex v2 support

hannesj opened this issue · comments

commented

I would be interested in implementing support for the GTFS-Flex v2 proposal, in order to kickstart work on implementing It for OpenTripPlanner.

There are however couple of open questions.

locations.geojson

Currently the GTFS specification only supports CSV files. There is an open discussion within the draft discussing the pros and cons of various formats, with leaning towards storing the locations in GeoJSON. This would mean adding a new dependency for (de)serialization the JSON. Do you have any preference for the library? Would adding org.locationtech.jts together with org.json be too heavy, or should we just use org.json, and do the validation ourselves?

Multiple possible types for stop_id in stop_times.txt

Currently the tables have references only to single type of entities. With GTFS-Flex however, the stop_id in stop_times.txt can be of type Stop, Location or LocationGroup. Implementing this will in any way be a backwards incompatible change, as the stop will not always correspond to a stop, which it does currently. There are a couple of different ways to approach this, fo you have any feedback on which of these (or something else) would be preferrable? With both approaches there is still the problem of validating that each id appears at most once between each of the three types.

Multiple fields with a single type each

Add fields location and locationGroup and fill in the appropriate when loading data. For the setters for each of the three fields, we would always null the other two.

Interface type, with multiple implementing classes

Add a new interface type eg. Stoplike, and make Stop, Location and LocationGroup implement it. The interface would only have an AgencyAndId id field (+ possibly the name), and during loading we would need to have a new MappingFactory, which would check which of the corresponding entity types exist.

commented

@hannesj Very cool!

locations.geojson

I would strongly suggest using Jackson with https://github.com/opendatalab-de/geojson-jackson for parsing GeoJSON. There is very little code to write to get the GeoJSON into a Java model object - see the README for an example.

Jackson is used elsewhere in the OBA ecosystem, and we're using above combination in a Java client we created for the Pelias geocoder to parse GeoJSON:
https://github.com/CUTR-at-USF/pelias-client-library

commented

@hannesj our team at Cambridge Systematics would be interested in helping out, at the very least to review and potentially help merge down the line, if not more.

And to clarify for my understanding - is your intention to enable Flex v2 with OTP1, OTP 2, or ideally both? @barbeau any thoughts welcome from you too (esp. if it's the wrong question...)

commented

I would strongly suggest using Jackson with https://github.com/opendatalab-de/geojson-jackson for parsing GeoJSON.

Thanks, this seems like a good choice, I only studied this repo and didn't notice any usage.

And to clarify for my understanding - is your intention to enable Flex v2 with OTP1, OTP 2, or ideally both?

OTP v2, as v1 already has a working implementation for the previous version of GTFS-Flex. As the new version of OTP uses a new algorithm for journey planning, it means not much of the existing code can be shared between the versions.