Skip to content

Commit b98420b

Browse files
authored
Merge pull request #636 from openmobilityfoundation/release-1.1.0
Release 1.1.0 - branch to dev
2 parents 486ca56 + 757fde7 commit b98420b

12 files changed

Lines changed: 165 additions & 165 deletions

File tree

README.md

Lines changed: 82 additions & 103 deletions
Large diffs are not rendered by default.

ReleaseNotes.md

Lines changed: 6 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,7 @@
11
## 1.1.0
22

3-
> Expected Released: 2021-02-28 (TBD)
3+
> Released: 2021-03-30
4+
45
> [Release Plan](https://github.com/openmobilityfoundation/governance/wiki/Release-1.1.0)
56
67
The 1.1.0 minor release adds new top level APIs (geography, jurisdictions), privacy options (provider reports, geography-driven events, metrics), and transparency features (public endpoints).
@@ -23,6 +24,8 @@ _Minor Updates_
2324
- [Geography publish date field consistency](https://github.com/openmobilityfoundation/mobility-data-specification/pull/597)
2425
- [Adding more cities using MDS](https://github.com/openmobilityfoundation/mobility-data-specification/pull/591)
2526
- [Adding more providers using MDS](https://github.com/openmobilityfoundation/mobility-data-specification/blob/dev/providers.csv)
27+
- [Added a section for third party software companies using MDS](https://github.com/openmobilityfoundation/mobility-data-specification/issues/552) and cleaned up home page, moving list content to the OMF website
28+
- [Update geography_json field type](https://github.com/openmobilityfoundation/mobility-data-specification/issues/635)
2629

2730
**_Provider_**
2831

@@ -54,6 +57,8 @@ _Minor Updates_
5457

5558
> Released: 2020-09-16
5659
60+
> [Release Plan](https://github.com/openmobilityfoundation/governance/wiki/Release-1.0.0)
61+
5762
The 1.0.0 release reconciles and aligns many parts of the MDS specification and adds features and updates requested by the community, including many new detailed vehicle states and event types, support for Stops (for docked vehicles, dockless corrals, parking areas), and adding rates (fees/subsidies) to Policy.
5863

5964
### CHANGES

agency/README.md

Lines changed: 4 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,7 @@
11
# Mobility Data Specification: **Agency**
22

3+
<a href="/agency/"><img src="https://i.imgur.com/HzMWtaI.png" width="120" align="right" alt="MDS Agency Icon" border="0"></a>
4+
35
The Agency API endpoints are intended to be implemented by regulatory agencies and consumed by mobility providers. Providers query the Agency API when events (such as a trip start or vehicle status change) occur in their systems.
46

57
This specification contains a collection of RESTful APIs used to specify the digital relationship between *mobility as a service* providers and the agencies that regulate them.
@@ -184,7 +186,7 @@ Body Params:
184186
| `event_types` | Enum[] | Required | see [Vehicle Events][vehicle-events] |
185187
| `timestamp` | [timestamp][ts] | Required | Date of last event update |
186188
| `telemetry` | [Telemetry](#telemetry-data) | Required | Single point of telemetry. |
187-
| `event_geographies` | UUID[] | Optional | **[Beta feature](/general-information.md#beta-features):** *Yes (as of 1.1.0)*. Array of Geography UUIDs consisting of every Geography that contains the location of the event. See [Geography Driven Events](#geography-driven-events). Required if `telemetry` is not present. |
189+
| `event_geographies` | UUID[] | Optional | **[Beta feature](/general-information.md#beta-features):** *Yes (as of 1.1.0)*. Array of Geography UUIDs consisting of every Geography that contains the location of the event. See [Geography Driven Events][geography-driven-events]. Required if `telemetry` is not present. |
188190
| `trip_id` | UUID | Optional | UUID provided by Operator to uniquely identify the trip. Required if `event_types` contains `trip_start`, `trip_end`, `trip_cancel`, `trip_enter_jurisdiction`, or `trip_leave_jurisdiction` |
189191

190192
201 Success Response:
@@ -330,7 +332,7 @@ If `stop_id` is specified, `GET` will return an array with a single stop record,
330332
[general]: /general-information.md
331333
[geography-driven-events]: /general-information.md#geography-driven-events
332334
[error-messages]: /general-information.md#error-messages
333-
[hdop]: https://support.esri.com/en/other-resources/gis-dictionary/term/358112bd-b61c-4081-9679-4fca9e3eb926
335+
[hdop]: https://en.wikipedia.org/wiki/Dilution_of_precision_(navigation)
334336
[propulsion-types]: /general-information.md#propulsion-types
335337
[responses]: /general-information.md#responses
336338
[stops]: /general-information.md#stops

general-information.md

Lines changed: 2 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
# Mobility Data Specification: **General information**
22

3-
This document contains specifications that are shared between the various MDS APIs such as [`agency`][agency], [`policy`][policy], and [`provider`][provider].
3+
This document contains specifications that are shared between the various MDS APIs such as [`agency`][agency], [`policy`][policy], [`provider`][provider], etc.
44

55
## Table of Contents
66

@@ -143,20 +143,17 @@ Here's how it works in practice:
143143

144144
*Agency adds rule disallowing parking on waterfront path, begins receiving data on events within area.*
145145

146-
147-
148146
Agencies that wish to use Geography-Driven Events do so by requiring a new `event_geographies` field in status events. When an Agency is using Geography-Driven Events, Providers must emit a new `changed_geographies` status event whenever a vehicle in a trip enters or leaves a Geography managed by a Policy.
149147

150148
During the Beta period for this feature, location and telemtry data remain required fields. This allows Aggencies to test Geography-Driven Events, measuring its accuracy and efficacy against regulatory systems based on precise location data. After the beta period, if Geography-Driven Events is deemed by OMF to be accurate and effective, the specification will evolve to allow cities to use Geography-Driven Events in lieu of location or telemtry data.
151149

152-
153150
[Top][toc]
154151

155152
## Optional Authentication
156153

157154
Authorization of the Policy and Geography APIs is no longer required and will be deprecated in next major release with these endpoints becoming optionally private instead of optionally public. An agency may optionally decide to make both the Policy and Geography endpoints unauthenticated and public. This allows transparency for the public to see how the city is regulating, holds the city accountable for their policy decisions, and reduces the technical burden on providers to use these endpoints. A side benefit is that this allows third parties to ingest this information into their applications and services for public benefit.
158155

159-
Note if implementing the beta features [Geography Driven Events](/general-information.md#geography-driven-events), both Policy and Geography must be public.
156+
Note if implementing the beta feature [Geography Driven Events](/general-information.md#geography-driven-events), both Policy and Geography must be public.
160157

161158
[Top][toc]
162159

geography/README.md

Lines changed: 4 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,7 @@
11
# Mobility Data Specification: Geography
22

3+
<a href="/geography/"><img src="https://i.imgur.com/JJdKX8b.png" width="120" align="right" alt="MDS Geography Icon" border="0"></a>
4+
35
This specification contains a collection of RESTful APIs used to read Geographies (descriptions of geographical information, e.g. multi-polygons, currently represented via GeoJSON).
46

57
Geographical data has many applications in the context of mobility, such as the description of municipal boundaries, locations for pick-up and drop-off zones, and areas of temporary closure for special events or emergencies. This API is intended to support a variety of other APIs, including the Policy API.
@@ -87,7 +89,7 @@ Authorization is not required. An agency may decide to make this endpoint unauth
8789

8890
## Schema
8991

90-
Placeholder -- link to schema to be added later.
92+
Link to schema will be defined and added in a future release.
9193

9294
[Top][toc]
9395

@@ -99,7 +101,7 @@ Placeholder -- link to schema to be added later.
99101
| `description` | String | Optional | Detailed description of geography |
100102
| `geography_type` | String | Optional | Type of geography, e.g. `municipal_boundary` or `council_district` or custom text. See [Geography Types](#geography-types). |
101103
| `geography_id` | UUID | Required | Unique ID of geography |
102-
| `geography_json` | UUID | Required | The GeoJSON that defines the geographical coordinates. |
104+
| `geography_json` | JSON | Required | The GeoJSON that defines the geographical coordinates. |
103105
| `effective_date` | [timestamp][ts] | Optional | The date at which a Geography is considered "live". Must be at or after `published_date`. |
104106
| `published_date` | [timestamp][ts] | Required | Time that the geography was published, i.e. made immutable |
105107
| `retire_date` | [timestamp][ts] | Optional | Time that the geography is slated to retire. Once the retire date is passed, new policies can no longer reference it and old policies referencing it should be updated. Retired geographies should continue to be returned in the geographies list. Must be after `effective_date`. |

geography/examples/README.md

Lines changed: 3 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
# Geography Examples
22

3-
This file presents a series of example [Geography](/geography) files to use as reference and to see previews.
3+
This file presents a series of example [Geography](/geography) files to use as reference and to see previews online.
44

55
## Table of Contents
66

@@ -19,7 +19,8 @@ All of the examples below will be presented within the single [/geographies](/ge
1919
**File with full geometry**: [`geographies.json`](geographies.json)
2020

2121
**GeoJSON sample to view all geometries together in a preview**: [`geographies.geojson`](geographies.geojson)
22-
Note this file is just for your reference to generate a preview on Github. It is not part of the spec.
22+
23+
_Note GeoJSON example files are just for your reference and to generate a preview on Github. The GeoJSON files alone are not part of MDS._
2324

2425
## Municipal Boundary
2526

jurisdiction/README.md

Lines changed: 7 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,11 @@
11
# Mobility Data Specification: Jurisdiction
22

3+
<a href="/jurisdiction/"><img src="https://i.imgur.com/tCRCfxT.png" width="120" align="right" alt="MDS Jurisdiction Icon" border="0"></a>
4+
35
This specification details the purpose, use cases, and schema for Jurisdictions, a beta feature. Jurisdictions are an optional service that, if implemented, must be authenticated, and served by a coordinated group of agencies.
46

7+
The Jursidiction API is to be served by agencies, and it can optionally be made public. It serves a different purpose from the [Geography](/geography) API, though it does reference areas within Geography by ID.
8+
59
## Table of Contents
610

711
- [Background](#background)
@@ -64,7 +68,7 @@ Those tools can be granted data access from the SaaS tool based on the jurisdict
6468

6569
## Distribution
6670

67-
Jurisdictions can be served by agencies through the following REST API, or via [flat-files](#flat-files).
71+
Jurisdictions can be served by agencies through the following REST API, or via [flat-files](#flat-files). Agencies may choose to make the endpoints public and non-authenticated.
6872

6973
### REST
7074

@@ -114,7 +118,7 @@ Formatted in JSON, a Jurisdiction object should look like this:
114118

115119
### GET /Jurisdictions
116120

117-
Gets all of an agency's Jurisdictions.
121+
Gets all of an agency's Jurisdictions. Served by agencies.
118122

119123
Parameters:
120124
| Name | Type | R/O | Description |
@@ -129,7 +133,7 @@ Response codes:
129133

130134
### GET /Jurisdictions/:jurisdiction_id
131135

132-
Gets a single Jurisdictions.
136+
Gets a single Jurisdictions. Served by agencies
133137

134138
Parameters:
135139
| Name | Type | R/O | Description |

metrics/README.md

Lines changed: 5 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,7 @@
11
# Mobility Data Specification: Metrics
22

3+
<a href="/metrics/"><img src="https://i.imgur.com/ouijHLj.png" width="120" align="right" alt="MDS Metrics Icon" border="0"></a>
4+
35
The Metrics API endpoints are intended to be implemented by regulatory agencies, their third party appointed representatives, or city designated partners for requesting **historical** calculated [core metrics](core_metrics.md) and aggregations of MDS data. The Metrics API allows viewing of aggregate report data derived from some MDS endpoints that may be used for use cases like compliance, program effectiveness, and alignment on counts. The metrics [methodology](/metrics/metrics_methodology.md) definitions may be used by providers and third parties in their own calculations.
46

57
[Metrics Examples](examples) are available with sample implementations.
@@ -96,15 +98,15 @@ Further scopes and requirements may be added at the discretion of the Agency, de
9698

9799
## Data Redaction
98100

99-
Some combinations of dimensions, filters, time, and geography may return a small count of trips, which could increase a privacy risk of re-identification. To correct for that, Metrics does not return data below a certain count of results. This is called k-anonymity, and the threshold is set at a k-value of 10.
101+
Some combinations of dimensions, filters, time, and geography may return a small count of trips, which could increase a privacy risk of re-identification. To correct for that, Metrics does not return data below a certain count of results. This data redaction is called k-anonymity, and the threshold is set at a k-value of 10. For more explanation of this methodology, see our [Data Redaction Guidance document](https://github.com/openmobilityfoundation/mobility-data-specification/wiki/MDS-Data-Redaction).
100102

101-
**If the query returns less than `10` trips in a count, then that row's count value is returned as "-1".** Note "0" values are also returned as "-1" since the goal is to group low and no count values together for privacy.
103+
**If the query returns fewer than `10` trips in a count, then that row's count value is returned as "-1".** Note "0" values are also returned as "-1" since the goal is to group both low and no count values together for privacy.
102104

103105
The OMF suggests a k-value of 10 is an appropriate starting point for safe anonymization, absent analysis and a further decision from the agency. As Metrics is in [beta](#beta-feature), this value may be adjusted in future releases and/or may become dynamic to account for specific categories of use cases and users. To improve the specification and to inform future guidance, beta users are encouraged to share their feedback and questions about k-values on this [discussion thread](https://github.com/openmobilityfoundation/mobility-data-specification/discussions/622).
104106

105107
The k-value being used is always returned in the Metrics Query API [response](/metrics#response-1) to provide important context for the data consumer on the data redaction that is occurring.
106108

107-
Using k-anonymity with this k-value and methodology will reduce, but not necessarily eliminate the risk that an individual could be reidentified in a dataset. Higher k-values have lower re-identification risk, but may result in less complete metrics depending on the duration of time periods and size of geographic areas for which the metrics are calculated. Some use cases (such as sharing metrics with trusted parties who already have access to disaggregated trip data) may not require k-anonymization, while others (such as sharing with less trusted partners or extracts for the public) may require substantial k-anonymization. While metrics with any k-value are likely to be substantially less sensitive than disaggregated trip records, they should still be treated as potentially sensitive unless a more detailed risk analysis is performed by the hosting organization.
109+
Using k-anonymity will reduce, but not necessarily eliminate the risk that an individual could be re-identified in a dataset, and this data should still be treated as sensitive. This is just one part of good privacy protection practices, which you can read more about in our [MDS Privacy Guide for Cities](https://github.com/openmobilityfoundation/governance/blob/main/documents/OMF-MDS-Privacy-Guide-for-Cities.pdf).
108110

109111
[Top][toc]
110112

0 commit comments

Comments
 (0)