Skip to content

Public Draft Review

Summary

  • Support for development of open standards
  • Interest in developing equity/data justice as integrated part of MDIP, and furthering ability of communities to achieve equity through data availability
  • Desire for more clarity around specific impacts of MDIP to GIS data
  • Desire to incorporate examples of implementation into resources online, along with instructional anecdotes (potentially in additional presentations for those seeking to adopt/implement the principles)
  • Desire for additional resources to support champions
  • Interest in adding communities as vested stakeholders for the Interoperability Principles and to contemplate the impacts of the MDIP vision on communities
  • Desire to specifically tailor language around interoperability to exclude internal processes in order to encourage private sector engagement
  • Interest in including academic researchers or explicitly addressing specific types of regulators in the end users of MDIP

Feedback Excerpts

The definition of Mobility Technology Component is key and should be highlighted up front, as this defines which categories of data fields are necessary for interoperability - to efficiently provide inter-modal and/or multi-provider linked trips.

The 6th category, “Manage the mobility system (e.g. performance reporting, shift selection, non-revenue schedules)”, is too broad.
Performance Reporting is germane.
Each mobility provider’s internal processes, including shift selection and non-revenue schedules, are not germane.

Internal processes should be explicitly excluded from this effort. This revision will encourage participation by the private sector.

The 4th and 5th categories should be more explicit and combined: “Facilitate communications and processes among the staff involved in providing rides (drivers, schedulers, dispatch and other on-board staff) involved in booking, assigning, providing and monitoring rides through hardware, software and protocols”.

While older systems separate the scheduling, trip assignment, dispatch, and monitoring processes, these are combined by the newer dynamic real-time ride providers.

What we heard

Paraphrased and combined for clarity and concision.

Scope

Is the planning/modeling/analysis side of transportation within the scope of the Principles? There aren’t any examples in this realm.

Planning, modeling, and analysis are included in the scope of the Principles, but only to the extent that they are functions of an established stakeholder.

For example, the Principles take into account the transit planning that takes place in the development of new schedules for an agency. There may likewise be modeling and analysis that is utilized to assess actual performance or the performance of potential alternatives. However, the Principles do not at this stage include long-term planning activities like construction of new transportation facilities, nor does it include traffic volume analyses, traffic light analyses, or any modeling related to these.

These items were excluded from scope due to the feedback received during the Admin review period for the Principles, that a too-broad scope would significantly increase implementation challenges. Such items may be scoped in for a future version of the Principles.

Implications of Principle 3

Principle 3

Transit agencies and other mobility service providers should have access to tools that present high-quality mobility data accessibly, equitably, and in real time to assist travelers in meeting their mobility needs.

Is Principle 3 arguing for public funding or provisioning of tools?

No.

Principle 3 positively asserts that mobility service providers are more able to provide high quality service to travelers when the technology they utilize is interoperable. Principle 3 is concerned with the qualities of market-developed tools and the ability of agencies to transition between suites of tools to find a solution that meets their needs. It is not intended to reference the means of procuring those tools.

Equity Focus

There should be a principle that’s focused on equitable access and outcomes

The document mentions “equity” in a couple places, but this important theme should be strengthened throughout. Consideration should be added for social equity across demographic groups and equity in the transportation technology marketplace.

Data alone can’t solve all these challenges, but it would be great to have a principle in this document that indicates how all are worth pursuing.

Unclear if the specific goal is to:

  • provide access to trip planning and related data services equitably, to provide the actual transportation service equitably, and/or
  • for equitable outcomes in terms of the real-world needs that travelers are trying to accomplish.

The co-authors discussed the below options (modifications in bold):

Options considered:

Existing Principle 5

All individuals should be empowered through high-quality, well-distributed mobility data to find, access, and utilize high-quality mobility options that meet their needs as they see fit, while maintaining their privacy.

All individuals should be empowered through high-quality, well-distributed mobility data to find, access, and utilize high-quality mobility options that meet their needs as they see fit, while maintaining their privacy. Communities should then have access to the data necessary to advocate for a more equitable society and a more sustainable environment and economy.

