diff --git a/.github/workflows/check_website_returns_200_OK.yaml b/.github/workflows/check_website_returns_200_OK.yaml deleted file mode 100644 index ad078a5e..00000000 --- a/.github/workflows/check_website_returns_200_OK.yaml +++ /dev/null @@ -1,25 +0,0 @@ -name: Check Website returns 200 OK - -on: - workflow_dispatch: -# workflow_run: -# workflows: -# - Update website on server -# types: -# - completed - -jobs: - validate: - runs-on: ubuntu-latest - steps: - - name: Wait for 5 minutes - run: sleep 300 - - - name: Check HTTP Status Code - run: | - STATUS_CODE=$(curl -s -o /dev/null -w "%{http_code}" https://tods-transit.org/ ) - if [ "$STATUS_CODE" -ne 200 ]; then - echo "Error: Website returned status code $STATUS_CODE" - exit 1 - fi - echo "Website is up and returned 200" diff --git a/.github/workflows/lint.yml b/.github/workflows/lint.yml deleted file mode 100644 index fa30269b..00000000 --- a/.github/workflows/lint.yml +++ /dev/null @@ -1,17 +0,0 @@ -name: Lint and style checks - -on: - workflow_dispatch: -# push: -# branches: [ main ] -# pull_request: -# branches: [ main ] - -jobs: - lint: - runs-on: ubuntu-latest - steps: - - uses: actions/checkout@v4.2.2 - - uses: actions/setup-python@v5.6.0 - - uses: pre-commit/action@v3.0.1 - - uses: tcort/github-action-markdown-link-check@v1.1.0 diff --git a/.github/workflows/update-requirements.yaml b/.github/workflows/update-requirements.yaml deleted file mode 100644 index 89c7e181..00000000 --- a/.github/workflows/update-requirements.yaml +++ /dev/null @@ -1,71 +0,0 @@ -name: Update requirements.txt - -on: - schedule: - - cron: '0 3 1 * *' # Runs every first day of the month @ 3 AM. - workflow_dispatch: # Allow manual runs - -jobs: - update-requirements: - runs-on: ubuntu-latest - - steps: - - name: Setup global variables - id: global_vars - run: | - echo "TODAYS_DAY=$(date '+%d')" >> $GITHUB_ENV # Ex.: 27 - echo "TODAYS_MONTH=$(date '+%m')" >> $GITHUB_ENV # Ex.: 07 - echo "TODAYS_YEAR=$(date '+%Y')" >> $GITHUB_ENV # Ex.: 2023 - - - name: Checkout repository - uses: actions/checkout@v7.0.0 - - - name: Set up Python - uses: actions/setup-python@v6.3.0 - with: - python-version: 3.11 # Adjust to your required Python version - - - name: Load secrets from 1Password - id: onepw_secrets - uses: 1password/load-secrets-action@v4.0.1 - with: - export-env: true # Export loaded secrets as environment variables - env: - OP_SERVICE_ACCOUNT_TOKEN: ${{ secrets.OP_SERVICE_ACCOUNT_TOKEN }} - GITHUB_TOKEN: "op://rbiv7rvkkrsdlpcrz3bmv7nmcu/GitHub generic action token for all repos/credential" - - - name: Install pur and update requirements file - run: | - pip install --upgrade pur - pur -r requirements.txt - - - name: Remove venv from git tracking - run: | - git clean -fdX venv - - - name: Check for changes - id: check_changes - run: | - if git diff --exit-code requirements.txt; then - echo "changes=false" >> $GITHUB_ENV - else - echo "changes=true" >> $GITHUB_ENV - fi - - - name: Create branch name - id: create_branch_name - run: | - echo "BRANCH=update-requirements-${{ env.TODAYS_YEAR }}-${{ env.TODAYS_MONTH }}-${{ env.TODAYS_DAY }}" >> $GITHUB_OUTPUT - - - name: Create Pull Request - id: createpr - if: env.changes == 'true' - uses: peter-evans/create-pull-request@v7.0.6 - with: - token: ${{ env.GITHUB_TOKEN }} - sign-commits: true - assignees: "fredericsimard" - branch: ${{ steps.create_branch_name.outputs.BRANCH }} - commit-message: 'This PR updates the `requirements.txt` file with the latest versions of dependencies.' - title: 'Monthly `requirements.txt` update' - body: 'This PR updates the `requirements.txt` file with the latest versions of dependencies.' diff --git a/.github/workflows/update_website_contents_on_server.yml b/.github/workflows/update_website_contents_on_server.yml deleted file mode 100644 index 0d0fd115..00000000 --- a/.github/workflows/update_website_contents_on_server.yml +++ /dev/null @@ -1,43 +0,0 @@ -name: Update website on server - -# Controls when the action will run. Workflow runs when manually triggered using the UI or API. -on: - workflow_dispatch: - push: - branches: - - main - paths-ignore: - - '.gitignore' - - '.gitattributes' - - 'LICENSE' - - 'README.md' - - '.github/workflows/**' - -# A workflow run is made up of one or more jobs that can run sequentially or in parallel -jobs: - build: - name: Build - runs-on: ubuntu-latest - steps: - - - name: Load secrets from 1Password - id: onepw_secrets - uses: 1password/load-secrets-action@v2.0.0 - with: - export-env: true # Export loaded secrets as environment variables - env: - OP_SERVICE_ACCOUNT_TOKEN: ${{ secrets.OP_SERVICE_ACCOUNT_TOKEN }} - ACTION_GXFS_WEBSERVER_SSH_HOST: "op://rbiv7rvkkrsdlpcrz3bmv7nmcu/kttdw7r3jp6rir7rtgkwk2a22q/ACTION_GXFS_WEBSERVER_SSH_HOST" - ACTION_GXFS_WEBSERVER_SSH_PORT: "op://rbiv7rvkkrsdlpcrz3bmv7nmcu/kttdw7r3jp6rir7rtgkwk2a22q/ACTION_GXFS_WEBSERVER_SSH_PORT" - ACTION_GXFS_WEBSERVER_SSH_USER: "op://rbiv7rvkkrsdlpcrz3bmv7nmcu/kttdw7r3jp6rir7rtgkwk2a22q/ACTION_GXFS_WEBSERVER_SSH_USER" - ACTION_GXFS_WEBSERVER_SSH_PRIVATE_KEY: "op://rbiv7rvkkrsdlpcrz3bmv7nmcu/kttdw7r3jp6rir7rtgkwk2a22q/ACTION_GXFS_WEBSERVER_SSH_PRIVATE_KEY" - - - name: executing remote ssh commands using password - uses: appleboy/ssh-action@master - with: - host: ${{ env.ACTION_GXFS_WEBSERVER_SSH_HOST }} - username: ${{ env.ACTION_GXFS_WEBSERVER_SSH_USER }} - key: ${{ env.ACTION_GXFS_WEBSERVER_SSH_PRIVATE_KEY }} - port: ${{ env.ACTION_GXFS_WEBSERVER_SSH_PORT }} - script: | - ./tods_mobilitydata_org_webaite_updater.sh \ No newline at end of file diff --git a/CITATION b/CITATION index 6398a274..3816403c 100644 --- a/CITATION +++ b/CITATION @@ -2,12 +2,12 @@ ## APA -Operational Data Standard Working Group. (2022). Transit Operational Data Standard. Operational Data Standard Board of Directors. Retrieved from https://ods.calitp.org +Operational Data Standard Working Group. (2022). Transit Operational Data Standard. Operational Data Standard Board of Directors. Retrieved from https://tods-transit.org. ## MLA -Operational Data Standard Working Group. Transit Operational Data Standard. Operational Data Standard Board of Directors, 2022, https://ods.calitp.org. +Operational Data Standard Working Group. Transit Operational Data Standard. Operational Data Standard Board of Directors, 2022, https://tods-transit.org. ## Chicago -Operational Data Standard Working Group. 2022. Transit Operational Data Standard. Operational Data Standard Board of Directors. https://ods.calitp.org. +Operational Data Standard Working Group. 2022. Transit Operational Data Standard. Operational Data Standard Board of Directors. https://tods-transit.org. diff --git a/Makefile b/Makefile deleted file mode 100644 index 58c28809..00000000 --- a/Makefile +++ /dev/null @@ -1,23 +0,0 @@ -PHONY: help - -help: ## This help. - @awk 'BEGIN {FS = ":.*?## "} /^[a-zA-Z0-9_-]+:.*?## / {printf "\033[36m%-30s\033[0m %s\n", $$1, $$2}' $(MAKEFILE_LIST) - -clean: - rm -rf generated/ - -setup: - pip3 install --force-reinstall -r requirements.txt && \ - pip3 install --upgrade --force-reinstall mkdocs-material - -serve: clean - @echo "Starting MkDocs server..." - @trap 'echo "Stopping MkDocs server..."; pkill -f "mkdocs serve"' SIGINT SIGTERM; \ - mkdocs serve -f config/en/mkdocs.yml --dev-addr 127.0.0.1:8000 --livereload --watch overrides - -build: clean - mkdir -p generated # Ensure the folder exists - mkdocs build -f config/en/mkdocs.yml --clean - -killserve: - pkill -f "mkdocs serve" diff --git a/README.md b/README.md index 4ca6720e..5204ca6a 100644 --- a/README.md +++ b/README.md @@ -2,7 +2,7 @@ The Transit Operational Data Standard (TODS) is an open standard for describing how to operate scheduled transit operations which can be used to port scheduled operations between software products (e.g. scheduling systems and CAD/AVL systems), agencies, and more. TODS leverages the existing [General Transit Feed Specification](https://gtfs.org) (GTFS) and extends it to include information about personnel and non-revenue service. -Complete documentation published at: +Complete documentation published at: [tods-transit.org](https://tods-transit.org) ## License to Use @@ -12,29 +12,6 @@ The TODS Specification is licensed under the [Apache License 2.0](https://www.ap If you use the Transit Operational Data Standard in a report or article, please cite it as follows: -> Transit Operational Data Standard Working Group. 2022. Transit Operational Data Standard. Transit Operational Data Standard Board of Directors. https://tods.mobilitydata.org. +> Transit Operational Data Standard Working Group. 2022. Transit Operational Data Standard. Transit Operational Data Standard Board of Directors. [tods-transit.org](https://tods-transit.org) Additional citation styles can be found in [CITATION](CITATION). - -## Building the site locally - -1. In Terminal, change the directory to one where you wish to build the site. -1. Ensure you have an up-to-date version of pip: - - Linux: `pip install pip` or `pip install --upgrade pip` - - macOS: `pip3 install pip` or `pip3 install --upgrade pip` -1. Clone this repository: - - `git clone https://github.com/MobilityData/operational-data-standard` -1. Change the directory to the cloned repository, and create & enable a Python virtual environment: - - `python3 -m venv venv` - - `source venv/bin/activate` -1. Have [`requirements.txt`](requirements.txt) installed: - - Linux: `pip install --force-reinstall -r requirements.txt` - - macOS: `pip3 install --force-reinstall -r requirements.txt` -1. To run the site locally (command defined in `MakeFile`): - - `make serve` - - Then you can reach the site at this address: `http://127.0.0.1:8000/` - - To shut down MKdocs from serving the site: `make killserve` -1. To build the site locally only (command defined in `MakeFile`): - - `make build` -1. Deactivate the Python virtual environment when done: - - `deactivate` \ No newline at end of file diff --git a/config/en/mkdocs.yml b/config/en/mkdocs.yml deleted file mode 100644 index eb396654..00000000 --- a/config/en/mkdocs.yml +++ /dev/null @@ -1,137 +0,0 @@ -site_name: "Transit Operational Data Standard" -site_url: https://tods.mobilitydata.org/ -repo_url: https://github.com/MobilityData/operational-data-standard -repo_name: TODS Specification -docs_dir: ../../docs/en # Where to find the English markdown files -site_dir: ../../generated/ # Where to put the English HTML files - -theme: - name: material - language: en - custom_dir: ../../overrides/ - features: - - navigation.expand - - navigation.tabs - - toc.integrate - palette: - primary: custom - accent: custom - text: custom - background: custom - highlight: custom - logo: assets/images/ods-small-eggshell.png - favicon: assets/images/favicon.ico - -plugins: - - search: - lang: - - en - - awesome-pages - -extra: - analytics: - provider: google - property: G-HKC18043J5 - consent: - title: Cookie Consent - description: >- - We use cookies to track visits, stored anonymously. With your consent, you're helping us to make our documentation better. See our Privacy Policy. - actions: - - accept - - reject - - manage - social: - - icon: fontawesome/brands/github - link: https://github.com/MobilityData - - icon: fontawesome/brands/linkedin - link: https://www.linkedin.com/company/mobilitydata - - icon: fontawesome/brands/slack - link: https://share.mobilitydata.org/slack - # alternate: - # - name: English - # link: / - # lang: en - -extra_javascript: - - https://unpkg.com/mermaid@8.5.0/dist/mermaid.min.js - - assets/javascript/fix-md-search.js - -extra_css: - - https://use.fontawesome.com/releases/v5.13.0/css/all.css - - assets/stylesheets/additional.css - -markdown_extensions: - - admonition - - codehilite: - linenums: true - - pymdownx.inlinehilite - - pymdownx.tasklist: - custom_checkbox: true - - pymdownx.tabbed - - pymdownx.superfences: - custom_fences: - - name: mermaid - class: mermaid - format: !!python/name:pymdownx.superfences.fence_div_format - - pymdownx.smartsymbols - - pymdownx.caret - - pymdownx.mark - - pymdownx.tilde - - meta - - toc: - # insert a blank space before the character - permalink: " ¶" - - smarty - - pymdownx.emoji: - emoji_index: !!python/name:material.extensions.emoji.twemoji - emoji_generator: !!python/name:material.extensions.emoji.to_svg - -nav: - - Home: index.md - - About: - - about/about.md - - Initial Specification Development Process: about/spec-development.md - - Contributors: about/contributors.md - - Attribution: about/attribution.md - - Specification: - - spec/index.md - - Revision History: spec/revision-history.md - - Examples: spec/examples.md - - Governance: - - governance/governance.md - - Board Actions: governance/actions.md - - Board Meetings: governance/board-meetings.md - - Contributor Meetings: governance/contributor-meetings.md - - Policies: - - Change Management: governance/policies/change-management-versioning.md - - Board Composition: governance/policies/board-composition.md - - Board Decision Making: governance/policies/board-decisionmaking.md - - Code of Conduct: governance/policies/code-of-conduct.md - - Contributor License Agreement: governance/policies/CLA.md - - Repository Access: governance/policies/repository-organization-access.md - - Resources: - - Handouts + Presentations: resources/resources.md - - Frequently Asked Questions: resources/faq.md - - Implementation Guide: resources/implementation-guide.md - - Upcoming Engagements: resources/upcoming-engagements.md - -copyright: | -
-
-
-

- TODS Project - by TODS Board of Directors is licensed under - - CC BY 4.0 - Creative Commons - Attribution - -

