mobilitydata / gbfs Goto Github PK

Will gbfs be expanded to cover shared scooters?

Currently, the spec doesn't specify a type for time stamps. This has caused some systems to represent them as ints, while others represent them as strings. More amusingly, some systems use both.

Example: BCycle-Charlotte currently uses a string representation in their gbfs.json, but integers in system_status.json. (This actually seems to be the case for all BCycle feeds, so that may be an error on their part.)

@jcn pointed out that the POSIX time spec does not specify a type or encoding, but we agree that an integer makes the most sense in this situation.

I am most familiar with the Citibike NYC's (Motivate) BikeAngels program which associates points with picking up or dropping off bikes at stations. https://bikeangels.citibikenyc.com/ They offer membership extensions and other perks for members who accumulate points. I do not know of other systems which offer incentives for dropping off or picking up, but perhaps you all may know. Currently my application hits the Citibike GBFS feed and makes a subsequent request to their bike angels api. However in recent days it appears they may have merged their status and bike angels info into the same api endpoint: https://layer.bicyclesharing.net/map/v1/nyc/stations See fields like "bike_angels_action": "give", "bike_angels_points": 1

Proposal: Add optional fields to the inner objects within station_status.json and free_bike_status.json:

It makes sense that incentive_status could be set on its own without an incentive_value in cases where there is not a value based system. These fields should only be used if there is an actual incentive system in place. I would not like the incentive_status field just being set using a simple algorithm with rules like bikes/docks > 0.95 and so on.

It may also be possible to add those fields to the zones from #65 as well.

• station_status: num_bikes_diabled & num_docks_diabled
• system_regions : sname

I'd like to get a discussion going around adding polygon coordinates to describe parking areas and service area boundaries for free floating bikes. Cities are beginning to wrestle with how to regulate stationless bikes and it seems like there's an opportunity to address this via GBFS. Since I run a station based system I'm not up to speed on how these data are currently described. This issue also comes up with the proposed "super hubs" in Portland. Is there anyone from SoBi or with GIS expertise that would be interested in working on this?

@mdarveau and @dsgermain raise up a good point in #9 about versioning. While we've said that we would version the spec in the repository via git tags, we did not actually ever decide where to indicate the GBFS version in the feed.

I can imagine two logical places for this:

1. In gbfs.json, in which case we would want to make this file required (though the version field would be the only file that was required - the auto-discovery mechanism would change to optional)
2. In system_information.json, but this doesn't really make sense since it's metadata about the feed, not about the system

I am leaning toward including it in gbfs.json but would like other people's thoughts.

Can we update the discovery spec to allow a link to the legal license, something like:

Updating discovery:
https://gbfs.citibikenyc.com/gbfs/gbfs.json

To include:
{
name: "license",
url: "https://gbfs.citibikenyc.com/license.txt"
}

Motivation:

I work for Google and we require a legal review to import any third party data. This would be one review per provided, and there are currently 47. If there were a straightforward link to the license it would be easier for us to review than having to search for it on the website.

Thanks!

As stated in the specification I added a link tag with the location of the auto-discovery file to our website.
<link rel="gbfs" type="application/json" href="https://www.example.com/data/gbfs.json" />

However the website failed to validate at the W3 Validator:

Error: Bad value gbfs for attribute rel on element link: The string gbfs is not a registered keyword.

Even though the link to the site with "registered" keywords is listed as "Reference" in the specification, no one seems to have added gbfs to the table on their site. The procedure and how conformance checkers should behave is explained better at WHATWG

I've added the gbfs keyword to the wiki as "proposed" so that it might will be considered by validators as valid in the future.

I'll report back and close the issue after the W3 validator won't throw an error anymore. I thought it'd be a good idea create an issue here for reference.

Following #113, i check all urls on systems.csv

On docs, it's

This should be in the base unit as defined by the ISO 4217 currency code with the appropriate number of decimal places and omitting the currency symbol. e.g.

Can we clarify the JSON type ? Number and/or String
Most looks number but some are given in String https://rey.publicbikesystem.net/ube/gbfs/v1/en/system_pricing_plans (and with ',')

Are we trying to invent a new format for hours of operation (system_hours.json)?