All individuals should be empowered through high-quality, well-distributed mobility data to find, access, and utilize high-quality mobility options that meet individual, community, and planetary needs while maintaining individual privacy.

All individuals should be empowered through high-quality, well-distributed mobility data to find, access, and utilize high-quality mobility options that meet their needs as they see fit, while maintaining their privacy. Understand that these individual data play an important role in equity and sustainability at a community level.

All communities should be empowered through high-quality, verified, and accessible mobility data, to analyze and understand the impacts of transportation systems on the well-being of society and the environment. They should have access to data necessary to advocate for a more equitable society and a more sustainable environment and economy.

After several meetings, the co-authors concluded that equity was more properly an initial motivating factor for the Principles themselves. Equity and sustainability were thus added to the Purpose statement within the document. Additionally, in order to reduce the perceived individualism of elevating travelers but not groups of people to the level of stakeholders, the group determined that the language should include a reference to the public at large as being stakeholders.

4. Who is the “consumer” in Principle #4?

Principle 4

Transit agencies, other mobility service providers, and consumers should be able to select the mobility technology components that best meet their needs.

Travelers or data consumers?

  • If it’s data consumers, that makes sense for modular “best of breed” and “build or buy” models, where all agencies that produce and consume data can assemble the highest quality components for their needs and further improve in an iterative manner.
  • If it’s travelers/riders, that seems like a very different proposition — moving the point of integration from within agencies/providers/consuming apps to the riders themselves.

That’s interesting and could be a great eventual goal, but it is very complicated to tackle at this point and seems to distract from more immediate goals of improving interoperability across existing and near-term systems within agencies/providers.

5. Documented data formats list is suggestive but incomplete

Documented data formats list is suggestive but incomplete

This is intentional at this stage. A more complete and comprehensive list will be developed as part of the implementation product: Mobility Dataverse.

Changes made in response to Public Review Comments

Benjie de la Pena, SUMC

SUMC suggests including community as key stakeholder of the Interoperability Principles. The current draft only considers transit agencies, mobility service providers, and individuals. The communities are not even contemplated. We suggest appending a sentence to the 5th principle or (our preference) adding a sixth principle.

Option A Principle #5.

All individuals should be empowered through high-quality, well-distributed mobility data to find, access, and utilize high-quality mobility options that meet their needs as they see fit, while maintaining their privacy. Communities should then have access to the data necessary to advocate for a more equitable society and a more sustainable environment and economy.

Option B Principle #6.

All communities should be empowered through high-quality, verified, and accessible mobility data, to analyze and understand the impacts of transportation systems on the well-being of society and the environment. They should have access to data necessary to advocate for a more equitable society and a more sustainable environment and economy.

Jamie M. Fischer

The document mentions “equity” in a couple places, but this important theme should be strengthened throughout. Consideration should be added for social equity across demographic groups and equity in the transportation technology marketplace.

Albert Kochaphum

I would like for there to be an equity part of the interoperability principles, similar to the idea of data justice, where the focus just isn’t on keeping data open and transparent, but also anti-discrimination of who gets access to use this information and on which platforms.

Equity

MDIP co-authors discussed equity as a component of the vision for this document. It was agreed on that communities are a stakeholder for the Interoperability Principles. Concern was expressed regarding the appropriate way to bring equity into the principles. Concern was expressed that in not mentioning equity, MDIP would lose meaningful mechanism to hold signers to pursuit of equity outcomes later on.

Anti-discrimination

In regards to the issue of anti-discrimination, that is (sort of) addressed in the implementation responsibilities’s reliance on open standards which should be usable/consumable by any developer or app. That being said, there is a certain level of gatekeeping built in to MDIP at this point because discretion as to what information should be distributed and to whom is ultimately given to the Mobility Service Provider. Currently, this responsibility rests with the Transportation Technology Company in many/most cases.

Modifications Made

“Communities” added as stakeholder to vision statement. Revised Principle 5 language.


Tiffany Huang

