1.0 API Design

[teburd]

It would be much nicer to simply work with the .zip file

Ex:

let gtfs = GTFS::from_zip("gtfs.zip").unwrap();
for agency in gtfs.agencies() {
   println!("{:?}", agency);
}
for stop in gtfs.stops() {
   println!("{:?}", agency);
}

Solved with #14

[teburd]

For a 1.0 release lets talk about what we want this crate to look like and how we want it to work.

I think we're on the right track so far. Generally speaking I'd like to differentiate between GTFS the format, and a TransitNetwork the API.

Things I'd want to be able to do with a GTFS type

• Read GTFS and decode into useful structures
• Write GTFS and encode useful structures
• Validate based on the rules given by the spec

Versus things I'd want to be able to do with a TransitNetwork type

• Get general information about the network (agency, shape, etc)
• Get a list of routes and their types
• Get a list of stops for a route
• Get a list of stops near a location
• Get related information for a stop (routes, trips, stop times, geolocation/shape)

I'd like to think that TransitNetwork is a trait, not an implementation, and that there would be an implementation for GTFS but that their might also be an implementations for perhaps the wide variety of live transit API's out there.

I think a lot of what your thinking is similiar to what I was thinking for what I'm tentatively calling the TransitNetwork trait. It can aggregate shapes/stop times, have various indices and such to help provide the convenience I think most people (myself included) really want to get out of the data that is stored in GTFS and provided by various transit APIs

I look forward to your thoughts. If we get a nice plan together we can break things down and work on various parts individually and together as we need to.

[medwards]

I don't need writing or validation atm but FWIW I think you're right that it should be included in a 1.0 release. GTFS reading is also still unfinished: we're missing Extended GTFS support. Whether that needs to be in place for a 1.0 release or not is a separate discussion, for now I'm just reminding you.

As far as TransitNetwork stuff: I think you've defined a good set of high level features that are of interest to feed consumers. I'd be careful about trying to get abstract and making it a trait at this juncture, in particular GTFS makes a lot of decisions about its domain model that aren't reflected in other specs. That's a decision we can always revisit anyways.

I have some ideas for an extended feature set for TransitNetwork too but the scope is already pretty big so imma hold back.