What is the proposal?

The introduction of manifest.json greatly facilitates the distribution of feed changes. It would be even more useful if a course geographic specification of the feed area would be specified for each feed. This would allow consumers to select relevant feeds according to the location of the user.

The geographic area could be specified by an array of lat/lon rectangles (areas in the example). In most cases, one rectangle per feed should suffice. Multiple rectangles could be useful for disjunct operating areas in a single feed.

Optionally, specifying an ISO 3166-1 alpha-2 country_code could help selecting relevant feeds per country.

Example:

"data":{
  "datasets":[
    {
      "system_id":"flamingo_wellington",
      "versions":[
        {
          "version":"2.3",
          "url":"https://data.rideflamingo.com/gbfs/wellington/gbfs.json",
        },
        {
          "version":"3.0-RC",
          "url":"https://data.rideflamingo.com/gbfs/3/wellington/gbfs.json",
        }
      ],
      "areas": [
        {
          "north": -41.20,
          "east": 174.86,
          "south": -41.36,
          "west": 174.71
        }
      ],
      "country_code": "nz"
    }
    …
  ]
}

Alternative solutions

In theory, this information could also be retrieved by fetching geofencing_zones.json (if existing). However, the rule mechanism makes it relatively hard to determine if a feed is "relevant" for a given coordinate and it requires to fetch 2 feeds (gbfs.json and geofencing_zones.json) per tested region. The idea really is to specify only as much information on the manifest level as needed to filter relevant feeds. This would help reduce unnecessary fetching of sub-feeds.

Is your potential solution a breaking change?

• Yes
• No, since manifest.json is new in 3.0.
• Unsure

Which files are affected by this change?

manifest.json