Would like more clarity around sharing and data governance for GIS data.

MDIP contemplates GIS data as being beholden to the same levels of disclosure as other shared and/or generated data. GIS software developers would fall under the definition of a Transportation Technology Company, their products or platforms as Mobility Technology Components, and individual datasets and/or shapefiles as Mobility Data.

Modifications Made

Added explicit mention of “GIS” under definition of Mobility Technology Component point 5


Jamie M. Fischer

The vision for transit planners and transportation system managers should make reference to the context of land use, environmental, and socio-economic data that are often utilized in broader planning efforts.

MDIP agreed to incorporate this change.

Modifications Made

Explicit reference to land use, environmental and socio-economic data added to vision for Transportation System Managers.


Jamie M. Fischer

There are a few issues with grammar and clarity throughout. I will provide more specific notes ad suggestions by emailing a markup of the public draft.

Received, thank you.

Modifications made

Grammar and punctuation updated based on recommendations.


Drew Dara-Abrams, Interline

OpenStreetMap is a complicated example to cite. OSM’s standard file format and API data format is XML, which isn’t listed in this doc. OSM data is licensed under a “viral” license, some would argue doesn’t fit the goals of “openness” in these principles — then again, others would argue it does. Also debatable is whether OSM has “transparent, inclusive governance.” Much progress related to OSM actually happens outside of the OSM Foundation and its communication channels. We don’t want to be “downers,” but OSM is very mixed as a role model for other projects.

MDIP agrees that OSM is not easily citable as an open technology.

Modifications made

OSM removed from examples


Steve White, GMV Syncromatics

Re: Ability of Interoperability to enable MSPs to swap GPS units or onboard computers: This sounds nice in theory, but the fact of the matter is that the onboard unit used by a CAD/AVL system is more than just a “GPS unit” and these things are not going to be widely interchangeable even if they use commercial off the shelf hardware. An agency cannot simply swap out “GPS units,” because the GPS functionality is included in a tablet or computer-type piece of hardware that performs many other functions. Some companies develop their products on Android and some on Linux (both open source operating systems), and some use Windows or other type devices. I don’t assume the interoperability principles would go so far as to define a specific OS or hardware architecture, so this entire point feels far-fetched to me. Only in the most basic GPS-only type deployments could it be possible – where multiple routers or single-purpose GPS trackers would use a TAIP or NMEA type standard.
All of the other points in this section make sense.

The language used here (“Interoperability enables: Mobility service providers to easily change which GPS unit their CAD/AVL system uses because the old and new GPS units transmit data in an open standard and the CAD/AVL system ingests data in an open standard.”) is or should be more directly focused on the intention of the co-authors to combat so-called vendor lock-in and the inability of Mobility Service Providers to secure the technology they want to use. The intention of this bullet point is not to suggest that interoperability means that a specific fine-grained technology will be able to work with another within a single vendor’s suite of components necessarily (although the Principles might provide an incentive in that direction).
In general, this point should be broadened so that it is about the expectation that interoperability will allow for MSPs to “right-size” their Mobility Technology Components to meet their existing and projected needs because those components will be better integrated into a larger Mobility Technology System.

Modificaitons Made

Replace existing language with:

Mobility service providers to more easily receive the mobility technology components that meet the needs of their uses because components are better integrated into a larger mobility technology system, in which the transmission and ingestion of data is utilizing open standards.”


Additional Responses to Public Review Comments

Chloe Spano, Cityway

How does MDIP result in ability of mobility service providers to use data from other MSPs? Through collaborative 1-to-1 agreements?

Noted

The statement in the MDIP vision (“Mobility service providers can… Easily use their data and data from other mobility providers to increase rider satisfaction and the customer experience through service efficiency and service quality.”) references the ability of data to be more widely available to various consumers in an interconnected network of service provision. It is anticipated that interoperability will result in a fuller picture of mobility data for all providers without the need for private one-on-one agreements between operators.


Chloe Spano, Cityway

Under implementation responsibilities: Transit Agencies and Governments should allow access keys to data consumers

