New Data/File: Station Services

[fruminator]

Hey all. We already provide special services at certain Citi Bike stations, and we plan to add these to the Citi Bike app this spring/summer, and we want to do that via GBFS. These types of services include the following:

• Valets/corrals - human powered services to ensure bike and/or dock availability (eg http://citibikeblog.tumblr.com/post/91056867097/updated-bike-valet-service-coming-to-7th-and-a)
• Ambassadors - people at a station to help them buy a pass, learn how to dock/undock, etc.
• Special sponsored services (totally custom, to be defined)

For each of these, we will want to represent the following (at a first pass):

• Service Type (e.g. valet, corral, ambassadors, sponsor, other)
• Service Summary ("Valet at 7th and A")
• Service Description ("guaranteed bikes and docks at 7th and A on weekday evenings. our friendly citi bike valets will make sure you always have a bike or dock from 7pm to 11pm on weekday evenings")
• URL (to an online description of the service)
• Opening Hours -- yes, we should use OSM Opening Hours for this. Unlike service/system alerts, these things are often regularly occurring. For example, weekdays from 7am - 11am. or weekdays from 7am-11am and 3pm-7pm. but not holidays. etc.
• Station ID(s) - one or more stations that the service applies to.
• Other adminstrativa such as entity ID, entity last updated timestamp, etc.

There is a potential argument that this could be wedged into the system_alerts.json but it feesl to me like around peg in a square hole. Special services are likely to be an area of continuous innovation.

So, questions for the group:

1. what think, broadly?
2. thoughts on how we would roll this out in one city on an expedited, trial basis. I'm thinking we just publish it and start using it.

[fruminator]

@jcn @fkh @mplsmitch @cubbi @mdarveau do you guys get emails for new issues such as this? did we ever set up an email list?

[mplsmitch]

I get them

On Tue, Mar 15, 2016 at 10:18 AM, Michael Frumin [email protected]
wrote:

@jcn https://github.com/jcn @fkh https://github.com/fkh @mplsmitch
https://github.com/mplsmitch @cubbi https://github.com/cubbi @mdarveau
https://github.com/mdarveau do you guys get emails for new issues such
as this? did we ever set up an email list?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#16 (comment)

[jcn]

My initial thought would be that these are actually 2 (or possibly 3) different extensions:

1. The corrals/valets are basically stations with unlimited capacity and is_renting being 0. So the question is one of implementation. Are they just modifiers on existing stations, or are they their own thing? They could appear on the map at all times, but with special conditions to flip on and off the is_returning value. And then an extension to a) describe the type of station it is and b) to add details about the hours. This might look like a return_methods to complement the existing rental_methods values already in place. They're probably not part of service alerts, but I'm not 100% convinced of that yet.
2. Ambassadors are probably just a feature of a station, like rental_methods - in fact, this might be a good way to implement the key_dispenser option that was discussed in Add guidance about making suggestions #3 (comment) so we could add a number of different features a particular station might have and apps/maps could provide icons as appropriate.

Regarding implementation, we should continue the discussion in #3 about implementation and try to hash out some actual solutions, but I agree that some mechanism for just adding fields to the actual feed and starting to use them would make the most sense.

[fkh]

We have an unused google group - https://groups.google.com/forum/#!forum/gbfs

[fruminator]

@jcn why is a valet/corral a station with is_renting = 0? users can always take or return bikes from valets/corrals. We also want to make sure to provide special icons, descriptions, etc. for these stations.

I won't address key_dispensers here since there's a thread about that, but in terms of ambassadors being a feature of a station -- that couldn't be like rental_methods because rental_methods is on the station_information file which "rarely" changes.

I think where you are headed, broadly, is to define station "features" such as key dispensers, ambassadors, valets, etc. on the existing station_status.json files. Since the data is JSON (not CSV like GTFS) I can see this as a potentially viable solution. But it also potentially creates a lot of denormalization.

For example, consider a situation where we have ambassadors and we have the same name+description+url for this "feature" or "service" and it's running at a whole bunch of stations all day saturday. In the extensions-to-stations_status.json approach, you would be copying that descriptive data to every station. In the separate layer approach I proposed, it's more more concise, centralized, etc.

We should probably just talk about it. We should also have some wireframes or something to more fullsomely explain what we are trying to do here.

[mdarveau]

Yes, I do get the messages. I would drop the google group in favor of github.

[cubbi]

@mdarveau +1

[antrim]

The proposal for virtual stations (#175) responds to this.

There are proposed fields (is_virtual_station, virtual_vehicle_capacity, and valet) in station_information.json file to represent this (https://docs.google.com/document/d/1po4tlv5p7jXB6KQYohLAIS0qKJfxI1e-EH3JjiyUWoc/edit#heading=h.tc4u15ik0na3).

If there are other elements that a feed consumer or producer would like to implement, please add that on #175. To consolidate discussion, I'm closing this for now. Let me know if anyone has objections.