Method for calculating de-identified trip data (open data)
まだ誰も着手していません。
評価
調査の方向性
リンクされた Trip Deidentification Binning Specification と Anonymization Methods Comparison から始め、次に #485 の Metrics API 提案と既存の agency/provider /trips エンドポイントを確認してください。非識別化されたトリップ API、その検索パラメーター、正確な非識別化ルール、および命名を定義してください。完了の条件は、agency と provider の仕様書に、合意済みのエンドポイントとデータの挙動が記載されていることです。
索引モデルが issue の本文から書いたものです。
説明
Is your feature request related to a problem?
Trip data is useful for many reasons, including for planning and research purposes, such as those expressed in #136.
Trip data however carries a risk, as described in the Chicago TNP and Taxi Open Data Approach: “It has been recognized in scientific literature and news reports that even data without directly identifying attributes can be reidentified using other data sources. Specifically, data about an individual’s location at certain points in time can create a ‘fingerprint’ that can allow for re identification, as long as there is a separate dataset available containing parts of the fingerprint along with identifying fields.”
By design, MDS data does not include rider characteristics, e.g. rider’s name, date of birth, zip code, phone number, gender identification, or any other attribute related to the individual. The exception is the location and time of the trip related events, and in-trip route trace telemetry.
To further protect against re-identification of MDS data, LADOT is implementing a similar approach to the one outlined and used by Chicago for TNP and Taxi, and micromobility trip data. Here we propose a Trip Binning approach to further de-identified trip data and a new API to support serving it.
Describe the solution you'd like
Following the example of the submitted Metrics API #485, we propose a new de-identified trips API that could be implemented by either mobility Providers or regulating Agencies (based on data obtained from the Provider or Agency /trips endpoint). The single endpoint would be something like /trips/deidentified with a variety of search parameters.
The API would contain precise definitions for further de-identified trips. It could provide either private exchange between Providers and Agencies, or between either of those and more public feeds for e.g. academic researchers.
Is this a breaking change
- No, not breaking
Impacted Spec
agencyprovider
Describe alternatives you've considered
We considered having one /trips endpoint that has different permissions and scope whether to serve the granular or further de-identified trip information. We went with separating /trips from /trips/deidentified to create clear delineation between granular and further de-identified trip information.
In regards to methodologies to de-identify trip information, cities have taken different approaches whether through rounding the start and end location to broader geography, binning the time to a larger time interval, and/or applying k-anonymization. We went with a de-identification technique that puts forward the best aspects of these different approaches.
We tested approaches that go beyond spatial and temporal rounding, such as using k-anonymization methodologies, namely, Trip Binning, which originated from the City of Chicago, and Point Fuzzing by Louisville. The result of the comparison study here.
Additional context
I'd welcome suggestions for better naming for /trips/deidentified.
Special thanks to @schnuerle for developing the Point Fuzzing technique, and providing input to the comparison study, @nicklucius for developing the Trip Binning approach for Chicago, and @whereissean, @playground-julia, Sam Jackson who kickstarted and have been relentless in developing a standard for trip deidentification.
We hope to push the privacy conversation a step further and stimulate discussion with more members of the OMF community.
- 主要言語
- 言語のデータがありません
- スター
- 753
- フォーク
- 255
- PR マージ指標
- 30日以内にマージされた PR はありません
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
openmobilityfoundation/mobility-data-specification のほかの issue
-
documentation
難易度 1/5 1〜3時間 初心者へのやさしさ 85/100
openmobilityfoundation/mobility-data-specification#994 · リアクション 4 件 ·
-
Policy
難易度 5/5 1週間以上 初心者へのやさしさ 18/100
openmobilityfoundation/mobility-data-specification#996 · リアクション 1 件 ·
-
Move Provider/Agency List out of MDS repo再び着手できるかも @schnuerle が 37 日前に担当しましたが、オープン中のプルリクエストはありません。 オープンidentifier change
openmobilityfoundation/mobility-data-specification#995 · 担当者 1 名 ·
-
Agency Provider
難易度 3/5 1〜2日 初心者へのやさしさ 65/100
openmobilityfoundation/mobility-data-specification#993 · コメント 1 件 ·
-
Agency Delivery Policy Provider
難易度 5/5 1週間以上 初心者へのやさしさ 25/100
openmobilityfoundation/mobility-data-specification の issue をすべて見る
似ている issue
-
changelog investigate
難易度 1/5 1時間未満 初心者へのやさしさ 85/100
ramnes/notion-sdk-py#454 ·
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
anthropics/claude-agent-sdk-python#1509 ·
メンテナーはふだん 2 日以内に返信
-
from-review-extraction priority: medium python severity:suggested
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
LearningCircuit/local-deep-research#8665 ·
メンテナーはふだん 1 日以内に返信
-
難易度 1/5 1時間未満 初心者へのやさしさ 82/100
メンテナーはふだん 1 日以内に返信
-
external feature request openai
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
langchain-ai/langchain#41853 ·
メンテナーはふだん 1 日以内に返信