Noted

This comment is posted in multiple locations in response to the use of the phrase “without restriction” to the access of data in open standard or proposed open standard format. The intention of MDIP is that access keys would constitute an acceptable means of making data available to parties designated by the transit agency or mobility service provider.


Chloe Spano, Cityway

Change definition of published data so that data published via documented API “must” (rather than “may”) be granted via API key.

Noted

The impact of this change is that MDIP would not consider data to be published if the API operator were to make the data available without an API key. MDIP is allowing for but not mandating the use of API keys, and the default in some cases might well be for there to be no API key, which appears to be an acceptable use.


Steve Yaffe, Yaffe Mobility Consulting

The definition of Mobility Technology Component is key and should be highlighted up front, as this defines which categories of data fields are necessary for interoperability - to efficiently provide inter-modal and/or multi-provider linked trips. The 6th category, “Manage the mobility system (e.g. performance reporting, shift selection, non-revenue schedules)”, is too broad. Performance Reporting is germane. Each mobility provider’s internal processes, including shift selection and non-revenue schedules, are not germane. Internal processes should be explicitly excluded from this effort. This revision will encourage participation by the private sector. The 4th and 5th categories should be more explicit and combined: “Facilitate communications and processes among the staff involved in providing rides (drivers, schedulers, dispatch and other on-board staff) involved in booking, assigning, providing and monitoring rides through hardware, software and protocols”. While older systems separate the scheduling, trip assignment, dispatch, and monitoring processes, these are combined by the newer dynamic real-time ride providers.

Noted

In the published format we anticipate making the definitions easily available throughout the document using tooltips and/or links. The definition should be evident to readers from the first mention. Internal processes are not excluded from MDIP due to the desire through interoperability to help identify and eliminate existing gaps in the flow of data for mobility consumers/producers. Generally, there is not industrywide agreement on what constitutes internal processes and making a decision to exclude them here could result in a significant reduction in MDIP’s ability to press the industry toward interoperability. Additionally, some MDIP coauthors are presently working with industry partners to standardize data for non-revenue services and shift selection.


Anat Caspi, Taskar Center for Accessible Technology

I would very much like to see (and contribute to) implementation stories, as well as the production of presentation materials that would allow for dissemination of the principles. Specifically, it would be great to take after the model of Smart Growth America, develop the principles a little bit more, and offer advocates of the principles a coherent set of slides and instructional material from/through which they can evangelize the ideas in the principles.

Noted

This comment relates specifically to implementation of the principles and not to the document, however it seems like a good course of action for MDIP as we move into the post-v1-publication phase of promoting the principles.


Weston Shippy,Trillium Transit

Happy with the product overall! The principles mention end users and mobility service providers as stakeholders who can benefit from interoperable data, but they don’t mention planning/regulatory/DOTs or academic researchers. This omission may have been intentional, however, because they were discussed in the drafting process.

Noted

Planning/regulatory/DOTs are contemplated by the MDIP as being part of Transportation System Managers. Researchers are listed as an independent (albeit undefined) stakeholder in the Vision statement.


Sean Holman

I believe that the development of open standards and open source tools is critical to the future of mobility. These principles embody the strength that comes from an aligned approach amongst complimentary projects like MDS, GBFS, and GTFS

Noted

Comment is supportive of the project.


Jamie M. Fischer

  • The vision for transit operators and the discussion of interoperability’s importance should include a reference to data validation, quality control, and cross-referencing.
  • The vision for transit system managers should make reference to project selection and funding to meet emerging customer needs.

Noted

The language that has been selected for MDIP v1 is generally “best available” and in “real-time.” The implementation responsibilities language has more expressive force where quality and validation are concerned. This may be an area to revisit in a future document, but for the time being validation and quality are viewed as areas of enforcement, rather than natural outgrowths of MDIP.


Jamie M. Fischer

Re: read/write access requirement in Implementation Responsibilities: Is this reasonable for all transportation technology components? I imagine read-only access would be an easier sell - specifically because of the “free from cost” detail. Write-access might require contractual relationships, unless I’m not understanding the responsibility as written.

