http://github.com/bmander/gtfs
The gtfs package is little more than a marriage of the csv, sqlite3,
and sqlalchemy packages around the GTFS schema. It works by loading
the zipped CSVs into a sqlite database and then using sqlalchemy to do
the ORM on the database tables. It can work basically like transitfeed
when using the default memory database:
>>> import gtfs
>>> sched = gtfs.load( "bart.zip" ) #takes a minute
>>> sched.routes
[<Route AirBART>, <Route 01>, <Route 02>, <Route 03>, <Route 04>,
<Route 05>, <Route 06>, <Route 07>, <Route 08>, <Route 11>, <Route
12>]
But it really shines when you use an on-disk database
>>> sched = gtfs.load("bart.zip", "bart.db")
>>> exit()
quit, walk away, have dinner, come back, start again
>>> import gtfs
>>> sched = gtfs.Schedule( "bart.db" )
>>> sched.routes
[<Route AirBART>, <Route 01>, <Route 02>, <Route 03>, <Route 04>,
<Route 05>, <Route 06>, <Route 07>, <Route 08>, <Route 11>, <Route
12>]
>>> sched.stops[0].stop_times[0].trip.route.agency
<Agency BART>
Hope you all find it useful,
-B
FYI: the current merge & transitfeed.py has performance problems with
huge feeds; one example if the NYCT bus data (available at
http://mta.info/developers), which I haven't managed to successfully
merge on my machine (up until now at least, MTA has been providing
GTFS feeds that spans distinct, contiguous period: X->Y, then Y+1 ->
Z, etc.. and one needs the feed merger to have a continuous database
around day Y or Y+1).
I'm wondering if your port would make things better. At least that's a
challenge :-)
> --
> You received this message because you are subscribed to the Google Groups "Transit Developers" group.
> To post to this group, send email to transit-d...@googlegroups.com.
> To unsubscribe from this group, send email to transit-develop...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/transit-developers?hl=en.
>
>
-B