What about a format that is already used and supported with code libraries—see OSM’s opening_hours (http://wiki.openstreetmap.org/wiki/Key:opening_hours)

It seems like systems.csv would be a nice source for discovery of GBFS-compatible systems.

Questions:

• How stable is the structure of this file? Safe to query programmatically via https://raw.githubusercontent.com/NABSA/gbfs/master/systems.csv without fear of field names and/or column order changing?
• Is System ID guaranteed to be unique?
• Is anyone else currently known to be querying this programmatically?

If someone has a suggestion to improve GBFS, what is the process for adding a suggestion? Beyond adding an issue to the repo, what should be included in the description?

Perhaps separately, or not, what is the process for improving and modifying the spec?

One of the current uses of the legacy json feeds is to show the stations of CitiBike NYC in DuckDuckGo:

The legacy feed works great for this, because by making only one call, we can get the stations' names, locations and number of total/available bikes.

We would love to switch to the new GBFS feeds, but that would imply either making two calls (one to get station_information.json and another for station_status.json), or periodically getting the station information, and then updating only the statuses on demand.

Ideally, there could be an aggregated feed that includes all the fields from both of them.

Some SoBi systems?

I would like to develop a standard for communicating parking regimes (forbidden areas, virtual hubs) to bicycle operators.

The reason that I think a new standard is needed is that normally GBFS is created by bike sharing operators, while parking regimes are created by local governements. It would be more efficient if a local government shares there parking regime then having multiple operators drawing the same regime on a map themselves. Anyone interested to help me with developing this standard?

where can i get data for damaged bike ids or bike id which required repairs

I'm not a huge fan of the JSON schema, but there are quite a few libraries (some examples) that use or support schema validation.

I'm currently trying to validate geoJSON, and I am shocked that there is no official schema. I think it would be helpful to developers to provide the schema ourselves.

I was thinking, wouldn't it be great to be able to query the api based on date,
for example

https://tor.publicbikesystem.net/ube/gbfs/v1/en/station_status?startDate=1500801931187&endDate=1510801931187

I cannot find where the station_id field requirements are clearly defined.
It says "See Output Format above for ID field requirements" here

What's the (my) issue?
I'm not clear as to what the line is referring to regarding the 'Output Format'
While many systems use integers we have some such as:
bcycle_spartanburg_1924
bcycle_linkdayton_3025
So clearly the unofficial requirement is a string. Of what length then? 32 characters?

I'm not sure if there's some overall guidelines that's being followed - such as freedom and flexibility vs compactness and clarity...

Getting to the point, I wonder if station ids shouldn't be defined as integers? I'm fine with a string too. Either way a maximum length should be defined. 32? 64?

Further I wonder if all fields should have a clearly defined type and maximum character/digit length?

This will help those storing these values in databases with predefined fields sizes.

A proposal from Tom Brown in the original draft:

"boolean" suggests true/false to me, but it looks like you want int number 0 or 1. if you think this may become 3 or more state an enum string may be clearer. if it you expect it to remain binary json true/false looks like a good fit.

The integers 0 and 1 evaluate as falsy and truthy in Javascript but not in other languages so converting these to true booleans would make these values more explicit. They would represent an additional several characters in the underlying file, which may or may not be a concern from a bandwidth perspective, but it's the only reason I could think to not make this change.

station_information.json schema could be enhanced by providing additional address fields (could be still optional)

• location description
• lat/long calculation method (from geocoding an address using ; manual placement using as a reference; using a GPS receiver … etc.)
• station photo URL(s).

Hello,
i made a validation tool on https://github.com/PierrickP/gbfs-validator (the cli should working) and https://gbfs-validator.netlify.com/
Currently validate the current specs (1.0 ?) but i working on validate gbfs+ and futur other version.

It's a work in progress project. It could have some errors. Contribution are welcome :)

There's a lot of 'pre-trip' data (station availability, etc) but nothing about the public trip data. These are provided in a variety of formats, but it'd be nice to have them included in the GBFS and systems.csv so they are discoverable. Perhaps it's more complicated than the normal name/url in a gbfs.json (for instance, daily/weekly files, zip/csv/json, anonymized), but starting to normalize/enumerate these would be helpful.

Some examples:

• citibike, monthly, zip
• divvy, every 6mo, zip
• capitalbike, every 3mo, zip
• pronto , 1year, oneoff zip?

How about letting the opperator of the GBFS put optional information about bike types at each station.
I'd see it as an object detailing num_bikes_available like:

"num_bikes_available_types" : {
    "3 gears":7,
    "7 gears":3,
    "electric bike":2,
    "special event bikes":2
}

Following #113, i check all urls on systems.csv
Many failed because they use Int/Number instead of String for station_id / bike_id

On specs, it's written

ID fields in the document should be represented as strings

I understand, it should BE a string.
Should i consider them as errors ?

The Curtin University Bike Share and associated feeds no longer resolve. I'm not affiliated with them so I can't speak authoritatively about what is going on.

As per a comment from Tom Brown in the original spec, we propose that timestamps be changed from POSIX time to RFC 3339 for potential human-readability and clarity (to avoid millisecond confusion).

Furthermore, I would propose that the time zone always be set to "Z" (i.e. UTC) to further prevent confusion.

i.e. 2016-01-13T21:19:33Z instead of 1452719973

https://web.spin.pm/api/gbfs/v1/gbfs

{"last_updated":1543516918,"ttl":0,"data":{"en":{"feeds":[{"name":"system_information","url":"https://web.spin.pm/api/gbfs/v1/system_information"},{"name":"system_regions","url":"https://web.spin.pm/api/gbfs/v1/system_regions"},{"name":"free_bike_status","url":"https://web.spin.pm/api/gbfs/v1/detroit/free_bike_status"},{"name":"free_bike_status","url":"https://web.spin.pm/api/gbfs/v1/washington_dc/free_bike_status"}]}}}

@jcn does this match the spec? How should this be represented in systems.csv?

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.

We (Austin) have a number of stations that have been uninstalled (or were installed temporarily) and are not listed in our station_status feed. I assume that is_installed should be a means for keeping track of such stations, but I've checked a handful of other feeds (Denver, Madison, Houston), and I don't see any stations listed with a status of is_installed = 0.

Would the is_installed field be an appropriate means for tracking uninstalled stations? Any idea why cities aren't using it? This leads to a situation (in Austin, at least) where we have trip data with station IDs that are not in our station_status feed. I realize this issue may be outside the scope of GBFS, but I'm curious to hear from interested parties.

First well done with creating this standard!

I want to use this standard to make positions of freefloating bicycles available available as open data. In the standard https://github.com/NABSA/gbfs/blob/master/gbfs.md#files is specified that station_information and station_status are required. In a freefloating bicycle system there are no stations and therefor these files are not relevant.

Another suggestion that I have is adding a type of system (free floating/ station_based maybe some other options renting a bike at a station and having to bring it back to the same station) to system information https://github.com/NABSA/gbfs/blob/master/gbfs.md#system_informationjson

I am interested in your opinion. Based on that I could propose formal changes.

This is tangentially related to #47.

We at Populus have been working to convert GBFS feeds to trip logs. One of the biggest issues is that when a bike disappears from the feed, we can't tell whether the bike is in use (on a trip) or if it's undergoing maintenance, being charged, etc. Also it's hard to differentiate short trips from connectivity issues / GPS noise (i.e. did a bike move 200 meters in 3 minutes, or was that just a gust of wind).

I wonder if it would help to leave a bike which is in use in the GBFS feed with an in_use flag. This would help address the above, and we also could know how many bikes are out there at any given time, which you can't know now. In theory, operators could continue to include some location information for the trip even when the vehicle is in use, and we could very roughly track the trip route for infrastructure planning purposes.

Some context here is that we are working with the cities to help them know how their bike and scooter share systems are working holistically. I understand from the responses to #47 that this is not the purpose of GBFS exactly, but it seems to me that GBFS could evolve to support this and keep from forcing my group and others from having to overhaul the standard entirely like MDS. Any thoughts on this use case, which I think will be increasingly common in the future. Is it better to just have the operators use MDS and report their own trips? I know that some cities would rather use GBFS because they don't trust the operators to report their trips perfectly.

In the root file the vendors bike network should be an added column. There are a more than a few bike rental company's that do not list, or have as a part of their URL or domain name, the name of their service network.

Example: Coast Bike Share. There is no information anywhere that suggests or shows they are a part of Social Bicycles. SoBi has their own API with more extensive data than is found here on the GBFS. I also forsee other bike networks, as they grow, coming up with their own API too. The GBFS for SoBi and the other API's would therefore be a secondary data pull.

With the "network" identified here we can differentiate between those with more populated APIs versus those that only have the GBFS data.

At this moment different rental hours per station can only be modeled if every station is modeled as a different system. Wouldn't it be more elegant to have the ability to set the rental hours per station opposed to per system?

The spec file should be called gbfs.md and should conform to this style guide: https://github.com/NABSA/gbfs/wiki/Style-Guide

The source document is here: https://docs.google.com/document/d/1BQPZCKpem4-n6lUQDD4Mi8E5hNZ0-lhY62IVtWuyhec/edit#

Note: there are some outstanding comments in the Google Docs which should be discussed with @jcn during migration if they're not resolved yet.

Hello everyone.

There are a some systems that doesn't work the whole day, in these cases, What should be the behaviour of the num_bikes_available during the non service hours?

There are two values that indicate if a station is renting or receiving bikes, additionally, The number of bikes and docks should change to "0" on each case?, I can see that not all the systems are managing these values the same way so I would like to find a standarization.

In our experience, mantain the value of bikes and docks available at the station as an independent value from the renting and returning flags can be much more valuable for analisys and developing purposes, also, as an end user is very functional to know where the bikes are, it allows the user to plan where to go and take a bike at the very first hours of service, ultimately, there are a lot of options like color, size, shape, symbols, legends, etc. to represent the functional status and the occupation of a station at the same time.

thanks in advance!

The current localization rules allows but does not require feeds to have the ISO-639 2 letter language code in the URL. The wording implies that if the bike share intends to only serve the files in one language.

Examples:

• SoBi and B-Cycle feeds that only provide english data place all feeds at the autodiscovery root. See http://boise.greenbike.com/opendata/gbfs.json, http://boise.greenbike.com/opendata/system_information.json, https://gbfs.bcycle.com/bcycle_charlotte/gbfs.json
• Motivate and PBSC feeds use the /en/ or /fr/ routes, regardless of if there is one or multiple languages.

Issues
While this is not an issue if a developer pulls URLs from the auto discovery URL, it is often faster to link directly to the necessary feeds for the sake of speed. By having this ambiguity, it is more difficult for a developer to build URL strings without first parsing the auto discovery gbfs.json feed, as it is not clear whether to append /lang/feed.json or just /feed.json to the GBFS root.

Possible Solutions

1. [Breaking] Mandate that feeds be nested under a ISO-639 /lang/ route.
2. [Breaking, but less overhead] Require developers to serve their default language when no language parameters are specified, and any additional languages must be nested in a /lang/ route¹.
3. Do nothing at all, and recommend developers always refer to the auto discovery feed.

While this is not a large issue, it has caused URL routes of GBFS feeds to be inconsistent. I would argue that solution 1 would be the most correct, with 3 being the most feasible.

Thoughts? I’d love to hear from developers and how you poll GBFS feeds—do you store the direct URLs? Parse the auto discovery?

¹ This could be problematic as someone parsing without using lang parameters would return different languages between systems.

The GBFS currently offers read-only access to the existing system status data. Have you considered adding generic API for "write" access, e.g. to allow opening bikeshare system for rentals coming from "outside"?

I would envision this as set of general rules that system could set to either allow or don't allow rental queries coming from third-parties (apps, websites such as spinlister etc.).

Is there something in spec about how often information is updated? Or is that site specific?

• station_status is missing its 'is_renting' field.
• station_information is missing its 'post_code' field

Maybe this has been thought of already, but doesn't it seem strange to issue two API calls to get:

• the name of the station
• how many bikes it can hold
• how many are available

It would be nice if there was a single object that represents a station, with a single endpoint to get the information for the stations in the system.

Hi all...this is now my 2nd request for feature enhancement.

I am developing a rideshare aggregator app. Thus I am taking a national and multi-national approach to designing my app services. Lyft/Uber/Taxi rideshares, Bikeshares, and public transit are integrated into my app.

I have already integrated the SoBi API. But now I am expanding to add the non-SoBi bikeshares listed in the GBFS csv file - I am actually excited I came across this GBFS...it literally doubles that amount of locations I can show available bikeshares to my users. Within the SoBi API I can do a quick "network" check with a single call to see if a bikeshare is in the city my user is inquiring from. But not so with the GBFS data.

There needs to be a central GPS coordinates in the system-information.json file - or a full address with zipcode - that can allow me to do a single call for the top level json file to determine if that network is even near/available to my user...then if it is, go deeper into the lower level json files to get bike/station information. As is, "Phoenix" as the location field in the root system.csv simply isn't good enough for me to do a top level check.

Last week I threw together this: https://github.com/trevorgerhardt/gbfs-map to explore the participating GBFS networks. Initially, I wanted to just pull in the data on page load in the front end, first querying the systems.csv file in this repo and then pulling in the gbfs.json file for a system when it was needed. A problem that quickly arose is that certain CORS settings disallow direct requests from a browser. To see an example I queried the Cabi gbfs.json from the Chrome console and it worked, but the Monash system failed.

If each system added to their OPTIONS header: Access-Control-Allow-Origin: *, we wouldn't need to proxy through an additional system.

Learn more about CORS here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS

Hi-

I wanted to get some clarification on the NABSA standard for the GBFS free bikes feed. In the City of Los Angeles, we are requiring that dockless mobility companies provide information on the status of available devices, adhering as best as possible to the NABSA guidelines. However, we've seen some providers implementing pagination of results.

I'm not sure what the historical scale of docked bikeshare has been, so this question is thinking a bit about how GBFS has operated in the past, but also how it should be thought about for the future in adapting it for dockless companies.

1. Does the omission of pagination on the output format section on the structure of the free_bikes feed mean that paginating results are not allowed?
2. It is reasonable to forbid paginating results, given the proliferation of dockless devices, and thus the high result count of any GET request?

We've been having this discussion within our own MDS here.

Thank you!

Currently, the "feeds" array contains an array of feed objects with the properties name and url. This structure seems redundant, as this feed object has no additional values. In addition, there is no explicit ordering of the feeds in gbfs.json.

Having the feeds list be changed to a key-value pair of the format "<feed_name>": "<feed_url>" would make the auto-discovery feed easier to parse and more terse. Using the example from the spec, an updated gbfs.json would look like this:

{
  "last_updated": 1434054678,
  "ttl": 0,
  "data": {
    "en": {
      "feeds": {
        "system_information": "https://www.example.com/gbfs/en/system_information",
        "station_information": "https://www.example.com/gbfs/en/station_information"
      },
    "fr" : {
      "feeds": {
        "system_information": "https://www.example.com/gbfs/fr/system_information",
        "station_information": "https://www.example.com/gbfs/fr/station_information"
      },
    }
  }
}

Both of the big bike sharing operators in Germany, nextbike and DB Call a Bike, normally allow a user to return a rented bike next to the station if there are no free docks available.

If no spaces are available, simply lock it close to the stand.
https://www.callabike-interaktiv.de/en/cities/hamburg

Thus there should be a way to make sure that a station never appears to be "full" (accepting no returns) to GBFS consumers.

Is there a combination of station_information capacity and station_status num_docks_available to achieve this?

Hey everybody,
We have an open PR, #92 from @dsgermain that I would like to move forward on but there hasn't been any discussion since it was submitted. This is a significant update and I'd like others in the group to weigh in before it gets merged. If no outstanding issues are identified after one week’s time, and there is general agreement that the change is worthwhile and follows the GBFS guiding principles outlined in the READ.ME I will go ahead with the merge on 3/23/2018.

Thanks

Per a colleague from Portland Trimet, who (a) was involved in first development and use of GTFS, and (b) is involved with OpenTripPlanner which is likely to be a consumer of GBFS:

Needs a license for public use. GTFS uses Creative Commons license. See bottom of page:
https://developers.google.com/transit/gtfs/reference

Specifically: "Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 3.0 License, and code samples are licensed under the Apache 2.0 License. For details, see our Site Policies."

@mplsmitch any reason you wouldn't want to just add this?