-
Notifications
You must be signed in to change notification settings - Fork 101
Roadmap
Carl Fredlund edited this page Mar 23, 2021
·
33 revisions
π MobilityData created this space for you to share your big picture plans and to see ours.
This is meant to be a list of major features. More granular items (e.g. specific validation rules) are covered in contributing.md.
Please βοΈ edit this page to add your vision, interest, and work.
List of main point of contacts for the product roadmap:
Organization | Project owner |
---|---|
MobilityData | @carlfredl (product) |
Cal-ITP | @e-lo |
π MobilityData believes these items need tighter ownership to ensure stability. Please get in touch with @carlfredl to coordinate contribution.
- Need: There is vague language in the GTFS specification leading to unclear validity in some cases.
- Feature: Clean up the spec, review existing validation rules accuracy according to updated spec.
π . | π₯ | π οΈ |
---|---|---|
2021 Q1 | Google, MobilityData | Ambiguity in language of GTFS flagged. |
2021 Q2 | MobilityData | Working on clarifications in GTFS spec. |
- Need: Changes to Validator should not result in previously valid datasets becoming invalid.
- Feature: Run tests on a large number of expectedly valid datasets. MobilityData plan = leverage the Mobility Archives.
π . | π₯ | π οΈ |
---|---|---|
2021 Q1 | Suggested feature. | |
2021 Q2 | MobilityData | Implementation work. |
- Need: Consumers & regulatory bodies have requirements beyond the GTFS spec itself. Producers want test validity against these, too.
- Feature: Allow rules that are not in the spec itself yet but are required by various consumers or regulatory bodies. Validator users should be able to toggle to use their choice of additional rules beyond the core in-GTFS-spec rules.
π . | π₯ | π οΈ |
---|---|---|
2020 Q4 | Cal-ITP | Suggested feature. |
2021 Q2 | MobilityData | Design & implementation. |
π€ Features expected to allow larger autonomy by the open source community. It's recommended to check-in with others here if you're planning major work.
- Need: Validity of data should be determined as early as possible to make errors easier to fix.
- Feature: Validator should run whenever data is published/ingested into data portals.
π . | π₯ | π οΈ |
---|---|---|
2020 Q3 | Cal-ITP, MobilityData | Feature originated in vision discussion. |
2021 Q2 | MobilityData | We are now populating the Mobility Archives, will run Validator on every dataset. |
- Need: A way for users to better understand content of the validation report.
- Feature: A web user interface that will present the content of the validation report.
π . | π₯ | π οΈ |
---|---|---|
2020 Q3 | Cal-ITP, MobilityData | Feature originated in vision discussion. |
- Need: Make the Validator easily usable by anyone.
- Feature: Web user interface that will allow users to use an online instance of the gtfs-validator without having to use the command line.
π . | π₯ | π οΈ |
---|---|---|
2020 Q3 | Cal-ITP | Feature originated in vision discussion. |
- Need: GTFS has been extended, validation of the additional concepts would help ease implementation.
- Feature: Add rules for each extensions. Areas needing rules include Pathways, Fares v2.
π . | π₯ | π οΈ |
---|
- Need: Show if the data is compliant with the Best Practices.
- Feature: Add warnings to show if dataset is not complaint with Best Practices
π . | π₯ | π οΈ |
---|
- Need: Discover errors that may have occurred as a result of updating dataset.
- Feature: Compare dataset to previous version. Flag if changes are widespread.
π . | π₯ | π οΈ |
---|