Noted

The stipulation may be overbroad given the broad construction of transportation technology components, resulting in a higher than desired implementation cost. | Language changed from “read/write” to “read-only or read/write.” The default assumption will therefore be read-only


Drew Dara-Abrams, Interline

Re: Open Standards. The criteria will likely clash with approaches taken by some other orgs — SAE and the Alliance for Parking Data Standards come to mind. Maybe that is inevitable, but do consider reaching out to discuss

Future Action

MDIP will coordinate and communicate with SAE, ADPS, CEN and APTA


Steve White, GMV Syncromatics

Regarding Implementation Responsibilities to support “adopted and proposed open standards”: My only comment here is that the “proposed” language should be removed. Until a standard is accepted and implemented by other parties, it’s unlikely that even a vendor who is generally agreeable to open standards will start implementing it in hopes that it becomes widely adopted. I realize this is a bit of a catch-22, as the lack of critical mass adoption prevents a critical mass from agreeing to adopt a standard, but few companies will want to commit to adopting “proposed” standards until they see adoption. A good example of this is GTFS-ride for sharing historical APC data. We see the benefit of it, the standard is current, but adoption is so low that it makes no sense for us to invest in adopting it ourselves. Until scheduling providers that have customers in common with us actually adopt it, there is no reason for us to do so and our time is better spent on other endeavors. With that in mind, it would be difficult for us to commit to adopting “proposed” open standards. We would certainly commit to language that says we’d utilize “widely adopted” or “industry accepted” open standards. This “adopted” language makes sense especially when you follow to the next sections in the document which say that transportation technology companies shall “collaboratively develop and adopt open standards where gaps currently exist.” That is agreeable, because it comes with the assumption that other companies would adopt those standards, thus it becomes worth everyone’s time to adopt and no single company would be left as the only one having wasted time adopting a standard that no other companies adopted.

Noted

The implementation responsibilities are the main enforcement backstop for the principles that prevent them from being merely aspirational. They are intended to serve as a benchmark against which the co-authors, prospective buyers, MSPs, communities, and other interested stakeholders can assess whether or not a given mobility technology component is or isn’t interoperability compliant. This topic came up in Admin Review conversations and among co-authors who determined that it was reasonable to establish some definition for “proposed open standard” that has a higher threshold than merely existing, including the transition of the standard to an independent group for management.

Public Draft Reviewers

In addition to the co-authors and co-signatories, the public draft was distributed to a multitude of interested public-sector, public-interest, academic, and private-sector organizations and individuals. We received 13 formal reviews and edits ahead of the September 13th 2021 deadline, of which the following organizations and individuals gave permission to disclose their names and affiliations (*for identification purposes only):

  • Drew Dara-Abrams, Interline Technologies
  • Chloe Spano, Cityway
  • Weston Shippy, Trillium Solutions
  • Katie Monroe, Transit App
  • Steve Yaffe, Yaffe Mobility Consulting
  • Sean Holman
  • Albert Kochaphum, LA Metro
  • Jamie M. Fischer, State of Georgia’s Mobility Authorities
  • Audrey Denis, Cubic
  • Steve White, GMV/Synchromatics Inc.

Co-author Application and Admission Process

During the Public Review period, organizations were allowed to express interest in joining the co-authors of the Mobility Data Interoperability Principles before the publication of v1.

On September 27, 2021, the co-authors met to establish a formal process for admitting new co-authors and to vote on applications for co-author status by four organizations.

The co-authors expressed concern about the potential reputational impact on the Mobility Data Interoperability Principles that could be incurred if for-profit companies were allowed to join as co-authors. Additional concerns were raised including the potential for co-authors to have to pick winners and losers among for-profit applicants, the enforcement of the spirit of the principles, and the ability for the principles to be used primarily as a marketing tool by co-authors.

The co-authors decided that the marginal benefit to elevating for-profit companies as co-authors rather than as co-signatories was smaller than the marginal cost of allowing for-profit companies to join the ranks of the co-authors of the Principles.

