Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add station type attribute for stations #27

Open
elliottwilliams opened this issue Sep 9, 2016 · 3 comments
Open

Add station type attribute for stations #27

elliottwilliams opened this issue Sep 9, 2016 · 3 comments

Comments

@elliottwilliams
Copy link
Member

As a transit rider who occasionaly has to wait 10-15 minutes to catch a bus, I prefer it when I can wait at a shelter with a bench. During inclement weather, it's doubly essential to me. Proper Shark should show me what kind of station a particular stop is, be it a shelter, a sidewalk, or a transfer hub.

I propose adding a kind enum attribute to Station, which derives its possible values from object configuration. For CityBus, the kinds would be :roadsign, :shelter, and :transfer_hub, unless there are some more standardized terms for these that I'm missing.

By default, Stations would be configured to be kind = :roadsign. :shelter can be determined by the station name, probably using the same middleware from #23, and :transfer_hub can be configured to the station with stop code BUS215.

@faultyserver
Copy link
Member

I think this is certainly doable, and your suggested implementation will probably work best. I wasn't aware that station names had "at Shelter" annotations on them, but it seemed to be accurate for all of the stops I could think of.

The only "official" names that I've been able to find are from GTFS, which only specifies "stop" and "station" (neither of which actual give relevant information).

Note that the actual implementation of this will be pending on #20, which will define the way attributes like this are added via middlewares.

@elliottwilliams
Copy link
Member Author

Great. I think this is something that is deliberately not in 1.0, but it's here for when you can get to it.

@faultyserver
Copy link
Member

With the implementation of #20, this shouldn't have any obstacles to implementation. If we want, we may be able to pull this into 1.0, but I'll leave it out for now.

@faultyserver faultyserver added this to the v1.1 milestone Sep 25, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants