search

opentripplanner / OpenTripPlanner

An open source multi-modal trip planner
http://www.opentripplanner.org
Other
2.17k stars 1.02k forks source link

Replace existing GTFS code with OneBusAway's GTFS Library #21

Closed novalis closed 13 years ago

novalis commented 13 years ago

OneBusAway has existing libraries for reading/writing GTFS, as well as storing it in a database using Hibernate. I propose replacing the existing gtfs functionality that Brandon wrote with the OneBusAway libraries.

A couple reasons why:

1) This library has been in production use by OneBusAway for a while and it's well-tested. 2) The OneBusAway GTFS libraries have been carefully designed to deal with multiple agencies in the same data store. By multiple agencies, I mean handling multiple GTFS feeds in the same graph/database/etc. The GTFS spec makes no guarantees that stop, trip, and other entity ids will be unique across GTFS feeds, and I believe the current OTP GTFS codebase will start running into issues when we attempt to interleave feeds from geographically nearby transit agencies into one graph.

Documentation about OneBusAway's GTFS libraries:

http://code.google.com/p/onebusaway/wiki/ModuleGtfsExamples http://code.google.com/p/onebusaway/wiki/ModuleGtfsHibernateExamples

Now a couple reasons why not:

1) Brandon, I know you looked at my library at some point and decided not to use it. I'm interested in hearing your reasons. 2) Currently, the onebusaway-gtfs-hibernate module has a dependency on the Spring IOC framework. I can remove that if it's a big deal.

I'm happy to do the work to transition the existing codebase, but since it's a non-trivial change, I'm definitely looking for feedback / votes.

novalis commented 13 years ago

+1 -- multiple agencies are definitely a case we want to support.

The one thing I'm not sure about is the hibernate bit -- I'm not opposed to using a database, but I want to make sure that it's not going to cause performance problems.

I think using Spring IOC is a good idea generally, and it seems to be fairly standard.

--novalis

novalis commented 13 years ago

Replying to [comment:1 novalis]:

The one thing I'm not sure about is the hibernate bit -- I'm not opposed to using a database, but I want to make sure that it's not going to cause performance problems.

I agree that Hibernate (or any database persistence mechanism) needs to be handled carefully with respect to performance. My general strategy in OneBusAway has been to use the database as the root data source, but use intermediate caching all over the place such that the database is hit only rarely. While we might hit the database a few times to construct the initial trip planner graph, for example, I don't think there should be any database hits at all in the actual trip plan generation.

--bdferris

novalis commented 13 years ago

{{{

!html

}}} This ticket has been referenced in ticket #16:

''...memory. Hopefully the OneBusAway GTFS library will make this easy. See ticket #21.''

--bdferris

novalis commented 13 years ago

--nicholasbs

novalis commented 13 years ago

Agreed to officially use the OneBusAway GTFS code at today's meeting.

--nicholasbs