Consequently, the co-authors have agreed upon the following process for the inclusion of new co-authors:

  1. New co-authors shall be accepted by application during an open call prior to the release of each version of the Mobility Data Interoperability Principles.
  2. Co-authors must be institutions, transit agencies, or other non-profit organizations. Applications will not be accepted from for-profit companies, nor shall such companies be considered eligible to apply.
  3. Upon receipt of an application from an eligible organization, the co-authors will schedule a vote on the question of admitting the organization as a co-author.
  4. The initial question will be one of unanimous consent: if there are no objections to the admission of the applicant organization, the co-authors will formally move to accept the applicant organization as a co-author.
  5. If there are objections, they will be stated and discussed.
  6. If the question of admitting the applicant organization should be called again following the discussion of objections, the applicant organization may be admitted with a majority (50%+1 vote) of all co-authors voting in favor.

With this process established, consideration was taken up for the four applicant organizations for co-authorship under the new process prior to the release of v1. Of those organizations, three were for-profit firms (Cityway, Cubic, and Transit App) and thus ineligible under the new guidelines. These organizations will be notified of the policy and that their applications have therefore not been accepted. The fourth organization, the Taskar Center for Accessible Technology at University of Washington, was found to be eligible and was admitted as a co-author of the Mobility Data Interoperability Principles without objection.

Pre-Final Release Co-Author Review

Co-Author Review Meeting Minutes

On September 28, 2021, all Proposed Responses to Public Review Comments and Requests for Changes were adopted without objection except for the requested changes by Co-Author Benjie de la Peña/SUMC on the topic of community representation, equity and sustainability.

Concerns were raised in the objections about the focus on the individual over communities and in the subordination of community needs to individual needs in the proposed revision of the 5th Principle. Additionally, concerns were raised in the objections about the proposed revision to the Vision statement, in particular that they did not address sustainability directly.

On October 5, 2021, the Co-Author group was invited to a meeting to discuss the resolution of the outstanding objections and to develop new proposed revisions to address the Public Review comments. The meeting was opened with a reading of the proposed revisions to the Vision statement and Principle 5. Benjie de la Peña/SUMC presented his objections to the group, and stated that the main desires were the addition of a sixth principle to represent community empowerment and to move equity and sustainability from the Vision statement to the Purpose statement.

The Co-Author group discussed concerns around adding a sixth principle for communities, particularly that there was not a clear nexus between the Interoperability Principles - which are intended to facilitate the movement of data between actors in a closed system, rather than to serve as an open data project - and community empowerment. Concerns were also raised about the self-defining nature of Communities - which to this point has not been a defined term within the Mobility Data Interoperability Principles.

Concerns were also raised with the ability of the Co-Authors to serve as experts in the achievement of equity for communities, and with the potential for co-signatories to use the Mobility Data Interoperability Principles to “equity-wash” without meaningful implementation responsibilities. The group discussed potential equity-oriented implementation responsibilities, including a requirement for co-signatories to provide an appeals process, context, and justification for the creation of data types.

Ultimately, the group came to an agreement that despite concerns around individualism, there wasn’t a clear enough link between Interoperability Principles and community empowerment, or between community empowerment and equity, for inclusion at the Principle level in this document. Additionally, implementation responsibilities were not edited due in part to concerns about who the “do-er” would be and the potential for additional requirements to affect existing commitments from co-signatories.

The meeting concluded with the Co-Authors moving without objection to present the following changes to the full Co-Author group (Edits in bold):

  • Amend the Purpose statement to read:

The purpose of the Mobility Data Interoperability Principles is to foster a transit industry where mobility data flows freely and securely between systems, between operators, and between providers and the riding public, empowering transit agencies and other mobility service providers and transportation system managers to provide better service, improve the customer experience, and promoting equity and sustainability.

  • Amend Principle 5 to read:

All individuals and members of the public should be empowered through high-quality, well-distributed mobility data to find, access, and utilize high-quality mobility options that meet their needs as they see fit, while maintaining their privacy.