-
-
-
diff --git a/docs/en/about/about.md b/docs/en/about/about.md deleted file mode 100644 index d23ae74b..00000000 --- a/docs/en/about/about.md +++ /dev/null @@ -1,16 +0,0 @@ -# About TODS - -The Transit Operational Data Standard ("TODS") is managed by [MobilityData](https://mobilitydata.org) serving as the [TODS Manager](../governance/governance.md#tods-manager) under the authority of the [TODS Board](../governance/governance.md#tods-board-of-directors) with basic monetary support through 2025 from the [California Integrated Travel Project (Cal-ITP)](https://cal-itp.org). - -TODS was [initially developed](spec-development.md) in 2021-2022 by the [TODS Working Group](contributors.md) (now known as *contributors*) using resources from the [California Integrated Travel Project (Cal-ITP)](https://cal-itp.org) in order to: - -1. Create a common standard for transit operational data -2. Improve efficiency in dispatching, planning, scheduling, driver shift management, and other back-end transit operations -3. Reduce the burden of generating data for reporting (FTA and other) - -As of 2024: - -* TODS v1.0 is leveraged by several software vendors and transit agencies, -* TODS v2.0 has been adopted and is ready for implementation, -* [Independent governance and ownership](../governance/governance.md) has been established in order to meet the [Mobility Data Interoperability Principles'](https://interoperablemobility.org) definition of an **Open Standard**. -* TODS is specified as a suggested requirement for Scheduling and CAD/AVL systems in the Mobility Data Interoperability Principles' [Procurement Resource](https://interoperablemobility.org/procurement) diff --git a/docs/en/about/attribution.md b/docs/en/about/attribution.md deleted file mode 100644 index b79c1ed2..00000000 --- a/docs/en/about/attribution.md +++ /dev/null @@ -1,13 +0,0 @@ -# Attribution - -The project was initiated by the [California Integrated Travel Project](https://calitp.org), a project of the California Department of Transportation. - -The project has been resourced by the [California Integrated Travel Project](https://calitp.org) and the [TODS Working Group](../resources/faq.md#what-is-the-tods-working-group). - -The Transit Operational Data Standard (TODS) project is the property of the TODS Board. As of January 2024, the TODS Project is managed by [MobilityData](https://mobilitydata.org) under the authority of the TODS Board. - -## Citation - -If you use the Transit Operational Data Standard in a report or article, please cite it as follows: - -> Transit Operational Data Standard Working Group. 2022. Transit Operational Data Standard. Transit Operational Data Standard Board of Directors. https://ods.calitp.org. diff --git a/docs/en/about/contributors.md b/docs/en/about/contributors.md deleted file mode 100644 index f536a7a1..00000000 --- a/docs/en/about/contributors.md +++ /dev/null @@ -1,63 +0,0 @@ -# Contributors - -The Transit Operational Data Standard Contributors Group (formerly known as the TODS Working Group) is convened by [TODS Board](../governance/governance.md#tods-board-of-directors) as part of its goal to provide complete, accurate, and up-to-date transit data to customers and respective agencies. - -Contributors are expected to commit to supporting the adopted TODS v1 specification. Depending on the organization,supporting the TODS v1 specification may entail developing software to produce or consume the specification, or, for transit agencies, encouraging vendors to support the specification. - -## Membership - -### Transit Agencies - -[AC Transit, CA](https://www.actransit.org/) -[Clovis Transit, CA](https://cityofclovis.com/general-services/transit/) -[Community Transit, WA](https://www.communitytransit.org/) -[Foothill Transit, CA](http://foothilltransit.org/) -[Golden Empire Transit, CA](https://www.getbus.org/) -[Kings Area Rural Transit (KART), CA](https://www.kartbus.org/) -[Los Angeles DOT, CA](https://www.ladottransit.com/dash/) -[Marin Transit, CA](https://marintransit.org/) -[Massachussets Bay Transit Authority (MBTA), MA](http://mbta.com) :material-check-circle-outline: -[Metrolink, CA](https://metrolinktrains.com/) -[Metro Transit, MN](https://www.metrotransit.org) -[Nevada County Connects, CA](https://www.mynevadacounty.com/2257/Transit-Services) -[OmniTrans, CA](https://omnitrans.org/) -[Pasadena Transit, CA](https://www.cityofpasadena.net/pasadena-transit/) -[SamTrans, CA](https://www.samtrans.com/) -[Sound Transit, WA](https://www.soundtransit.org/) -[Stanislaus Regional Transit Authority, CA](https://www.srt.org/) -[TriMet, OR](https://trimet.org/) - -### Companies - -[Avail](https://availtec.com/) -[Clever Devices](https://www.cleverdevices.com/) -[Connexionz](https://www.connexionz.com/) -[Cubic](https://www.cubic.com/) -[Dilax](https://www.dilax.com/) -[Engie](https://www.engie.com/en) -[Giro](https://www.giro.com/) :material-check-circle: (on-request) -[GMV Syncromatics](https://gmvsyncromatics.com/) -[Init](https://www.initse.com/enus/start/) -[Keolis](https://www.keolisna.com/) -[MV Transit](https://www.mvtransit.com/) -[Optibus](https://www.optibus.com/) :material-check-circle: -[Passio](https://passiotech.com/) -[Remix by Via](https://www.remix.com/) :material-check-circle: -[Routematch / Uber](https://www.routematch.com/) -[Swiftly](https://www.goswift.ly/) :material-check-circle: -[The Master Scheduler](https://themasterscheduler.com/) :material-check-circle: -[Trapeze](https://www.trapezegroup.com/) -[Trillium Solutions](https://trilliumtransit.com/) - -### Other - -[Amalgamated Transit Union](https://www.atu.org/) -[California Association for Community Transportation (CALACT)](http://calact.org) -[California Integrated Travel Project (Cal-ITP)](http://calitp.org) -[Metropolitan Transportation Commission/511.org](http://mtc.ca.gov) - -!!! Note "Implementers" - - :material-check-circle: denotes an organization who has implemented TODS - - :material-check-circle-outline: denotes an organization in the process of implementing TODS diff --git a/docs/en/about/spec-development.md b/docs/en/about/spec-development.md deleted file mode 100644 index e98ddc91..00000000 --- a/docs/en/about/spec-development.md +++ /dev/null @@ -1,68 +0,0 @@ -# History + Initial Specification Development Process - -The California Integrated Travel Project (Cal-ITP) developed the TODS initiative in response to feedback from local transit providers and vendors. As Cal-ITP has as its core a mission to improve the quality of mobility data and increase the efficiency of transportation service delivery in the state of California, Cal-ITP conducted research and conversations with an eye toward identifying existing pain points. Many tranit agencies identified the lack of a standard format between scheduling and CAD/AVL software as a major source of friction. - -## Establishing Feasibility + Need - -In 2020, Cal-ITP studied the feasibility and documented the product requirements of a data standard that would reduce the friction between scheduling and operating transit service. The friction between these two activities was particuarlly acute during the height of the COVID Pandemic when transit agency schedules were in a constant state of change due to labor availability and safety precautions. - -### Landscape Analysis - -We analyzed the current landscape of systems and connections involved in transit operations. The primary focus was on the various interfaces and touchpoints between the Scheduling and CAD/AVL systems. The landscape analysis concluded that a data standard that connected scheduling and CAD-AVL systems was both feasible and not duplicative of any existing standardization efforts. - -:material-chevron-right: [Data Flow Diagrams](https://docs.google.com/document/d/1nNnVgmk29ExZU7_bkoawkpvP_gtn3DSR9eV8BugUY14/edit?usp=sharing) - -:material-chevron-right: [Field Mapping](https://docs.google.com/spreadsheets/d/1P7jLcp9BDx2Q-FVVR0fdc_eH5cEVxXjA1tdpID_uoTM/edit?usp=sharing) - -### Document Product Requirements - -The Product Requirements Document synthesized the landscape analysis into a realistic set of use cases with associated data model requirements. - -:material-chevron-right: [Product Requirement Document](https://docs.google.com/document/d/1KFLoMAj-XmNrn0MbCVB_IwlK2bILvuVImkjxXrZ9AXk/edit?usp=sharing) - -### Consulted organizations - -The following organizations were consulted as a part of the feasibility analysis: - -- LADOT -- Santa Barbara MTD -- Santa Rosa: -- Marin Transit -- Golden Empire Transit (GET Bus) -- Chicago Transit Authority -- Massachusetts Bay Transportation Authority -- IBI Group -- GMV Synchromatics -- Optibus -- Clever Devices -- Swiftly -- The Master Scheduler -- Trillium - -## Initial Development - -In 2021, Cal-ITP convened the [TODS Working Group](../resources/faq.md#what-is-the-tods-working-group), composed of stakeholders throughout the mobility industry, for the purpose of developing and adopting a first version of a Transit Operational Data Standard (TODS). These stakeholders included transit schedule firms, CAD/AVL firms, public transit providers, private transit providers, local governments and metropolitan planning organizations (MPOs), labor unions, and manufacturers of integrated on-vehicle hardware solutions (such as Automated Passenger Counting devices or LED signage). - -Meetings began in Summer of 2021 and continued through the end of 2021, at which point a framework for v1.0.0 had been reached. After spending several months resolving minor issues with the framework, the TODS Working Group approved v1.0.0 on May 3rd, 2022. -For a full list of past meetings and videos, go to the [Contributor Meetings page](../governance/contributor-meetings.md). - -## Implementation v1.0 - -2022 and 2023 saw the first implementations of TODS at agencies and vendors alike in the wild, including the first implementation by [WETA](https://weta.sanfranciscobayferry.com/) and [Swiftly](https://www.goswift.ly/). - -## Continued Improvement - -Implementation activities yielded a great deal of excitement about the TODS standard, but also a long wish-list for v2.0. v2.0 is [currently in the works.](https://github.com/cal-itp/operational-data-standard/issues/49). - -## Evolution of Management - -Recognizing that a State DOT is not the ideal place to manage a data standard, in 2023 Cal-ITP looked outside its walls to identify: - -1. an organization to assume day-to-day management of TODS; and -2. a governance and management model which would rest key decisions with the major TODS stakeholders. - -In January 2024: - -- the day-to-day management of the TODS standard will be assumed by [MobilityData](https://mobilitydata.org), the same organization that manages [GTFS](https://gtfs.org) (upon which TODS relies); and -- the ownership and key decisions about TODS will be transfered from Cal-ITP to an [independent board](../governance/governance.md#tods-board-of-directors) composed of transit agencies, and both schedule and CAD/AVL vendors. -- future spec development will be governed by the [change management and versioning policy](../governance/policies/change-management-versioning.md) diff --git a/docs/en/governance/actions.md b/docs/en/governance/actions.md deleted file mode 100644 index 8b589c34..00000000 --- a/docs/en/governance/actions.md +++ /dev/null @@ -1,24 +0,0 @@ -# TODS Board Actions - -Record of actions taken by the TODS Board. - -*Note that routine actions such as approval of meeting minutes are not listed here* - -| **Date** | **Action** | **Record (Yes - No - Abstain)** | -| -------- | ---------- | ---------- | -| 2026-03-23 | Board approval to recognize Board Chair as a named role on the TODS Governance page. | (5 - 0 - 0) | -| 2025-09-25 | Joshua Fabian elected to replace Scott Frazier as Board Coordinator. | (5 - 0 - 0) | -| 2025-04-23 | Board approval of TODS Change Management and Versioning Policy amendment regarding development cycles. | (5 - 0 - 0) | -| 2025-03-26 | Direct TODS Program Manager to amend the TODS Change Management and Versioning Policy to stipulate that the TODS Manager will lead at least 1 development cycle annually. | (4 - 0 - 0) | -| 2025-01-22 | Member Tollison's resignation from the Board sparks a proposal to follow up with individuals previously expressing interest in serving on the Board as an immediate next step and following up with the Board with additional proposals to expand the pool of Board Member candidates in the future | (3 - 0 - 0) | -| 2025-01-22 | Chair Jensen's employment was transfered without issue from his previous employement, to his new. Both positions were in public transit, not private enterprise. | (3 - 0 - 0) | -| 2024-09-18 | Board voted to readd TODS 1.0 definitions back to site, with indication that updates were no longer being made based on TODS 1.0 and that all future updates would be based on TODS 2.0| (5 - 0 - 0) | -| 2024-09-18 | Board supported a proposal to offer assistance/advice to the development teams for Giro and to collaborate on their implementation of TODS in Hastus and eventual TODS 2.0 based integration.| (5 - 0 - 0) | -| 2024-09-18 | Board supported a proposal to offer assistance/advice to the development teams for Optibus and GMV and to collaborate on their TODS 2.0 based integration.| (5 - 0 - 0) | -| 2024-07-24 | TODS 2.0 is adopted, now to be implemented. | (5 - 0 - 0) | -| 2024-06-26 | ODS Program Manager granted authority to make non-substantive changes to TODS governance to fix typos and change spec branding from ODS to TODS. | (5 - 0 - 0) | -| 2024-06-26 | Direct TODS Program Manager to transition TODS versioning to semantic versioning in the format X.X.X representing [breaking change].[non breaking change].[patch]. | (5 - 0 - 0) | -| 2024-06-26 | Direct TODS Program Manager to release all adopted proposals for a given development cycle under a single "bundled" version, rather than issuing a version for each adopted proposal individually. | (5 - 0 - 0) | -| 2024-03-11 | Erik Jansen elected as Board Chair. | (5 - 0 - 0) | -| 2024-03-11 | Scott Frazier elected as Board Coordinator. | (5 - 0 - 0) | -| 2024-03-11 | TODS Program Manager granted authority to move TODS repo out of Cal-ITP organization. | (5 - 0 - 0) | diff --git a/docs/en/governance/assets/MOU_ODS_and_Mobility_Data_signed.pdf b/docs/en/governance/assets/MOU_ODS_and_Mobility_Data_signed.pdf deleted file mode 100644 index 48d6a816..00000000 Binary files a/docs/en/governance/assets/MOU_ODS_and_Mobility_Data_signed.pdf and /dev/null differ diff --git a/docs/en/governance/board-meetings.md b/docs/en/governance/board-meetings.md deleted file mode 100644 index 04e2d0cb..00000000 --- a/docs/en/governance/board-meetings.md +++ /dev/null @@ -1,29 +0,0 @@ -# TODS Board Meetings - -The TODS Board Meeting Agendas & Minutes are available below. - -## 2026 - -[Rolling Agendas & Minutes for monthly meetings](https://docs.google.com/document/d/1AJT_rLOlIwl1zsh9oF-HPxCQo-1s5IJ4RFohh9_NewY/edit?usp=sharing) - -## 2025 - -| **Date** | **Minutes** | -| -------- | ---------- | -| 22 January 2025 | [Agenda & Minutes](https://docs.google.com/document/d/18tAwwYKdcqTJ9auGbvVNpY08HnS9kkLUFJbM2i1w718/edit?usp=sharing) | -| 26 March 2025 | [Agenda](https://docs.google.com/document/d/1RUx7vOqt0JUUWA68fUTGEh_bAnERjMsXPkZtRZoOSwA/edit?usp=sharing) & [Minutes](https://docs.google.com/document/d/1lP6kdKpNEFBnD-iuqfZFCfByFEENucQRmNjeEiExrv0/edit?usp=sharing) | -| 23 April 2025 | [Agenda](https://docs.google.com/document/d/11ThfreVUiS-4lvtOXJK128koMB_7YzTz6p91sagegFA/edit?usp=sharing) & [Minutes](https://docs.google.com/document/d/12T2yiXucb9gE1PMWNw7kPPWFBiBevCNiIgtU9Zvx-Sw/edit?usp=sharing) | -| 25 June 2025 | [Agenda](https://docs.google.com/document/d/14UDgwH1jIxCMYZAl2BmyznR69ZZAa4V_gdC2XPe8tVI/edit?usp=sharing) | -| 25 September 2025 | [Agenda](https://docs.google.com/document/d/13axpKpjCebxV5K2HP7elQLpF3rE1sRfViRcycHTJyRA/edit?usp=sharing) & [Minutes](https://docs.google.com/document/d/1vL6I_ArzQ2Wmx4sDypKciaje3yjzAU_J0tU5SIh0UoQ/edit?usp=sharing) | -| 27 October 2025 | [Agenda](https://docs.google.com/document/d/18QTpPyFBT-ceGLgxS-zQEuKFqg3NkzsxJYPJg1qtZxs/edit?usp=sharing) & [Minutes](https://docs.google.com/document/d/1V-PYo_3NgbU59fvl2D48YcdaMz7cHPaiaQ6BQf5-2QM/edit?usp=sharing) | -| 24 November 2025 | [Agenda](https://docs.google.com/document/d/1jUq-mC6py4X-zW9AxH7Mv74PpBTQR_nk2RlIWMoISJw/edit?usp=sharing) & [Minutes](https://docs.google.com/document/d/1ZJk4QQlSygS9tpDoqDmCFjaVKQlMOz-SdfPnCADKVOo/edit?usp=sharing) | -| 22 December 2025 | [Agenda](https://docs.google.com/document/d/1tZ9kvzOcrH3vdw_zjCzkCgnndBizXN_ScjvUQCgu948/edit?usp=sharing) & [Minutes](https://docs.google.com/document/d/1NDd8TPhgsFFte087nW4XpxCNRXIuXWQ9wV75gVPODxk/edit?usp=sharing) | - -## 2024 - -| **Date** | **Minutes** | -| -------- | ---------- | -| 11 March 2024 | [Agenda & Minutes](https://docs.google.com/document/d/1Y76UMxpnR0vQm2F8s02s8gIYr7JyHNFOX-lSFQheC8Q/edit?usp=sharing) | -| 26 June 2024 | [Agenda & Minutes](https://docs.google.com/document/d/1Y76UMxpnR0vQm2F8s02s8gIYr7JyHNFOX-lSFQheC8Q/edit?usp=sharing) | -| 24 July 2024 | [Agenda](https://docs.google.com/document/d/1GhQDt39f45WMvLpaBXvOVmZmAbyw-wNhK9ZlDj7Ci3M/edit?usp=sharing) | -| 18 September 2024 | [Agenda & Minutes](https://docs.google.com/document/d/1FyFHIH8IEYflgzyLm3_Zsh67WrdMZixoYZpfvL3wyz8/edit?usp=sharing) | diff --git a/docs/en/governance/contributor-meetings.md b/docs/en/governance/contributor-meetings.md deleted file mode 100644 index b3c94f9a..00000000 --- a/docs/en/governance/contributor-meetings.md +++ /dev/null @@ -1,29 +0,0 @@ -# Contributor Meetings - -## TODS Q3 2024 Development Cycle - -| Meeting | Date | Agenda | Minutes | Video | -| :---------- | :---- | :------ | :------- | :----- | -| Q3 2024 Development Priorities | 23 Jul 2024 | [Agenda](https://drive.google.com/file/d/1wY1Mp8tnYxvtGoaGzvTfeB6CaD6r_VbT/view?usp=sharing) | [Minutes](https://drive.google.com/file/d/1DK9hDQxLyQy_f1HEhW7P-N-lAAHTT3Xa/view?usp=drive_link) | [Video](https://drive.google.com/file/d/1UpYKlSiFWJa5mmfu1q6nttWFSd4WT7hn/view?usp=sharing) | - -## TODS 2.0 - -| Meeting | Date | Description | -| :---------- | :---- | :----------------------------------- | -| Working Group Meeting #1
| 7 Feb 2024 | Review of proposed spec changes for ODS v2.0. | -| Working Group Meeting #2
| 27 Feb 2024 | Finalizing structure of "GTFS-supplemental" approach for ODS v2.0. | -| Working Group Meeting #3
| 4 Apr 2024 | Review of and feedback on Run Events proposal; decide next steps on "GTFS-supplemental" proposal. | - -## TODS 1.0 - -| Meeting | Date | Description | -| :---------- | :---- |:----------------------------------- | -| [Working Group Meeting #1](https://docs.google.com/presentation/d/1y_xF002j0NJxt-pGTO2bR473rKWrNUzWvNZLncsbAXQ/edit?usp=sharing) | 20 Jul 2021 | Confirmation of need. | -| Stakeholder Scoping Meetings | Aug 2021 | Individual meetings with stakeholders to get detailed needs and scoping input. | -| [Working Group Meeting #2](https://docs.google.com/presentation/d/1x5cGNhLIBuYv_VM_Spdy85Vn7rWIDtlGSPsvDHTdjsI/edit?usp=drive_link) | Aug 2021 | Scope confirmation and process confirmation for spec development. | -| [Working Group Meeting #3](https://docs.google.com/presentation/d/1z2sgo3tA7JtLwSz9F6BFbbWrNK23gi8u5TdYsx30loc/edit?usp=drive_link) | 28 Sep 2021 | [Personnel Proposal](https://docs.google.com/document/d/1IL1mKME88M9jLHyyr545E1dLKWTdbRdt7OWihxgRjjI/edit?usp=drive_link)
[Meeting #3 notes](https://docs.google.com/document/d/1Fs1eRlKEDyKXCprV8pmDrr3QBMtuLczhvoG7t7Fn72w/edit?usp=drive_link) | -| [Working Group Meeting #4](https://docs.google.com/presentation/d/14A_j6A1ZqsaoNp_POVNWJb4Mu9-d_iO_0mdq-GJ7RSY/edit?usp=drive_link) | 19 Oct 2021 | [Facilities Proposal](https://docs.google.com/document/d/1p-fDePrnLBjJoceXLEbbYR1dPLwt6aoE26osMcp5NsQ/edit?usp=drive_link)
[Meeting #4 video](https://drive.google.com/file/d/1XeUm1QTEWUPXkge5GnVVbnwF6AmBY6ER/view?usp=drive_link) | -| Working Group Meeting #5 | 16 Nov 2021 | [Runcutting, Layovers, + Deadheads Proposal](https://docs.google.com/document/d/1GmBdo39QHIqD0MoPGT6RPyvkuxHYWQWXRi_rTOUYhpg/edit?usp=drive_link) | -| Working Group Meeting #6 | 21 Dec 2021 | Adoption of v1 framework
[Meeting #6 video](https://drive.google.com/file/d/1LAaAWFUjvPCTMvRs_1PhNT4WZZmcWbsZ/view?usp=drive_link) | -| [Working Group Meeting #7](https://docs.google.com/presentation/d/1p7qJSq5Ray07UZ_BNovW4MViXPZQi0by65ZbLDxNySk/edit?usp=drive_link) | 22 Feb 2022 | Discussion of Upcoming Implementation Steps
[Meeting #7 video](https://drive.google.com/file/d/1eiHYiwoUsjXVFFChWB7dqf8fSo1k-mxz/view?usp=drive_link) | -| Working Group Meeting #8 | 3 May 2022 | Reconsideration of v1 framework and adoption of 1.0.0
[Meeting #8 video](https://drive.google.com/file/d/1Eh_DJj1_9Copb0xHiFXSNBaS7My1UUsw/view?usp=drive_link) | diff --git a/docs/en/governance/governance.md b/docs/en/governance/governance.md deleted file mode 100644 index 5bbe45e9..00000000 --- a/docs/en/governance/governance.md +++ /dev/null @@ -1,180 +0,0 @@ -# TODS Governance - -This page outlines the policies, procedures, and structures that guide the collaborative and transparent development of the Transit Operational Data Standard ("TODS"). The TODS is a critical framework enabling effective dispatching and operations management through a standardized data schema. This document is intended for all members of the TODS Community, including the TODS Board of Directors, TODS Managers, TODS Contributors, and TODS Stakeholders. By clearly defining the principles, roles, and policies, we aim to facilitate the efficient, fair, and responsible advancement of the TODS Project. - -## Principles - -The TODS Governance is designed with the following principles in mind: - -**Merit** - -- Changes should have a clear purpose. -- Consequences of a change should be evaluated from the perspective of different affected stakeholder groups. -- Changes should be prioritized by the community. - -**Openness + Transparency** - -- Discussion and decisions about changes should be publicly noticed and accessible. -- Change-making process should be straight-forward and easy to follow. -- Change proposals should have a reliable timeline for being decided on and incorporated. -- Each change (or bundled set of changes) should be identified by assigning a new version number. - -**Efficiency** - -- Change-making process should be simple for simple changes. -- Complex changes should be made with careful consideration. -- Streamlined, purpose-driven change management should be applied to maximize stakeholder efficiency. -- Changes should be straightforward to incorporate by existing TODS Stakeholders. -- Significant changes, especially those which are not backwards compatible with existing datasets, should be limited in number and in frequency in order to limit the number of times existing processes and tools need to be re-engineered. -- A significant change merits a new version number. - -## Definitions - -### TODS Project - -The TODS Project encompasses: - -- [TODS Specification](#tods-specification) -- [TODS Tools](#tods-tools) -- [TODS Repository](#tods-repository) -- [TODS Documentation](#tods-documentation) -- [TODS Governance](#tods-governance) - -### TODS Governance - -Who and how decisions are made about the scope and direction of the TODS Project, including but not limited to the approved [roles and responsibilities](#roles) and the following policies: - -- [TODS Change Management and Versioning Policy](#tods-change-management-versioning-policy) -- [TODS Contributor Agreement](#tods-contributor-agreement) -- [TODS Code of Conduct](#tods-code-of-conduct) -- [TODS Use License](#tods-use-license) - -### TODS Specification - -The data schema documented on the [TODS Repository](#tods-repository) and [TODS Documentation](#tods-documentation) for the purposes of representing planned transit operations for use is dispatching and operations management software. - -### TODS Community - -The combined members of [TODS Board](#tods-board-of-directors), [TODS Manager](#tods-manager), [TODS Board Coordinator](#tods-board-coordinator), [TODS Contributors](#tods-contributor) and [TODS Stakeholders](#tods-stakeholder). - -### TODS Contributor Agreement - -Agreement contributors make when contributing to the [TODS Project](#tods-project) as documented at: [`CLA.md`](policies/CLA.md) - -### TODS Code of Conduct - -Agreement for behavior within the [TODS Community](#tods-community) which must be abided by by all of [TODS Board](#tods-board-of-directors), [TODS Contributors](#tods-contributor) and the [TODS Manager](#tods-manager) and its representatives as documented at [`code-of-conduct.md`](policies/code-of-conduct.md) - -### TODS Change Management + Versioning Policy - -How content of the [TODS Specification](#tods-specification) may be changed and released as an official [TODS version](policies/change-management-versioning.md#tods-release). - -### TODS Documentation - -The text and website (and supporting scripts) which describe the [TODS Specification](#tods-specification) and its purpose and usage located on the [TODS Repository](#tods-repository). - -### TODS Repository - -The version control repository containing the [TODS Specification](#tods-specification) located at: - - -### TODS Repository Organization - -The version control organization which contains the [TODS Repository](#tods-repository). - -!!! warning "To be migrated" - - The TODS Repository is currently located with the Cal-ITP GitHub organization but will be migrated as part of the process of transitioning management to MobilityData. - -### TODS Tools - -Any scripts or code released within the [TODS Repository Organization](#tods-repository-organization). - -### TODS Use License - -The [TODS Specification](#tods-specification) is licensed under the [Apache License 2.0](https://www.apache.org/licenses/LICENSE-2.0.txt) (code) and [Creative Commons Attribution 4.0](https://creativecommons.org/licenses/by/4.0/) (sample data, specification, and documentation) as defined in [`LICENSES`](https://github.com/cal-itp/operational-data-standard/blob/main/LICENSES) file in the [GitHub repository](https://github.com/cal-itp/operational-data-standard). - -## Roles - -Responsibility for the governance of the TODS Project is divided among the following [roles](#roles) as defined here and fulfilled by the following individuals as noted: - -| **Role** | **Who** | -| -------- | ----- | -| [TODS Board](#tods-board-of-directors) | | -| [TODS Board Coordinator](#tods-board-coordinator) | [Joshua Fabian](https://www.linkedin.com/in/jfabi/) | -| [TODS Manager](#tods-manager) | [MobilityData](https://mobilitydata.org) | -| [TODS Program Manager](#tods-program-manager) | [Carl Fredlund](https://github.com/carlfredl), [MobilityData](https://mobilitydata.org) | -| [TODS Contributors](#tods-contributor) | [Contributors via GitHub](https://github.com/MobilityData/transit-operational-data-standard/graphs/contributors) | -| [TODS Stakeholders](#tods-stakeholder) | Anyone interested in or could be directly affected by the TODS Project. | - -### Memorandum of Understanding for TODS Management - -PDF Preview - - - PDF - Download PDF - - -## TODS Owner - -The TODS Project is collectively owned and overseen by the [TODS Board of Directors](#tods-board-of-directors). - -## TODS Board of Directors - -The TODS Board of Directors ("TODS Board") governs and collectively owns the [TODS Project](#tods-project). - -- The Board MAY select an individual or organization to serve as the [TODS Manager](#tods-manager) to handle the day-to-day management of the [TODS Specification](#tods-specification) and [TODS Project](#tods-project). -- The [TODS Board](#tods-board-of-directors) MUST execute a memorandum of understanding with the [TODS Manager](#tods-manager) (if one is chosen) that outlines the roles, responsibilities, and limitations of the management role. -- The [TODS Board](#tods-board-of-directors) MAY change the [TODS Manager](#tods-manager) at any time for any reason. -- In the event that there is not an active agreement with an [TODS Manager](#tods-manager) the [TODS Board](#tods-board-of-directors) MUST assume the [TODS Manager](#tods-manager) responsibilities. -- The [TODS Board](#tods-board-of-directors) SHOULD ask the [TODS Manager](#tods-manager) to select a new [TODS Program Manager](#tods-program-manager) if there is continued failure to perform and meet expectations. -- [TODS Board](#tods-board-of-directors) membership MUST be determined by the [Board Composition Policy](policies/board-composition.md). -- [TODS Board](#tods-board-of-directors) decisionmaking should be consistent with the [Board Decisionmaking Policy](policies/board-decisionmaking.md). - -TODS Board [meetings](board-meetings.md) and [actions](actions.md). - -## TODS Board Coordinator - -Chosen by the TODS Board, this individual is responsible for coordinating the actions and activities of the [TODS Board](#tods-board-of-directors). - -- The Board Coordinator MUST schedule, agendize and arrange for Board meetings in consultation with the TODS Board Chair and [TODS Program Manager](#tods-program-manager). -- The Board Coordinator MUST conduct votes by the [TODS Board](#tods-board-of-directors) and document results. -- The Board Coordinator MUST communicate with the [TODS Manager](#tods-manager) / [TODS Program Manager](#tods-program-manager) as needed. - -## TODS Manager - -Responsible for the daily management of the TODS Project at the direction of the [TODS Board](#tods-board-of-directors) including the: - -- [TODS Change Management Process](policies/change-management-versioning.md), -- [TODS Repository](#tods-repository), -- TODS Project resource management, and -- Internal and external project communications. - -- The [TODS Manager](#tods-manager) MAY be an individual or organization. -- The [TODS Manager](#tods-manager) MUST assign an individual as the [TODS Program Manager](#tods-program-manager). -- The [TODS Manager](#tods-manager) MUST communicate the name of the [TODS Program Manager](#tods-program-manager) to the [TODS Board](#tods-board-of-directors) in writing and notify the Board of any change in this assignment in writing. -- The [TODS Manager](#tods-manager) SHOULD select a new [TODS Program Manager](#tods-program-manager) if asked to do so by the TODS Board. - -## TODS Program Manager - -Serves as the main contact between the [TODS Board](#tods-board-of-directors) and the [TODS Manager](#tods-manager). - -## TODS Contributor - -Individuals apply to become Contributors by acknowledging and agreeing to the [TODS Contributor Agreement](#tods-contributor-agreement) and [TODS Code of Conduct](#tods-code-of-conduct). - -- An TODS Contributor MUST abide by the [TODS Code of Conduct](#tods-code-of-conduct) or face removal. -- An TODS Contributor MAY create issues, discussions, and pull requests in the [TODS Repository](#tods-repository). -- An TODS Contributor MAY vote in decisions on changes to the TODS spec and other aspects of TODS. - -## TODS Stakeholder - -Anyone interested in or could be directly affected by the TODS Project. Interested parties may register for the [TODS distribution list](https://groups.google.com/g/ods-working-group). - -## Document History - -### Initial Version - -- Initial release of the TODS Governance document. -- Establishment of governance principles, roles, policies, and procedures. diff --git a/docs/en/governance/policies/CLA.md b/docs/en/governance/policies/CLA.md deleted file mode 100644 index 21457ea4..00000000 --- a/docs/en/governance/policies/CLA.md +++ /dev/null @@ -1,13 +0,0 @@ -# Contributor License Agreement - -By making a contribution to this project, I certify that: - -> a. The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or -> -> b. The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or -> -> c. The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. -> -> d. I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. - -Attribution: This Contributor Agreement is adapted from the node.js project available here: . diff --git a/docs/en/governance/policies/board-composition.md b/docs/en/governance/policies/board-composition.md deleted file mode 100644 index 6c4b4fb1..00000000 --- a/docs/en/governance/policies/board-composition.md +++ /dev/null @@ -1,17 +0,0 @@ -# TODS Board Composition Policy - -In standing up and sustaining the TODS Board, the current [TODS Board][board]: - -- MUST decide the number of board positions; -- MUST select individuals to fill open board positions for three-year terms; -- SHOULD stagger board terms to avoid more than half the board turning over in any given year; -- SHOULD aim for geographic, demographic, and organizational diversity; and -- SHOULD aim for the majority of board members to come from transit agencies. - -Individuals serving on the [TODS Board][board]: - -- MUST serve as individuals, not organization representatives; -- SHOULD offer their resignation with significant professional changes, like switching industries; -- MAY be removed by a majority vote of the [TODS Board][board] for infractions including but not limited to not upholding the TODS Code of Conduct or their [TODS Board][board] responsibilities. - -[board]: ../governance.md#tods-board-of-directors diff --git a/docs/en/governance/policies/board-decisionmaking.md b/docs/en/governance/policies/board-decisionmaking.md deleted file mode 100644 index e88af17c..00000000 --- a/docs/en/governance/policies/board-decisionmaking.md +++ /dev/null @@ -1,26 +0,0 @@ -# TODS Board Decision Policy - -The [TODS Board][board] will be required to act from time-to-time in order to make official [TODS Project][project] decisions such as (but not limited to): - -- executing a memorandum of understanding ("MOU"), -- choosing the [TODS Manager][manager], and -- resolving stalemates in [TODS Change Management](change-management-versioning.md) process - -[TODS Board][board] Decisionmaking shall be subject to: - -- A vote MAY be called by any [TODS Board][board] member, the [TODS Board Coordinator][coordinator], or the [TODS Program Manager][program-manager] at any time. -- [TODS Board][board] decisions MUST be approved by two thirds of the non-abstaining members at the time of the vote. -- Voting MAY be done by email or other written form of communication. -- [TODS Board][board] members MAY abstain from any vote. -- [TODS Board][board] members MUST abstain from any vote where they have a direct conflict of interest where they would personally financially benefit; although they are encouraged to state their position on a topic at hand. - -## Governance Documentation - -The [TODS Board Coordinator][coordinator], MUST make sure all governance documents and TODS Board Decisions are up-to-date and stored in the [TODS Repository][repository]. - -[board]: ../governance.md#tods-board-of-directors -[manager]: ../governance.md#tods-manager -[coordinator]: ../governance.md#tods-board-coordinator -[repository]: ../governance.md#tods-repository -[program-manager]: ../governance.md#tods-program-manager -[project]: ../governance.md#tods-project diff --git a/docs/en/governance/policies/change-management-versioning.md b/docs/en/governance/policies/change-management-versioning.md deleted file mode 100644 index bf1cdb3a..00000000 --- a/docs/en/governance/policies/change-management-versioning.md +++ /dev/null @@ -1,205 +0,0 @@ -# TODS Versioning and Change Management Policy - -!!! tip - - When capitalized in this document, the words “MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" refer to their respective definitions in [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119). - -## Definitions - -!!! tip - - Definitions of various roles such as [TODS Board][board], [TODS Manager][manager], and [TODS Contributors][contributors] refer to their respective definitions in the [TODS Governance][governance]. - -The following definitions build on the overall [TODS Governance][governance] definitions and exist within the purpose of the TODS Versioning and Change Management Policy. - -### TODS Release - -An official version of the [TODS Specification][tods-spec] which can be referenced in perpetuity by a version number. The process by which a new release is made and determination of a version number is discussed below. - -Each change to normative content in the main branch of the TODS Repository MUST be considered a new release and assigned a version number. - -### Normative Content - -Normative Content is the prescriptive part of a standard. It sets the rules to be followed in order to be evaluated as compliant with the standard, and from which no deviation is permitted. - -### Non-Normative Content - -Non-normative content is the non-prescriptive, or ‘descriptive’, part of a standard. This may include analogies, synonyms, explanations, illustrations, context, and examples. In the event non-normative content contradicts normative content, the normative content is to be followed. - -### Issue Working Group - -Tasked by the [TODS Manager][manager] with resolving a specific issue with respect to the [TODS Specification][tods-spec]. - -### Urgent Needs - -Urgent needs MUST pose significant risks to security, compliance, or the operational integrity of stakeholder systems. These MAY include necessary revisions due to legal mandates, critical security vulnerabilities, or severe technical inaccuracies that directly impair system functionalities. Urgent needs SHOULD necessitate an implementation timeline which is inconsistent with the normal change-making process. - -## Change-Making Process - -This change-making process covers [all normative content changes](#normative-content) to the [TODS Specification][tods-spec] and occurs in the following stages: - -| Stage | When | Who (led by) | -|-----|-----|-----| -| Need Identification | Anytime | Anyone | -| Need Prioritization | At least annually | Contributors ([TODS Manager][manager]) | -| Initial Proposal Development | Prioritized quarter | Issue Working Group ([TODS Manager][manager]) | -| Contributor Review + Adoption | Pull request for proposed change submitted after consensus in the Working Group | Issue Working Group ([TODS Manager][manager]) | -| Implementation | When decision made to consensus achieved on proposal | Issue Working Group ([TODS Manager][manager]) | -| Released | Next release | [TODS Manager][manager] | - -Each of these stages is discussed in more detail below. - -### Need Identification - -Initiated when Any TODS Contributor identifies a need that should be addressed in the [TODS Specification][tods-spec]. - -Actions: - -* An TODS Contributor submits an issue to the TODS Repository which identifies the need that they would like addressed and a rough assessment of its addressable audience. -* An [TODS Manager][manager] triages issue and asks for more detail from the Contributor if needed. -* An [TODS Manager][manager] determines if issue resolution would require a normative change. - -Resolution: [TODS Manager][manager] puts issue into consideration for next issue prioritization - -### Prioritization - -Initiated when the [TODS Manager][manager] starts a development cycle after or near the end of a quarterly release. - -Actions: - -* [TODS Manager][manager] to solicit feedback from TODS Contributors on which needs to prioritize. -* [TODS Manager][manager] to propose a set of needs that the community will focus on resolving based on feedback and available community capacity. -* [TODS Board][board] will approve a set of needs to focus on based on [TODS Manager][manager]’s proposal and TODS Contributors’ feedback. - -Resolution: [TODS Manager][manager] will create a Milestone for the next release in the TODS Repository and fill it with the issues the [TODS Board][board] prioritized. - -### Initial Proposal Development - -Initiated [for each need] when [TODS Manager][manager], in consultation with the [TODS Board][board] and [TODS Contributors][contributors], convenes an Issue Working Group to address a prioritized issue or set of interrelated issues. - -Actions: - -* [TODS Manager][manager] convenes an Issue Working Group to develop a resolution to the issue. -Working Group members document discussion points about approach in the relevant github issue. -* While consensus will be sought, if the Issue Working Group members cannot come to a unanimous agreement about the solution, the [TODS Manager][manager] may ask the [TODS Board][board] to make a decision after hearing feedback from various perspectives. -* Issue Working Group members update the schema and documentation according to the proposal on a feature branch. - -Resolution: Issue Working Group submits a pull request to the develop branch. - -### Contributor Review + Adoption - -Initiated [for each need] when: [TODS Manager][manager] invites TODS Stakeholders outside of the Working Group to review and comment on the proposal - -Actions: - -* The [TODS Manager][manager] MUST invite people outside of the Working Group to review and comment on the proposal for a minimum of two weeks, making sure [TODS Contributors][contributors] with different roles and backgrounds have had a chance to consider it. -* The [TODS Manager][manager] MUST review the proposal for consistency with the [Open Standards](https://www.interoperablemobility.org/definitions) definition maintained by the [Mobility Data Interoperability Principles](https://interoperablemobility.org). -* The [TODS Manager][manager] MUST offer tools, services and assistance to any [TODS Contributor][contributors] who is unable to fluidly interact with the tooling used in the review process. -* A minimum of three [TODS Contributors][contributors] outside the Working Group MUST publicly comment on each proposal for it to move forward and indicate a score of: - * Accepted; - * Accepted with minor changes; or - * Substantially revised. -* If 100% of reviewers accept, the proposal is adopted without need for further discussion. -* If any reviewer accepts with minor changes, the suggested change must be considered by the Working Group. -* If the Working Group decides to incorporate the edited proposal will be re-circulated for some period time greater than 72 hours and previous reviewers notified. If nobody objects to the change in that time, it is adopted. -* If the Working Group does not agree with the suggested change, they may appeal to the [TODS Board][board] to make a final decision about its necessity. -* If any reviewer requests substantial changes, they must also agree to work with the working group on developing an alternative solution to the need. -* If the working group believes the substantial change request is invalid or without merit, they may appeal to the [TODS Board][board] to make a final decision about if revisions are necessary. - -Resolution: Change as represented in the pull request from the feature branch is approved and merged into the develop branch. - -### Full Implementation - -Initiated [for each need](#need-identification) when: Final change proposal is approved - although initial work can begin ahead of this. - -Actions: - -* [TODS Manager][manager] MUST ensure the relevant accompanying documentation fleshed out. -* [TODS Manager][manager] MUST ensure Changelog fully documented. -* [TODS Manager][manager] MUST ensure sample datasets updated or added that support the new feature. -* [TODS Manager][manager] MUST ensure any relevant updates to continuous integration and testing are completed. -* [TODS Manager][manager] MAY make any number of [pre-release(s)](#pre-releases). -* [TODS Manager][manager] MUST identify and ensure resolution of relevant conflicts among proposals as overseen by the [TODS Board][board] or their designee. - -Resolution: Requirements for [release](#releases) are met. - -### Release - -Initiated: On a schedule maintained by the [TODS Manager][manager], at least annually. - -Actions: See [Release Management](#releases). - -## Expedited Change Management - -This section outlines an expedited process for implementing changes in response to urgent needs which are critical to maintaining the security, compliance, or operational functionality of [TODS Specification][tods-spec] balancing rapid response with informed, transparent decision-making. - -### Process - -1. **Identification**: Stakeholders SHOULD promptly report urgent needs to the [TODS Manager][manager], detailing the problem and its potential impact. -2. **Rapid Evaluation**: The [TODS Manager][manager] MUST convene a group of at least 2 TODS Contributors of their choosing to swiftly assess the issue's urgency and validity. - * If it meets their threshold for an urgent need, they forward a list of their proposed Urgent Working Group Members to the [TODS Board][board]. - * The Urgent Working Group Members SHOULD contain representatives of TODS Contributors affected stakeholder groups. - * The Urgent Working Group size SHOULD be at least three and reflect the scale of the problem and also need for agile decision making. - * The [TODS Board][board] MAY object to their characterization of the need as urgent. - * The [TODS Board][board] MAY make changes to the Urgent Working Group members. - * If the [TODS Board][board] fails to respond within 48 hours, the Urgent Working Group MAY proceed with their implicit approval. -3. **Solution Identification**: The Urgent Working Group, managed by the [TODS Manager][manager], MUST identify a solution that meets the urgent need and document it as a PR to the `main` branch of the TODS Repository – outside the normal release cycle. -4. **Decision-Making**: A supermajority (two-thirds) of the Urgent Working Group members MUST approve the proposed change to meet the urgent need. If the decision is deadlocked, the decision is escalated to the [TODS Board][board]. -5. **Implementation**: The rest of the implementation and release cycle mirrors the main change-making process. - -## Versions and Release Management - -### Releases - -Each change to normative content in the main branch of the TODS Repository MUST be considered a new release and assigned a version number. - -* Each release MUST contain one or more changes to normative content which have been approved through the change-making process. -* Each release MUST be reviewed and approved in the TODS Repository by 2+ members of the [TODS Board][board], or their designees, for accuracy and consistency with the intent of the change. -* Each release MUST be tagged with its version number. -* Each release MUST have documentation available. -* Each release MUST have an entry in `CHANGELOG.md`. -* Each release MUST be specified as a release on Github. -* Each release MUST be noticed to any TODS mailing lists or discussion groups. -* Each release SHOULD have sample datasets (real or exemplary) which cover the normative changes in the release. - -#### Pre-releases - -Each approved change to normative content in the develop branch of the TODS Repository MAY be considered a pre-release and assigned a pre-release version number. - -* Pre-releases MAY be made in order to evaluate and work on incrementally-approved changes. -* Each pre-release MUST contain one or more changes to normative content which have been approved through the change-making process. -* Each pre-release MUST be reviewed and approved in GitHub by 1+ members of the [TODS Board][board], or their designees, for accuracy and consistency with the changes’ intent. -* Pre-releases MUST be tagged with an appropriate pre-release version number: - * Pre-releases that have incorporated all the normative changes for the target-release MUST have a beta version number; - * otherwise, they MUST receive an alpha version number. -* Each pre-release MUST have documentation available. -* Each pre-release MUST have an entry in `CHANGELOG.md`. -* Each pre-release MAY be specified as a pre-release on Github. - -### Release Schedule - -Barring significant unexpected events: - -* Major releases SHOULD be limited to no more than once per year; -* Minor releases MAY be expected at least annually. - -### Version Numbering - -TODS Releases MUST be reflected by an incremental version number based on a semantic versioning policy as detailed below. - -* Release versions MUST be named with incremental increases to the format `.` where: - * Major versions reflect backwards-incompatible changes - * Minor versions change the normative content in a way that is backwards-compatible - -Pre-release versions MUST be named with the `.` of their target release name and appended with either: -`-alpha.` where NUMBER starts at 1 and increases by 1 for each alpha release of that target release. -`-beta.` where NUMBER starts at 1 and increases by 1 for each beta release of that target release. - -Non-normative changes MUST NOT increment the TODS Version Number even though they are represented by updates in the `main` branch of the [TODS Repository][repository]. - -[governance]: ../governance.md -[tods-spec]: ../governance.md#tods-specification -[repository]: ../governance.md#tods-repository -[manager]: ../governance.md#tods-manager -[board]: ../governance.md#tods-board-of-directors -[contributors]: ../governance.md#tods-contributor diff --git a/docs/en/governance/policies/code-of-conduct.md b/docs/en/governance/policies/code-of-conduct.md deleted file mode 100644 index 9bdc2840..00000000 --- a/docs/en/governance/policies/code-of-conduct.md +++ /dev/null @@ -1,86 +0,0 @@ -# TODS Code of Conduct - -## Our Pledge - -We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, caste, color, religion, or sexual identity and orientation. - -We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community. - -## Our Standards - -Examples of behavior that contributes to a positive environment for our community include: - -* Demonstrating empathy and kindness toward other people -* Being respectful of differing opinions, viewpoints, and experiences -* Giving and gracefully accepting constructive feedback -* Accepting responsibility and apologizing to those affected by our mistakes, - and learning from the experience -* Focusing on what is best not just for us as individuals, but for the overall - community - -Examples of unacceptable behavior include: - -* The use of sexualized language or imagery, and sexual attention or advances of - any kind -* Trolling, insulting or derogatory comments, and personal or political attacks -* Public or private harassment -* Publishing others' private information, such as a physical or email address, without their explicit permission -* Other conduct which could reasonably be considered inappropriate in a - professional settin - -## Enforcement Responsibilities - -The community leaders for this effort include the TODS Manager and the TODS Board. - -Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful. - -Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate. - -## Scope - -This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official email address, posting via an official social media account, or acting as an appointed representative at an online or offline event. - -## Enforcement - -Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible for enforcement at [`odstransit@gmail.com`](mailto:odstransit@gmail.com). - -All complaints will be reviewed and investigated promptly and fairly. - -All community leaders are obligated to respect the privacy and security of the reporter of any incident. - -## Enforcement Guidelines - -Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct: - -### 1. Correction - -**Community Impact**: Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community. - -**Consequence**: A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested. - -### 2. Warning - -**Community Impact**: A violation through a single incident or series of actions. - -**Consequence**: A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban. - -### 3. Temporary Ban - -**Community Impact**: A serious violation of community standards, including sustained inappropriate behavior. - -**Consequence**: A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban. - -### 4. Permanent Ban - -**Community Impact**: Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals. - -**Consequence**: A permanent ban from any sort of public interaction within the community. - -## Attribution - -* This Code of Conduct is adapted from the TIDES Code of Conduct: https://github.com/TIDES-transit/TIDES/blob/main/CODE_OF_CONDUCT.md -* The TIDES Code of Conduct was in turn influenced by the following projects: -* Contributor Covenant version 2.1: https://www.contributor-covenant.org/version/2/1/code_of_conduct.html -* Mozilla's code of conduct enforcement ladder: https://github.com/mozilla/diversity -* For answers to common questions about this code of conduct, see the FAQ at: https://www.contributor-covenant.org/faq -* Translations are available at: https://www.contributor-covenant.org/translations diff --git a/docs/en/governance/policies/repository-organization-access.md b/docs/en/governance/policies/repository-organization-access.md deleted file mode 100644 index 37ec3c59..00000000 --- a/docs/en/governance/policies/repository-organization-access.md +++ /dev/null @@ -1,47 +0,0 @@ -# TODS Repository Organization Access Policy - -The [TODS Repository Organization][repository-organization], and its respective repositories and teams MUST be open and transparent to the general public to view and use under a permissive license. - -## Owners - -The following individuals MUST be invited as [TODS Repository Organization][repository-organization] owners: - -- Each [TODS Board][board] member -- [TODS Program Manager][program-manager] - -## Contributor-Level - -Contributor-level capabilities to the [TODS Repository][repository] shall be considered the ability to: - -- Create issues -- Add to discussions -- Create pull-requests -- Review pull-requests - -The [TODS Program Manager][program-manager] MUST invite the following individuals to have contributor-level capabilities: - -- [TODS Contributors][contributor] - -## Triage-Level - -Triage-level capabilities to the TODS Repository shall be considered the ability to to everything in contributor-level capabilities as well as: - -- Assignment of tags to issues -- Managing TODS Repository projects -- Assigning reviewers to pull requests -- Merging pull-requests that abide by branch policies -- Closing pull-requests -- Closing issues - -The [TODS Program Manager][program-manager] MAY invite the following individuals to have triage-level capabilities: - -- Additional individuals within the [TODS Manager][manager] organization; and -- [TODS Board Coordinator][board-coordinator], - -[program-manager]: ../governance.md#tods-program-manager -[manager]: ../governance.md#tods-manager -[board-coordinator]: ../governance.md#tods-board-coordinator -[repository]: ../governance.md#tods-repository -[repository-organization]: ../governance.md#tods-repository-organization -[contributor]: ../governance.md#tods-contributor -[board]: ../governance.md#tods-board-of-directors diff --git a/docs/en/index.md b/docs/en/index.md deleted file mode 100644 index 4247a41d..00000000 --- a/docs/en/index.md +++ /dev/null @@ -1,99 +0,0 @@ -# Transit Operational Data Standard - -The Transit Operational Data Standard (TODS) is an open standard for describing how to operate scheduled transit operations which can be used to port scheduled operations between software products (e.g. scheduling systems and CAD/AVL systems), agencies, and more. TODS leverages the existing General Transit Feed Specification (GTFS) and extends it to include information about personnel and non-revenue service. - -View the [full TODS specification](./spec/index.md). - -```mermaid -graph LR - subgraph Scheduling - I[Schedules] - M[Run Cutting] - N[Bidding/Driver Assignment] - M --> N - end - style Scheduling fill:#f4f1deff, stroke:#333, stroke-width:2px - style I fill:#BAE3CFff,stroke:#333,stroke-width:2px - style M fill:#BAE3CFff,stroke:#333,stroke-width:2px - style N fill:#BAE3CFff,stroke:#333,stroke-width:2px - - P[GTFS Schedule] - S[TODS] - style P fill:#F4D39Fff,stroke:#333,stroke-width:2px - style S fill:#F4D39Fff,stroke:#333,stroke-width:2px - - subgraph Operations - R[Dispatch] - end - style Operations fill:#f4f1deff, stroke:#333, stroke-width:2px - style R fill:#BAE3CFff,stroke:#333,stroke-width:2px - - I --> P - P --> R - I -->|Vehicle Blocks| M - N --> S - S --> R - linkStyle 3 stroke:#F4D39Fff,stroke-width:4px,stroke-dasharray: 5, 5 - linkStyle 4 stroke:#F4D39Fff,stroke-width:4px,stroke-dasharray: 5, 5 - -``` - -## Motivation - -Transit providers need the systems they use to schedule and operate their service to be [interoperable](https://www.interoperablemobility.org/) so that they have the flexibility to use various software products and exchange information with other transit operators. Interoperability is best achieved through open standards. The [GTFS](https://gtfs.org) open standard successfully transmits information useful to transit riders, but is missing key concepts that are necessary for transit providers to operate the service. TODS fills this gap. - -TODS is an open standard which extends GTFS to define additional operational details necessary to operate the service such as deadheads and runs. - -!!! warning "Does TODS Data have to be Open data?" - - While GTFS data can and should be public so that riders can learn about service, TODS data is typically not published in order to preserve the privacy of internal operations data. - - While the TODS standard itself is an "open standard", this doesn't necessitate the data described in TODS to be open. - -## Who uses TODS? - -TODS is used by transit agencies and the software which supports them including: - -### TODS 2.0+ - -:material-check-circle: [Optibus](https://optibus.com/) - -:material-check-circle-outline: [MBTA](http://mbta.com) (in progress) - -:material-check-circle-outline: [Keolis Commuter Services](https://www.keolisna.com/locations/boston-massachusetts) (in progress) - -### TODS 1.0 - -:material-check-circle: [WETA](https://weta.sanfranciscobayferry.com/) - -:material-check-circle: [Swiftly](https://www.goswift.ly/) - -:material-check-circle: [Equans Navineo](https://navineo.co/about-navineo/) - -:material-check-circle: [The Master Scheduler](https://themasterscheduler.com/) - -:material-check-circle: [Remix by Via](https://www.remix.com/) - -:material-check-circle: [Optibus](https://optibus.com/) - -:material-check-circle-outline: [Giro Hastus](https://www.giro.ca/) (on request) - -## How do I implement TODS? - -If you are transit agency: - -1. Talk to your current Scheduling and CAD/AVL vendors or -2. Include a requirement to use TODS in your next procurement. The Mobility Data Interoperability Principles has sample text for adding TODS and other key interoperability features as RFP requirements in their [Interoperable Procurement Resource](https://www.interoperablemobility.org/procurement/). - -If you are vendor: - -1. Review the [specification](./spec/index.md) and -2. Create an development roadmap to adopting it. - -Most vendors already read and write to GTFS, so this should be a marginal lift to implement. - -## Citation - -If you use the Transit Operational Data Standard in a report or article, please cite it as follows: - -> Transit Operational Data Standard Working Group. 2022. Transit Operational Data Standard. Transit Operational Data Standard Board of Directors. https://ods.calitp.org. diff --git a/docs/en/resources/assets/2026-01-12_KesslerJeff_(Keolis)_[P26-20294]_The_Journey_of_TODS.pdf b/docs/en/resources/assets/2026-01-12_KesslerJeff_(Keolis)_[P26-20294]_The_Journey_of_TODS.pdf deleted file mode 100644 index c785a89b..00000000 Binary files a/docs/en/resources/assets/2026-01-12_KesslerJeff_(Keolis)_[P26-20294]_The_Journey_of_TODS.pdf and /dev/null differ diff --git a/docs/en/resources/faq.md b/docs/en/resources/faq.md deleted file mode 100644 index 0bb2284e..00000000 --- a/docs/en/resources/faq.md +++ /dev/null @@ -1,45 +0,0 @@ -# Frequently Asked Questions - -## What is "operational data?" - -Operational data refers to everything a transit provider needs to know "behind the scenes" in order to provide service to riders. Operational data can include the following information: - -* Vehicle blocking (which vehicles run which routes) -* Driver shift management (which vehicle operators work on which routes) -* Vehicle shift start/end time and location (when and where vehicles pull in and out of service) -* Nonrevenue vehicle service (deadheading) -* Service disruptions - -## Why is a standard for operational data needed? - -Operational data is critical for transit providers, but currently it exists primarily in proprietary formats created and maintained by various scheduling and CAD/AVL companies. The use of proprietary formats leads to wide disparities in the experiences that agencies have in trying to create a schedule and then utilizing that schedule in a CAD/AVL software. Agencies often find that their CAD/AVL and scheduling vendors prepare data in different formats, or they use different nomenclature to refer to route and stop names, which results in time-consuming manual processes to align incompatible data sources. - -The availability of information in the GTFS standard format has not only resulted in better information being available to riders, but it has also led to innovation in features and functionality for use by transit providers themselves. Similarly, creating a standard format for operational data will help transit providers with easier, less expensive, and enhanced scheduling functionality. - -## Isn’t operational data already covered by … GTFS? - -Not entirely. GTFS provides what can be thought of as a rider-centric view of transit service. By that, we mean it is built around trip (or journey) planning and the information that riders need to know to complete a trip. While GTFS contains information about where vehicles should be at specified times, most transit agencies could not determine where a specific driver or operator should be at that time using a standard GTFS feed. Critical information for operators—for example, which driver is scheduled to serve a given trip, when and where to layover, or how deadheads should be completed—is not included in GTFS at present. But just because GTFS doesn’t get us all the way there, that doesn’t mean we are planning to start from scratch: TODS is intended to work with GTFS and could ultimately be developed as an extension to GTFS. - -## Isn’t operational data already covered by … NeTEx/SIRI? - -Yes. The Network Timetable Exchange, or NeTEx, does cover use cases that are being considered for use in TODS. However, because NeTEx has no foothold in the North American market, a major, coordinated about-face in the industry would be required to move toward the NeTEx/SIRI schema. While NeTEx is one way to represent the operational data that makes up transit schedules, it is neither the only nor even necessarily the easiest way to do so. GTFS is the dominant standard in use for defining transit trips in North America, and research by the California Integrated Travel Project (Cal-ITP) has found that vendors favor GTFS’s flexible and simpler approach to representing transit data. Given the shifts that would need to occur within the industry to move toward NeTEx, Cal-ITP is privileging compatibility with GTFS and taking a GTFS-like approach to developing TODS. - -## Isn’t operational data already covered by … TCIP? - -Yes. The Transit Communications Interface Profiles (TCIP) is a standard developed by the American Public Transportation Association approximately 20 years ago to serve as a standard interface between transit systems and the individual subsystems, like scheduling and CAD/AVL, that they rely on. TCIP has never achieved significant adoption in the United States or elsewhere and has been surpassed by the popularity of the simpler and more constrained GTFS family of standards. Without adoption, development of TCIP has not kept pace with extensions and proposed extensions of GTFS, nor with broader changes in the mobility landscape as a whole. Given the shifts that would need to occur within the industry to move toward TCIP, Cal-ITP is privileging compatibility with GTFS and taking a GTFS-like approach to developing TODS. - -## What is Cal-ITP? - -Cal-ITP is a statewide initiative of the California State Transportation Agency (CalSTA) and the California Department of Transportation (Caltrans) to simplify travel by increasing access to public transportation—including easier, faster payments via contactless credit/debit/prepaid cards and mobile wallets on smart devices, high-quality data standards, and seamless verification of eligibility for transit discounts. Learn more at [calitp.org](https://www.calitp.org/). And visit Cal-ITP's [CAMobilityMarketplace.org](https://www.camobilitymarketplace.org/) for a catalog of code-compliant products and services for transit agencies. - -## What is the TODS Working Group? - -The Transit Operational Data Standard working group was convened by staff from the California Integrated Travel Project (Cal-ITP) as part of its goal to provide complete, accurate, and up-to-date transit data to customers and respective agencies. Working group members include major transit agencies across the United States and many of the largest transit software companies in North America. Visit our [Working Group page](../resources/faq.md#what-is-the-tods-working-group) for a full list of members. - -## Why is Cal-ITP leading this effort? - -Cal-ITP developed the TODS initiative in response to feedback from local transit providers and vendors. As Cal-ITP has as its core a mission to improve the quality of mobility data and increase the efficiency of transportation service delivery in the state of California, we have conducted research and conversations with an eye toward identifying existing pain points. The gap that exists between scheduling software and CAD/AVL software was identified by respondents as a major source of friction. Even as GTFS has seen increasingly widespread adoption, operational data is subject to proprietary formats, overlapping use cases, and manual processes that inefficiently transfer data from one system to another. Cal-ITP’s conversations with partners have demonstrated that there is a clear desire among vendors and transit providers to come together around a standard representation of operational data built in the GTFS model. - -## Have more questions? - -For additional information, please email us at [tods@mobilitydata.org](mailto:tods@mobilitydata.org). diff --git a/docs/en/resources/implementation-guide.md b/docs/en/resources/implementation-guide.md deleted file mode 100644 index 42f937a1..00000000 --- a/docs/en/resources/implementation-guide.md +++ /dev/null @@ -1,3 +0,0 @@ -# TODS Implementation Guide - -Forthcoming. diff --git a/docs/en/resources/resources.md b/docs/en/resources/resources.md deleted file mode 100644 index 27872cf4..00000000 --- a/docs/en/resources/resources.md +++ /dev/null @@ -1,13 +0,0 @@ -# Handouts + Presentations - -## From Unmet Need to New Data Standard: The Journey of TODS - -

Jeff Kessler, Director of Innovation @ Keolis Commuter Services

-
AP017 Member & TODS Board Member
- -PDF Preview - - - PDF - Download PDF - \ No newline at end of file diff --git a/docs/en/resources/upcoming-engagements.md b/docs/en/resources/upcoming-engagements.md deleted file mode 100644 index 7e4c2bc2..00000000 --- a/docs/en/resources/upcoming-engagements.md +++ /dev/null @@ -1,17 +0,0 @@ -# Upcoming Engagements - -

Representatives of the TODS project are expecting to attend:

- -

2026

- -* 2026-06-23/25 — [TransitData 2026](https://www.transitdata2026.ca/) — _Toronto, Ontario, Canada_ -* 2026-08-09/12 — [APTAtech](https://www.cgi.com/us/en-us/event/cgi-advantage/aptatech) — _St. Louis, Missouri, United States of America_ -* 2026-09-22/23 — [International Mobility Data Summit](https://mobilitydata.org/2026-international-mobility-data-summit/) — _Montreal, Quebec, Canada_ -* 2026-10-04/07 — [APTA TRANSform](https://www.aptaexpo.com/) — _Chicago, Illinois, United States of America_ -* 2026-10-TBA — [TransportationCamp NYC](https://transportationcamp.org/) — _Brooklyn, New York, United States of America_ -* 2026-10-TBA — [TransportationCamp New England](https://transportationcamp.org/) — _Boston, Massachusetts, United States of America_ - -

2027

- -* 2027-01-10 — [TransportationCamp DC](https://transportationcamp.org/) — _Washington, D.C., United States of America_ -* 2027-01-11/15 — [TRBAM](https://www.nationalacademies.org/events/886) — _Washington, D.C., United States of America_ \ No newline at end of file diff --git a/docs/en/spec/examples.md b/docs/en/spec/examples.md deleted file mode 100644 index e8dea548..00000000 --- a/docs/en/spec/examples.md +++ /dev/null @@ -1,384 +0,0 @@ -# Examples - -The following sections provide examples of how TODS can represent specific use cases. The inclusion of these examples should not -be as an indication that this is the only way to represent these use cases with TODS. If you have questions about a use case not -represented here, please feel free to [create an issue in GitHub](https://github.com/cal-itp/operational-data-standard/issues/new). - -## Single Run with Pull-Out and Lunch Break - -In this example, a bus driver is assigned to run 10000, which has four revenue trips on two pieces, all on the same block. The run also includes a pull-out, a pull-back, a pre-trip inspection, and a lunch break between the two pieces. - -![Diagram showing four trips, two deadheads, and other events.](examples/single-run-diagram.png) - -### GTFS Files - -These are the same files that would be published in the agency's public GTFS file, and contains only revenue trips and public information. - -Some irrelevant files are ommitted for brevity. - -#### `stops.txt` - -```csv -stop_id,location_type -stop-1,0 -stop-2,0 -stop-3,0 -``` - -#### `routes.txt` - -```csv -route_id,route_short_name,route_type -12,12,3 -``` - -#### `trips.txt` - -```csv -route_id,service_id,trip_id,trip_headsign,direction_id,block_id -12,daily,101,North,0,BLOCK-A -12,daily,102,South,1,BLOCK-A -12,daily,103,North,0,BLOCK-A -12,daily,104,South,1,BLOCK-A -``` - -#### `stop_times.txt` - -```csv -trip_id,arrival_time,stop_id,stop_sequence -101,10:00,stop-1,1 -101,10:25,stop-2,2 -101,10:50,stop-3,3 -102,11:00,stop-3,1 -102,11:25,stop-2,2 -102,11:50,stop-1,3 -103,13:00,stop-1,1 -103,13:25,stop-2,2 -103,13:50,stop-3,3 -104,14:00,stop-3,1 -104,14:25,stop-2,2 -104,14:50,stop-1,3 -``` - -### TODS Files - -These are the new files that are published in TODS. In this example, the TODS files do not delete or modify any rows that were published in GTFS. - -#### `stops_supplement.txt` - -```csv -stop_id,location_type,TODS_location_type -garage,0,garage -garage-waypoint,0, -``` - -#### `routes_supplement.txt` - -```csv -route_id,route_long_name -deadheads,Deadheads -``` - -In this example, the agency puts all of its deadheads on this new route, though agencies may have other ways to assign deadheads to routes. - -#### `trips_supplement.txt` - -```csv -route_id,service_id,trip_id,block_id,TODS_trip_type -deadheads,daily,deadhead-1,BLOCK-A,pull-out -deadheads,daily,deadhead-2,BLOCK-A,pull-back -``` - -In this example, consumers know that these trips aren't in revenue service because of the `route_id` and `TODS_trip_type`. - -#### `stop_times_supplement.txt` - -```csv -trip_id,arrival_time,stop_id,stop_sequence -deadhead-1,09:45:00,garage,1 -deadhead-1,09:50:00,garage-waypoint,2 -deadhead-1,09:55:00,stop-1,3 -deadhead-2,14:50:00,stop-1,1 -deadhead-2,14:55:00,garage-waypoint,2 -deadhead-2,15:00:00,garage,3 -``` - -#### `run_events.txt` - -```csv -service_id,run_id,event_sequence,piece_id,block_id,job_type,event_type,trip_id,start_location,start_time,start_mid_trip,end_location,end_time,end_mid_trip -daily,10000,10, , ,Operator,Report Time, ,garage,09:30:00,,garage,09:30:00, -daily,10000,20, , ,Operator,Pre-Trip Inspection,,garage,09:35:00,,garage,09:45:00, -daily,10000,30,10000-1,BLOCK-A,Operator,Pull-Out,deadhead-1 ,garage,09:45:00,2,stop-1,09:55:00,2 -daily,10000,40,10000-1,BLOCK-A,Operator,Operator,101 ,stop-1,10:00:00,2,stop-3,10:50:00,2 -daily,10000,50,10000-1,BLOCK-A,Operator,Operator,102 ,stop-3,11:00:00,2,stop-1,11:50:00,2 -daily,10000,60, , ,Operator,Break, ,stop-1,11:50:00,,stop-1,13:00:00, -daily,10000,70,10000-2,BLOCK-A,Operator,Operator,103 ,stop-1,13:00:00,2,stop-3,13:50:00,2 -daily,10000,80,10000-2,BLOCK-A,Operator,Operator,104 ,stop-3,14:00:00,2,stop-1,14:50:00,2 -daily,10000,90,10000-2,BLOCK-A,Operator,Pull-Back,deadhead-2,stop-1,14:50:00,2,garage,15:00:00,2 -``` - -## Multiple Runs on a Single Block with Mid-Trip Relief - -In this example, the bus driver assigned to run 10000 pulls out a bus, does trip 101 and part of trip 102, and then ends their day at `stop-2`. A new driver on run 20000 boards the bus, completes trip 102, then does trip 103 and trip 104, and pulls back to the garage. - -![Diagram showing four trips, with the second trip broken into two different assignments.](examples/mid-trip-relief-diagram.png) - -This example uses the [exact same GTFS files as the previous example](#gtfs-files). Deadheads and nonrevenue locations are omitted in order to focus on the revenue trip assignments, so no `_supplement.txt` files are needed for this example. Only `run_events.txt` needs to change to reflect the multiple runs and mid-trip relief. - -### `run_events.txt` - -```csv -service_id,run_id,event_sequence,piece_id,block_id,job_type,event_type,trip_id,start_location,start_time,start_mid_trip,end_location,end_time,end_mid_trip -daily,10000,10,10000-1,BLOCK-A,Operator,Operator,101,stop-1,10:00:00,2,stop-3,10:50:00,2 -daily,10000,20,10000-1,BLOCK-A,Operator,Operator,102,stop-3,11:00:00,2,stop-2,11:25:00,1 -daily,20000,10,20000-1,BLOCK-A,Operator,Operator,102,stop-2,11:25:00,1,stop-1,11:50:00,2 -daily,20000,20,20000-1,BLOCK-A,Operator,Operator,103,stop-1,13:00:00,2,stop-3,13:50:00,2 -daily,20000,30,20000-1,BLOCK-A,Operator,Operator,104,stop-3,14:00:00,2,stop-1,14:50:00,2 -``` - -## Multiple operators on the same trip - -In this example (unrelated to the previous examples), a two-car train does a round trip, and requires two operators, one in the first car and one in the second car. The `event_type` field distinguishes whether an operator is in the front car or the rear car. The operators swap for the return trip. - -### `run_events.txt` - -```csv -service_id,run_id,event_sequence,job_type,event_type,trip_id,start_location,start_time,end_location,end_time -weekday,10000,10,Operator,Operate 1st Car,trip-1,stop-1,10:00:00,stop-2,10:58:00 -weekday,10000,20,Operator,Operate 2nd Car,trip-2,stop-2,11:00:00,stop-1,11:58:00 -weekday,20000,10,Operator,Operate 2nd Car,trip-1,stop-1,10:00:00,stop-2,10:58:00 -weekday,20000,20,Operator,Operate 1st Car,trip-2,stop-2,11:00:00,stop-1,11:58:00 -``` - -## Run as Directed work - -In this example (unrelated to the previous examples), an operator signs in for their shift, pulls out, and then operates a bus for several hours. They are not scheduled to do specific trips, but instead do trips as directed to by dispatch. This approach could apply in several situations: - -- An agency uses `frequencies.txt` (`frequencies.trip_id` may be able to be referenced in `run_events.trip_id`). -- An agency publishes specific times in GTFS `trips.txt`, but in practice operates the service according to a headway, or doesn't schedule operators to specific trips. -- The operator is assigned to cover or strategic work, and is positioned somewhere where they can cover absences or gaps in service on any route throughout the day. - -### `run_events.txt` - -```csv -service_id,run_id,event_sequence,block_id,event_type,trip_id,start_location,start_time,end_location,end_time -weekday,10000,10, ,sign-in ,,garage,08:45:00,garage,08:50:00 -weekday,10000,20,BLOCK-A,deadhead ,,garage,08:50:00,stop-1,09:00:00 -weekday,10000,30,BLOCK-A,run-as-directed,,stop-1,09:00:00,stop-1,12:00:00 -weekday,10000,40,BLOCK-A,deadhead ,,stop-1,12:00:00,garage,12:10:00 -``` - -## Jobs of entirely nonrevenue operations - -An overnight track inspection train operates once per week, with a separate crew. It's scheduled and operated separately from other service, so is given its own service ID separate from any trips in the public GTFS file. In this example, the route and stops are assumed to be defined in the public GTFS. - -### `calendar_supplement.txt` - -```csv -service_id,monday,tuesday,wednesday,thursday,friday,saturday,sunday,start_date,end_date -inspection_train,0,0,0,0,0,0,1,20240601,20241231 -``` - -### `trips_supplement.txt` - -```csv -route_id,service_id,trip_id,TODS_trip_type,direction_id -line1,inspection_train,inspection_line1_ob,deadhead,0 -line1,inspection_train,inspection_line1_ib,deadhead,1 -``` - -### `stop_times_supplement.txt` - -```csv -trip_id,stop_id,arrival_time -inspection_line1_ob,downtown,24:00:00 -inspection_line1_ob,anytown,24:45:00 -inspection_line1_ib,anytown,25:00:00 -inspection_line1_ib,downtown,25:45:00 -``` - -### `run_events.txt` - -This file references the service ID and trip ID defined in the other supplement files. - -```csv -service_id,run_id,event_sequence,event_type,trip_id,start_location,start_time,end_location,end_time -inspection_train ,1 ,1 ,sign-in , ,main_terminal ,23:45:00 ,main_terminal ,23:45:00 -inspection_train ,1 ,2 ,operator ,inspection_line1_ob ,downtown ,24:00:00 ,anytown ,24:45:00 -inspection_train ,1 ,3 ,operator ,inspection_line1_ib ,anytown ,25:00:00 ,downtown ,25:45:00 -inspection_train ,1 ,4 ,sign-off , ,main_terminal ,26:00:00 ,main_terminal ,26:00:00 -``` - -## Distinct Crew and Trip schedule scenarios - -These examples show situations where the crew schedules in `run_events.txt` use different service IDs than the trips they work on, as is allowed by [the spec](index.md#service_id-crew-schedules-and-trip-schedules). Most agencies will not need to model a situation like this. - -In all these cases, the trips and service IDs in the public GTFS file are not modified. New service IDs are created in the calendar supplement files, and runs that operate on those dates are described in `run_events.txt`. - -### Extra staffing for a special event - -Due to a baseball game, an additional ticket collector will be assigned to supplement the existing crew on train 101, serving the ballpark. - -#### `calendar.txt` - -```csv -service_id,monday,tuesday,wednesday,thursday,friday,saturday,sunday,start_date,end_date -weekday,1,1,1,1,1,0,0,20240101,20241231 -``` - -#### `trips.txt` - -```csv -route_id,service_id,trip_id,block_id -route,weekday,101,BLOCK-A -``` - -#### `calendar_dates_supplement.txt` - -```csv -service_id,date,exception_type -gameday,20240820,1 -gameday,20240821,1 -gameday,20240827,1 -gameday,20240903,1 -``` - -#### `run_events.txt` - -```csv -service_id,run_id,event_sequence,block_id,job_type,event_type,trip_id,start_location,start_time,end_location,end_time -weekday,1,1, ,collector,sign-in , ,main_terminal,14:00:00,main_terminal,14:15:00 -weekday,1,2,BLOCK-A,collector,collector ,101,main_terminal,14:45:00,ballpark ,15:30:00 -gameday,2,1, ,collector,sign-in , ,main_terminal,14:00:00,main_terminal,14:15:00 -gameday,2,2,BLOCK-A,collector,extra collector,101,main_terminal,14:45:00,ballpark ,15:30:00 -``` - -### Trip worked by different runs on different dates - -Consider a bus network between West City, Eastland, and Northingdon. Route 1 runs between West City and Eastland via Northingdon, whereas Route 2 runs directly between the two cities. - -To lengthen a short layover and improve on-time performance, the driver working the 10:45am Route 1 departure and the driver of the 11am Route 2 departure will exchange these trips effective September 2024. - -The public-facing schedule will not change. The trips remain on the service `weekday`. The runs are scheduled on new services `summer` and `fall`, which together cover all of the dates in `weekday`. - -![Diagram showing four trips on two runs, with the assignments rearranged in the fall.](examples/different-runs-same-trips.png) - -#### `calendar.txt` - -```csv -service_id,monday,tuesday,wednesday,thursday,friday,saturday,sunday,start_date,end_date -weekday,1,1,1,1,1,0,0,20240601,20241231 -``` - -#### `trips.txt` - -```csv -route_id,service_id,trip_id,trip_headsign,direction_id -1,weekday,101,Eastland via Northingdon,1 -2,weekday,201,Eastland,1 -1,weekday,102,West City via Northingdon,0 -2,weekday,202,West City,0 -``` - -#### `calendar_supplement.txt` - -To detail the presence of the new `service_id`s and assign them to their applicable days of the week, the runs can be added to the calendar via `calendar_supplement.txt`: - -```csv -service_id,monday,tuesday,wednesday,thursday,friday,saturday,sunday,start_date,end_date -summer,1,1,1,1,1,0,0,20240601,20240831 -fall ,1,1,1,1,1,0,0,20240901,20241231 -``` - -#### `run_events.txt` - -The current runs can be modeled with service_id `summer`, and mapped to the existing `weekday` trips. The future runs can be modeled with service_id `fall`, also mapped to the existing `weekday` trips. The service_id `weekday` is already defined in `calendar.txt`, but neither `summer` nor `fall` are. - -```csv -service_id ,run_id ,event_sequence ,block_id ,event_type ,trip_id ,start_location ,start_time ,end_location ,end_time -summer ,1 ,20 ,A ,drive ,101 ,westcity ,09:00:00 ,eastland ,10:30:00 -summer ,1 ,30 ,A ,drive ,102 ,eastland ,10:45:00 ,westcity ,12:15:00 - -summer ,2 ,20 ,B ,drive ,201 ,westcity ,09:00:00 ,eastland ,10:00:00 -summer ,2 ,30 ,B ,drive ,202 ,eastland ,11:00:00 ,westcity ,12:00:00 - -fall ,1 ,20 ,A ,drive ,101 ,westcity ,09:00:00 ,eastland ,10:30:00 -fall ,1 ,30 ,A ,drive ,202 ,eastland ,11:00:00 ,westcity ,12:00:00 - -fall ,2 ,20 ,B ,drive ,201 ,westcity ,09:00:00 ,eastland ,10:00:00 -fall ,2 ,30 ,B ,drive ,102 ,eastland ,10:45:00 ,westcity ,12:15:00 -``` - -(In this example, block IDs are listed in `run_events.txt` but not `trips.txt` because the blocks would also change with the schedule change.) - -## Vehicle Assignments - -Vehicles are assigned by service date. In this example, vehicle assignments are provided for 3 consecutive days from February 5 through 7. - -### `vehicles.txt` - -```csv -vehicle_id,vehicle_label,license_plate -bus-1,Old Reliable,OR-E285104 -bus-2,Buster,OR-E251432 -``` - -### `vehicle_assignments.txt` - -```csv -date,service_id,block_id,vehicle_id -20250205,daily,BLOCK-A,bus-1 -20250206,daily,BLOCK-A,bus-2 -20250207,daily,BLOCK-A,bus-1 -``` - -## Employee Assignments - -This example uses [`employee_run_dates.txt`](index.md#employee_run_datestxt) to assign employees to runs (and trips). - -In this example, `A` and `B` work Monday-Wednesday and Sunday. `C` and `D` work Thursday-Saturday. - -On Wedneday, July 3, `A` has scheduled vacation, so a substitute is assigned instead. - -**[`calendar.txt`](https://gtfs.org/documentation/schedule/reference/#calendartxt)** - -```csv -service_id,monday,tuesday,wednesday,thursday,friday,saturday,sunday,start_date,end_date -weekday,1,1,1,1,1,0,0,20240701,20240707 -weekend,0,0,0,0,0,1,1,20240701,20240707 -``` - -July 1, 2024 was a Monday. - -**[`run_events.txt`](index.md#run_eventstxt)** - -For this example, the purpose of this file is just to show which runs exist. Real runs would have more interesting data. - -```csv -service_id,run_id,event_sequence,event_type,trip_id,start_location,start_time,end_location,end_time -weekday,101,1,work,trip1,station,09:00:00,station,17:00:00 -weekday,102,1,work,trip2,station,09:00:00,station,17:00:00 -weekend,103,1,work,trip3,station,09:00:00,station,17:00:00 -weekend,104,1,work,trip4,station,09:00:00,station,17:00:00 -``` - -**[`employee_run_dates.txt`](index.md#employee_run_datestxt)** - -```csv -date,service_id,run_id,employee_id -20240701,weekday,101,A -20240701,weekday,102,B -20240702,weekday,101,A -20240702,weekday,102,B -20240703,weekday,101,A -20240703,weekday,102,B -20240704,weekday,101,C -20240704,weekday,102,D -20240705,weekday,101,C -20240705,weekday,102,D -20240706,weekend,103,C -20240706,weekend,104,D -20240707,weekend,103,A -20240707,weekend,104,B -``` diff --git a/docs/en/spec/examples/different-runs-same-trips.png b/docs/en/spec/examples/different-runs-same-trips.png deleted file mode 100644 index d2d662c3..00000000 Binary files a/docs/en/spec/examples/different-runs-same-trips.png and /dev/null differ diff --git a/docs/en/spec/examples/mid-trip-relief-diagram.png b/docs/en/spec/examples/mid-trip-relief-diagram.png deleted file mode 100644 index a0fdf722..00000000 Binary files a/docs/en/spec/examples/mid-trip-relief-diagram.png and /dev/null differ diff --git a/docs/en/spec/examples/single-run-diagram.png b/docs/en/spec/examples/single-run-diagram.png deleted file mode 100644 index 91e900ef..00000000 Binary files a/docs/en/spec/examples/single-run-diagram.png and /dev/null differ diff --git a/docs/en/spec/index.md b/docs/en/spec/index.md deleted file mode 100644 index a894528a..00000000 --- a/docs/en/spec/index.md +++ /dev/null @@ -1,209 +0,0 @@ - -# Reference - -The Transit Operational Data Standard was last updated on 2025-04-16 (v2.1.0). View the full [revision history](./revision-history.md). - -## Dataset Files - -### Structure - -There are two types of files used in the TODS standard: - -- **Supplement files**, used to add, modify, and delete information from public GTFS files to model the operational service for internal purposes (with a `_supplement` filename suffix). -- **TODS-Specific files**, used to model operational elements not currently defined in the GTFS standard. - -All files are optional. - -### Files - -| **File Name** | **Type** | **Description** | -| --- | --- | --- | -| trips_supplement.txt | Supplement | Supplements and modifies GTFS [trips.txt](https://github.com/google/transit/blob/master/gtfs/spec/en/reference.md#tripstxt) with deadheads and other non-public trip information. | -| stops_supplement.txt | Supplement | Supplements and modifies GTFS [stops.txt](https://github.com/google/transit/blob/master/gtfs/spec/en/reference.md#stopstxt) with internal stop locations, waypoints, and other non-public stop information.| -| stop_times_supplement.txt | Supplement | Supplements and modifies GTFS [stop_times.txt](https://github.com/google/transit/blob/master/gtfs/spec/en/reference.md#stop_timestxt) with non-public times at which trips stop at locations, `stop_times` entries for non-public trips, and related information. | -| routes_supplement.txt | Supplement | Supplements and modifies GTFS [routes.txt](https://github.com/google/transit/blob/master/gtfs/spec/en/reference.md#routestxt) with internal route identifiers and other non-public route identification. | -| calendar_supplement.txt | Supplement | Supplements and modifies GTFS [calendar.txt](https://github.com/google/transit/blob/master/gtfs/spec/en/reference.md#calendartxt) to adjust days for which existing `service_id`s are in effect, and add additional `service_id`s where crew and/or deadhead information is distinct from revenue trips. | -| calendar_dates_supplement.txt | Supplement | Supplements and modifies GTFS [calendar_dates.txt](https://github.com/google/transit/blob/master/gtfs/spec/en/reference.md#calendar_datestxt) to adjust dates for which existing `service_id`s are in effect, and add additional `service_id`s where crew and/or deadhead information is distinct from revenue trips. | -| run_events.txt | TODS-Specific | Lists all trips and other scheduled activities to be performed by a member of personnel during a run. | -| employee_run_dates.txt | TODS-Specific | Assigns employees to runs. | -| vehicles.txt | TODS-Specific | Lists fleet vehicles with attributes for reference in `vehicle_assignments.txt` | -| vehicle_assignments.txt | TODS-Specific | Assign vehicles to trips by `service_id` and `block_id`. | - -_The use of the Supplement standard to modify other GTFS files is not yet formally adopted into the specification and remains subject to change. Other files may be formally adopted in the future._ - -## Supplement Files - -### Structure - -The fields in all Supplement files match those defined in the corresponding file's [GTFS specification](https://github.com/google/transit/blob/master/gtfs/spec/en/reference.md). - -The overall premise is to update and add data to GTFS, which is accomplished by either updating matching values or adding rows entirely. - -Each entry in a Supplement file is paired with its matching entry in the corresponding GTFS file using the [GTFS file's Primary Key](https://gtfs.org/schedule/reference/#dataset-attributes), i.e. the fields that uniquely identify the row. If no match is found, the Supplement file's entry is added to the GTFS file in its entirety. - -The standard also supports the removal of rows in their entirety. - -### Evaluation - -Each row in a Supplement file shall be evaluated as follows: - -1. If the row's Primary Key is defined in the corresponding GTFS file, and the `TODS_delete` field is defined and equal to `1`, remove the corresponding row from the GTFS file. -2. If the row's Primary Key is defined in the corresponding GTFS file, and the `TODS_delete` field is not defined or not equal to `1`, set or update any fields with defined values in the Supplement file to those values in the corresponding GTFS file. -3. If the row's Primary Key is NOT defined in the corresponding GTFS file, add the row to the corresponding GTFS file. - -In other words, where a Primary Key matches, the row is either removed or any non-empty values in the row are used to _update_ the corresponding GTFS values. Where a Primary Key match does not exist, the entire row is added. - -### Example - -GTFS `stops.txt`: - -```csv -stop_id,stop_name,stop_desc,stop_url -1,One,Unmodified in TODS,example.com/1 -2,Two,Deleted in TODS,example.com/2 -3,Three,Will be modified in TODS,example.com/3 -``` - -TODS `stops_supplement.txt`: - -```CSV -stop_id,stop_name,stop_desc,TODS_delete -2,,,1 -3,,Has been modified by TODS, -4,Four,New in TODS, -``` - -Effective `stops.txt` after merging the supplement file: - -```CSV -stop_id,stop_name,stop_desc,stop_url -1,One,Unmodified in TODS,example.com/1 -3,Three,Has been modified by TODS,example.com/3 -4,Four,New in TODS, -``` - -_Note that the station name "Three" was not modified, and the whole column stop_url was omitted and not modified._ - -### Implications and Guidance - -- As blank fields are ignored, data to be removed should either be overwritten with a new value or have their entire row deleted using the `TODS_delete` field. -- As processing of files is non-sequential, it is prohibited to both delete and re-add a row with identical Primary Keys in the same Supplement file. -- If a row contains defined values besides the Primary Key and a `TODS_delete` value of `1`, the row shall be removed and other values in that row will be ignored. -- When adding rows and updating values, be certain to ensure the values are being updated based on their column values (e.g. if GTFS has fields of `trip_id,route_id,trip_short_name` and the TODS Supplement file has fields of `trip_id,trip_short_name`, be certain that values are mapping to the correct fields without assuming column headers are identical). -- When deleting a row in a file, any references to that field/value shall be ignored. Thus, it is important to ensure references to that row are either redefined or are being intentionally omitted. For example: - - When deleting a trip via `trips_supplement.txt`, all of that trip's entires in `stop_times.txt` will not be associated with a valid trip and would thus be ignored. - - When deleting a route via `routes_supplement.txt`, all trips using that route would not be associated with a valid route and would thus be ignored _UNLESS_ the `route_id` on the affected trips is updated via the `trips_supplement.txt` file. -- After modifying static GTFS content to incorporate the TODS Supplement modifications, the resulting data ("TODS-Supplemented GTFS") should form a valid GTFS dataset, with the limited exception of missing data that should be ignored per the above. - -### TODS-Specific Fields - -In addition to the fields defined in GTFS, specific fields for use within TODS are denoted by a `TODS_` field prefix. - -| **File** | **Field Name** | **Type** | **Required** | **Description** | -| --- | --- | --- | --- | --- | -| Any Supplement file | `TODS_delete` | Enum | Optional | (blank) - Update other fields; do not delete.
`1` - Deletes the GTFS row in the corresponding file whose Primary Key matches the value in the Supplement file's row. | -| `trips_supplement.txt` | `TODS_trip_type` | Text | Optional | Defines the type of the trip if distinct from a standard revenue trip. | -| `stops_supplement.txt` | `TODS_location_type` | Text | Optional | Defines the type of the location if distinct from a standard GTFS location type. Where defined, the GTFS `location_type` shall be ignored. | - -## TODS-Specific File Definitions - -### `run_events.txt` - -Primary Key: (`service_id`, `run_id`, `event_sequence`) - -| **Field Name** | **Type** | **Required** | **Description** | -| --- | --- | --- | --- | -| `service_id` | ID referencing `calendar.service_id` or `calendar_dates.service_id` | Required | Identifies a set of dates when the run is scheduled to take place. | -| `run_id` | ID | Required | A run is uniquely determined by a `service_id`, `run_id` pair. Runs with the same `run_id` on different `service_id`s are considered different runs. | -| `event_sequence` | Non-negative integer | Required | The order of this event within a run. Must be unique within one (`service_id`, `run_id`). See [more detail below](#event_sequence-and-event-times) about how order is defined. | -| `piece_id` | ID | Optional | Identifies the piece within the run that the event takes place.

May be blank if the event takes place out of a piece, like a break, or if the agency does not use piece IDs. | -| `block_id` | ID referencing `trips.block_id` | Optional | Identifies the block to which the run event belongs.

This field is always optional. May exist even if `trip_id` does not (e.g. if an event represents a run-as-directed block with no scheduled trips). May exist even if `trip_id` exists and the associated trip in `trips.txt` doesn't have a `block_id`. May be omitted even if `trip_id` exists and the associated trip in `trips.txt` has a `block_id`.

If `block_id` is set, `trip_id` is set, and the associated trip in `trips.txt` has a `block_id`, then the two `block_id`s must not be different. | -| `job_type` | Text | Optional | The type of job that the employee is doing, in a human-readable format. e.g. "Assistant Conductor". Producers may use any values, but should be consistent.

A single run may include more than one `job_type` throughout the day if the employee has multiple responsibilities, e.g. an "Operator" in the morning and a "Shifter" in the afternoon. | -| `event_type` | Text | Required | The type of event that the employee is doing, in a human-readable format. e.g. "Sign-in". Producers may use any values, but should be consistent. Consumers may ignore events with an `event_type` that they don't recognize. | -| `trip_id` | ID referencing `trips.trip_id` | Optional | If this run event corresponds to working on a trip, identifies that trip. Note that the trip may be on a different `service_id` than the run, see [`service_id`, Crew Schedules, and Trip Schedules](#service_id-crew-schedules-and-trip-schedules). | -| `start_location` | ID referencing `stops.stop_id` | Required | Identifies where the employee starts working this event.

If `trip_id` is set (and `mid_trip_start` is not `1`), this should be the `stop_id` of the first stop of the trip in `stop_times.txt` (after applying any trip supplement). If `start_mid_trip` is `1`, this should be the location where the employee starts working, matching a `stop_id` in the middle of the supplemented trip. | -| `start_time` | Time, as [defined in GTFS](https://gtfs.org/documentation/schedule/reference/#field-types) | Required | Identifies the time when the employee starts working this event.

If `trip_id` is set (and `mid_trip_start` is not `1`), this corresponds to the time of the first stop of the trip in `stop_times.txt` (after applying any trip supplement). If `start_mid_trip` is `1`, this time corresponds to a stop time in the middle of the supplemented trip, when the employee starts working on the trip. Note that this time may not exactly match `stop_times.txt` `arrival_time` or `departure_time` if the employee is considered to be working for a couple minutes before the trip departs. This field is about when the employee is working, and consumers who care about the the trip times should check `stop_times.txt` instead. | -| `start_mid_trip` | Enum | Optional | Indicates whether the event begins at the start of the trip or in the middle of the trip (after applying any trip supplement).

`0` (or blank) - Run event is not associated with a trip, or no information about whether the run event starts mid-trip
`1` - Run event starts mid-trip
`2` - Run event does not start mid-trip | -| `end_location` | ID referencing `stops.stop_id` | Required | Identifies where the employee stops working this event.

If `trip_id` is set (and `mid_trip_end` is not `1`), this should be the `stop_id` of the last stop of the trip in `stop_times.txt` (after applying any trip supplement). If `end_mid_trip` is `1`, this should be the location where the employee stops working, matching a `stop_id` in the middle of the supplemented trip. | -| `end_time` | Time, as [defined in GTFS](https://gtfs.org/documentation/schedule/reference/#field-types) | Required | Identifies the time when the employee stops working this event.

If `trip_id` is set (and `mid_trip_end` is not `1`), this corresponds to the time of the last stop of the trip in `stop_times.txt` (after applying any trip supplement). If `end_mid_trip` is `1`, this time corresponds to a stop time in the middle of the supplemented trip, when the employee stops working on the trip. Note that this time may not exactly match `stop_times.txt` `arrival_time` or `departure_time` if the employee is considered to be working for a couple minutes after the trip finishes. This field is about when the employee is working, and consumers who care about the the trip times should check `stop_times.txt` instead. | -| `end_mid_trip` | Enum | Optional | Indicates whether the event ends at the end of the trip or in the middle of the trip (after applying any trip supplement).

`0` (or blank) - Run event is not associated with a trip, or no information about whether the run event ends mid-trip
`1` - Run event ends mid-trip
`2` - Run event does not end mid-trip | - -#### `service_id`, Crew Schedules, and Trip Schedules - -For most agencies, crew schedules will use the same schedule as trips do. The `service_id` in `run_events.txt` will be the same `service_id` as is in `trips.txt` for all the trips that run works on, and the TODS feed won't need any additional entries in `calendar_supplement.txt`. - -Some agencies schedule crew schedules separately from vehicle/trip schedules, and runs and trips may occur on different `service_id`s. For example, a trip that occurs on service ID `weekday` may be worked by run `1` on service ID `monday`, and by run `2` on service ID `tuesday`. See the [examples](examples.md) for some situations where this may happen. In that case, `trips.txt:service_id` refers to dates when the trip occurs, and `run_events.txt:service_id` refers to the dates where the run works that trip. This means that producers do not need to rewrite the calendar for their public GTFS trip schedules in order to publish complex crew schedules in TODS. - -Consumers who care about the dates that a trip occurs should use the `trip_id` (which is unique even across different services) to look up the trip in `trips.txt`, and get the `service_id` there. - -Producers who create separate services for their crew schedules will likely need to add those services into `calendar_supplement.txt` and `calendar_dates_supplement.txt`. - -If the run's `service_id` and the trip's `service_id` are different, the run's `service_id` must not occur on any dates that the trip's `service_id` doesn't (after combining data from `calendar.txt`, `calendar_supplement.txt`, `calendar_dates.txt`, and `calendar_dates_supplement.txt`). - -#### `event_sequence` and Event Times - -`event_sequence` is required and unique within a run so it can be used in the Primary Key to uniquely identify events. - -Within one run, `event_sequence` values should increase throughout the day but do not have to be consecutive. - -Within one run, if two events both have `trip_id` set, they must not overlap in time (based on `start_time` and `end_time`). Employees cannot be on two trips at once, or have multiple duties on the same trip at the same time. Having a zero-minute overlap is allowed, to allow consecutive trips without layovers, and to allow trips with 0-minute durations, which some agencies use for bookkeeping reasons. - -Events that don't have `trip_id` set may overlap in time with any other events. This is to allow events that represent a large portion of a day (such as time that an employee is available to work), regardless of what other duties or trips they have during that time. - -Because some events may overlap in time, it may not be possible to choose a single order for events within a run that's correct for all uses. Producers should use `event_sequence` to define a reasonable order. If a consumer cares about exactly how overlapping events are ordered, they should sort based on the time fields and `event_type` instead. - -#### Run ID Uniqueness - -Run IDs may be non-unique. E.g. E.g. there may be a "Run 100" on both Weekday and Weekend service. There may even be a Run 100 on both `garage1-weekday` and `garage2-weekday` services, happening on the same day. Runs are uniquely referred to by a `(service_id, run_id)` pair. This is why the service ID is required on this file and other files that refer to run IDs. - -#### `run_events` Notes - -- Run IDs may be reused between different service IDs. A run is uniquely determined by a `service_id`, `run_id` pair. Runs with the same `run_id` on different `service_id`s are considered different unrelated runs. -- Multiple `run_event`s may refer to the same `trip_id`, if multiple employees work on that trip. -- Events may have gaps between the end time of one event and the start time of the next. e.g. if an operator's layovers aren't represented by an event. -- `start_time` may equal `end_time` for an event that's a single point in time (such as a report time) without any duration. -- Recommended sort order: `service_id`, `run_id`, `event_sequence`. - -### `employee_run_dates.txt` - -Describes which employees are scheduled to which runs on which dates. - -This file should represent the schedule after holidays, vacations, and other scheduled exceptions have been applied. - -Each run and date combination may appear 0 times in this file (if there's no assigned employee), 1 time, or multiple times (if multiple employees are assigned to the same run on the same date). - -Primary Key: `*` - -| **Field Name** | **Type** | **Required** | **Description** | -| --- | --- | --- | --- | -| `date` | Date | Required | Service date. | -| `service_id` | ID referencing [`run_events.txt`](#run_eventstxt) | Required | Part of the Run ID, which is refered to as `(service_id, run_id)`. See [Run ID Uniqueness](#run-id-uniqueness). | -| `run_id` | ID referencing [`run_events.txt`](#run_eventstxt) | Required | The run that's added to this employee's schedule. | -| `employee_id` | ID | Required | References an agency's external systems. Employee IDs are not used elsewhere in TODS. | - -### `vehicles.txt` - -Primary Key: `vehicle_id` - -| Field Name | Type | Required | Description | -|---|---|---|---| -| `vehicle_id` | ID, primary key | Required | Defines an ID for a vehicle. It is *recommended* but not required to match the `vehicle_id` in GTFS-realtime feeds. | -| `vehicle_label` | Text | Optional | Free text label for a vehicle, e.g. bus number or vessel name. | -| `license_plate` | Text | Optional | License number or global identifier for the vehicle, e.g. “E898656”. The field name was chosen to align with the `license_plate` field in GTFS-Realtime. It may specify a different global identifier, particularly for non-road vehicle types without license plates, e.g. Maritime Mobile Service Identity (MMSI) for ferries. | - -*Note for future-compatibility:* Future TODS versions may support vehicle couplings: specifically, train cars (individual vehicles) that comprise a train set. Such a proposal is described by the [GTFS-VehicleCouplings draft extension](http://bit.ly/gtfs-vehicles). - -### `vehicle_assignments.txt` - -Primary Key: `(date, block_id, service_id)` - -| Field Name | Type | Required | Description | -|---|---|---|---| -| `date` | Date | Required | | -| `service_id` | ID referencing `calendar.service_id` or `calendar_dates.service_id` | Optional | Identifies a set of *service days* when the trip is scheduled to take place. Note the [GTFS definition](https://github.com/google/transit/blob/master/gtfs/spec/en/reference.md#term-definitions) of *service day* is invoked here. Required if `block_id`s are repeated between different `service_id`s. | -| `block_id` | ID referencing `trips.block_id` | Required | Identifies the block. | -| `vehicle_id` | ID referencing `vehicles.vehicle_id` | Required | Refers to a specific vehicle in the transit fleet. | - -Not every block and date combo needs to have a vehicle specified. - -*Note for future-compatibility:* `vehicle_id` field may change to conditionally required in a future version where assignments may be made to either an individual vehicle OR a grouping of vehicles. See [GTFS-Vehicles](http://bit.ly/gtfs-vehicles) for how vehicle categories (types) might be incorporated. diff --git a/docs/en/spec/revision-history.md b/docs/en/spec/revision-history.md deleted file mode 100644 index e13ece6d..00000000 --- a/docs/en/spec/revision-history.md +++ /dev/null @@ -1,24 +0,0 @@ -# Revision History - -## 2025-04-16 - -TODS 2.1.0 is adopted - -* Adds new TODS-specific files `vehicle_assignments.txt`, `vehicles.txt`, and `employee_run_dates.txt`. -* Adds new supplemental files `calendar_dates_supplement.txt` and `calendar_supplement.txt` - -## 2024-07-24 - -TODS 2.0.0 is adopted, now to be implemented. - -## 2024-06-20 - -TODS v2.0.0-alpha.1 is adopted. - -* Removes files `deadheads.txt`, `ops_locations.txt`, `deadhead_times.txt`. -* Adds new files `trips_supplement.txt`, `stops_supplement.txt`, `stop_times_supplement.txt`, and `routes_supplement.txt`. - * Allows for supplementation, modification, and/or deletion of data in existing GTFS feed. - -## 2022-05-03 - -TODS v1.0.0 is adopted by the TODS Working Group diff --git a/mlc_config.json b/mlc_config.json deleted file mode 100644 index 7d3d9a09..00000000 --- a/mlc_config.json +++ /dev/null @@ -1,9 +0,0 @@ -// config file for markdown-link-check -// see: https://github.com/tcort/markdown-link-check -{ - "ignorePatterns": [ - { - "pattern": "localhost" - } - ] -} diff --git a/overrides/assets/images/2026-01-12_KesslerJeff_(Keolis)_[P26-20294]_The_Journey_of_TODS.jpg b/overrides/assets/images/2026-01-12_KesslerJeff_(Keolis)_[P26-20294]_The_Journey_of_TODS.jpg deleted file mode 100644 index 1ffb832b..00000000 Binary files a/overrides/assets/images/2026-01-12_KesslerJeff_(Keolis)_[P26-20294]_The_Journey_of_TODS.jpg and /dev/null differ diff --git a/overrides/assets/images/MOU_ODS_and_Mobility_Data_signed.jpg b/overrides/assets/images/MOU_ODS_and_Mobility_Data_signed.jpg deleted file mode 100644 index 7016a211..00000000 Binary files a/overrides/assets/images/MOU_ODS_and_Mobility_Data_signed.jpg and /dev/null differ diff --git a/overrides/assets/images/favicon.ico b/overrides/assets/images/favicon.ico deleted file mode 100644 index 55fed928..00000000 Binary files a/overrides/assets/images/favicon.ico and /dev/null differ diff --git a/overrides/assets/images/icon-pdf.png b/overrides/assets/images/icon-pdf.png deleted file mode 100644 index 4d6cc0ff..00000000 Binary files a/overrides/assets/images/icon-pdf.png and /dev/null differ diff --git a/overrides/assets/images/ods-small-eggshell.png b/overrides/assets/images/ods-small-eggshell.png deleted file mode 100644 index 74382f72..00000000 Binary files a/overrides/assets/images/ods-small-eggshell.png and /dev/null differ diff --git a/overrides/assets/javascript/fix-md-search.js b/overrides/assets/javascript/fix-md-search.js deleted file mode 100644 index c9ed6a17..00000000 --- a/overrides/assets/javascript/fix-md-search.js +++ /dev/null @@ -1,28 +0,0 @@ -// Accessibility fixes for Material for MkDocs -document.addEventListener('DOMContentLoaded', function() { - - // Fix search dialog ARIA accessibility - const searchDialog = document.querySelector('.md-search'); - if (searchDialog) { - searchDialog.setAttribute('aria-label', 'Site search dialog'); - searchDialog.setAttribute('role', 'dialog'); - - // Also fix the search input if it exists - const searchInput = searchDialog.querySelector('.md-search__input'); - if (searchInput && !searchInput.getAttribute('aria-label')) { - searchInput.setAttribute('aria-label', 'Search the documentation'); - } - } - - // Fix search overlay if it exists - const searchOverlay = document.querySelector('.md-search__overlay'); - if (searchOverlay) { - searchOverlay.setAttribute('aria-hidden', 'true'); - } - - // Fix search form - const searchForm = document.querySelector('.md-search__form'); - if (searchForm) { - searchForm.setAttribute('role', 'search'); - } -}); diff --git a/overrides/assets/stylesheets/additional.css b/overrides/assets/stylesheets/additional.css deleted file mode 100644 index b5c35d2f..00000000 --- a/overrides/assets/stylesheets/additional.css +++ /dev/null @@ -1,96 +0,0 @@ -/* Define CSS variables based on theme colors */ - - -/* ============================================== - CSS VARIABLES - COLOR PALETTE - ============================================== */ -/* Palette source: https://coolors.co/palette/f4f1de-e07a5f-3d405b-BAE3CF-F4D39F*/ -:root { - --md-primary-fg-color: #3d405bff; /* delft-blue */ - --md-accent-fg-color: #BAE3CFff; /* cambridge-blue */ - --md-primary-bg-color: #f4f1deff; /* eggshell */ - --text-color: #3d405bff; /* delft-blue: */ - --md-code-hl-color: #e07a5fff; /* burnt-sienna */ - --highlight-outline: #F4D39Fff; /* sunset */ - --headers-text-color: #4F4F4F; /* dark gray */ -} - -/* ============================================== - MKDOCS ELEMENTS - ============================================== */ - -.md-header__button.md-logo img, -.md-header__button.md-logo svg { - height: 2.5rem; -} - -.md-header { - overflow: visible; /* Allow overflow */ - background-color: var(--md-primary-fg-color); -} - -.md-footer { - background-color: var(--text-color); - color: var(--md-default-bg-color); -} - -/* Footer Icons */ -.md-footer .md-icon { - color: var(--text-color) !important; -} - -.md-tabs { - position: relative; /* Make sure .md-tabs is positioned */ - overflow: visible; /* Allow overflow */ - margin-bottom: 60px; -} - -/* ============================================== - TYPOGRAPHY - ============================================== */ - -/* Body and Link Styling for Readability */ -body { - font-family: 'Roboto', sans-serif; - color: var(--text-color); - background-color: var(--md-primary-bg-color); -} - -/* Headings */ -h1, h2, h3, h4, h5, h6 { - color: var(--headers-text-color); -} - -a { - font-weight: bold; /* All Hyperlinks Bold */ -} - -a:hover { - color: var(--md-accent-fg-color); - font-weight: bold; /* All Hyperlinks Bold */ -} - -code { - background-color: var(--md-accent-fg-color); /* No border for a cleaner look */ -} - -/* ============================================== - TABLE STYLING - ============================================== */ - -table { - border-collapse: collapse; - width: 100%; -} - -th, -td { - border: 1px solid var(--md-primary-fg-color); - padding: 8px; - text-align: left; -} - -th { - background-color: var(--md-primary-fg-color); - color: var(--md-default-bg-color); -} \ No newline at end of file diff --git a/requirements.txt b/requirements.txt deleted file mode 100644 index 6d20efad..00000000 --- a/requirements.txt +++ /dev/null @@ -1,7 +0,0 @@ -fontawesome_markdown==0.2.6 -mkdocs==1.6.1 -mkdocs-awesome-pages-plugin==2.10.1 -mkdocs-macros-plugin==1.5.0 -mkdocs-material==9.7.6 -mkdocs-material-extensions==1.3.1 -mkdocstrings==1.0.6