The appearance of MobilityData and the effect on the GTFS ecosystem

[Stefan de Konink]

Hello,


Over the past two years we have seen a lot of effort in the GTFS ecosystem.
While the standardisation effort under Google got to a standstill around
the time that a major shift in workforce took place, new additions that
would work in Google Maps where typically not published, and the only page
that existed was the GTFS-extension page. MobilityData had taken the
trouble to draft multiple specifications for these existing "hidden
features", typically attributes, which should be embraced.

More and more I feel that something like "The OpenStreetMap Foundation" is
taking place in terms of GTFS and its ecosystem via MobilityData. For the
unfamiliar, a private successfull but decentral operating initiative was
taken over, and put in place above a large community. Then enforced license
changes. And received significant donations from the industry. Putting the
community into a "if you are not with us, you are against us."

Is evidence for this? If we consult mobilitydata.org:

> 2018 marks a major turning point in our history as MobilityData has
> received sponsorship by major players of the mobility data industry,
> allowing it to turn a Rocky Mountain Institute project into a stand
> alone non-profit organization, MobilityData IO, based in Montréal, Canada.

It is clear that MobilityData is not publishing who is sponsoring them.
Hence can we trust their work is in fact independent and with best
intentions? Or could one ask if the work is only done if it is directly
paid for by an actor that wants to remain anonymous. Or more in a closed
national standard effort: you can only discuss or suggest additions if you
pay for a annual subscription fee.

In addition to that:

> During that year, MobilityData has led the improvement and extension of
> the de facto worldwide standard for public transit data, the GTFS format,
> by fostering conversations around on-demand services, fares, and by
> extending the format to describe station pathways.

I see. MobilityData is doing all this work. It does not feel this way at
all. Or does it? And can we only observe?


> Today, MobilityData is also now in charge of its equivalent in the
> sharing-system world, the GBFS format, as a subcontractor of NABSA.
> And through a partnership with TransitScreen, MobilityData has
> launched OpenMobilityData, a world wide repository of GTFS datasets.

It feels like MobilityData is positioning itself, in the same position as
OSMF: If you are not with them, you are against them. And you may not
appear on their outlets, or not be consulted in their conversations.


I would like to have an open discussion if we as ecosystem should allow a
third party - a lobby organisation - that is not a technical implementer of
data to draft marjor changes that would require key consumers to update
their systems. Specifically: if these key consumers do not update their
software - or do partial implementations - it would mean that travel
information is wrongly presented hurting the entire ecosystem. Which must
be avoided at all costs.


--
Stefan

[Michael Smith]

Thank you for starting this discussion.

Our ecosystem of transit information relies on the use of standards such as GTFS. My company Swiftly would not exist without these standards. At the same time, the situation continues to evolve rapidly as new sources of information are incorporated and as needs change. It is imperative that we have an organization to facilitate these changes, and I strongly feel that it shouldn't be in the hands of a single company as it was before. I see MobilityData as a group that saw the need for such facilitation. 

And note that I use the word "facilitation". The standards are not based on financial support but on the merits of the ideas. Non-members definitely have the ability to influence. I say that from the point of view of having experience with the organization, while not being a financially supporting member.

Doing this work of course costs money. Standards groups need to have staff and do effective outreach. Otherwise the standards cannot evolve. That they are supported by multiple "major players" in the transportation data world is clear. I think it is also necessary.

Of course if you find that your ideas, while having merit, are not being accepted, then please let this community know. I think we have strong agreement that good ideas need to be accepted, even by non-members.

Mike

[Leo Frachet (MobilityData)]

Hi Stefan,

Thanks for raising those questions. I think most of the stakeholders active in this Google Group and on the GitHub have some context that you don’t have, since they attended the workshops we did in NYC and Paris (to which you was invited). We provided most (maybe even all) of the informations which are below in those workshops, and we have been sending updates (e.g. the invite to our Annual General Meeting) to our members and by default to the stakeholders which attended those workshops, using this characteristic as an easy first estimation to know who is interested by our work. Therefore you weren’t kept informed of our evolution. You could have reached out directly to us to get those updates, and we would have provided them with pleasure. But your post gives us the occasion to post some updates publicly, so let’s do it.

My main answer to your concerns, regarding our lack of transparency, is that we have been working on it in the past months. We are actively working on overhauling our website (mobilitydata.org), the current landing page is outdated, and we have been through the whole process since last fall of overhauling the content, the backend and the visual identity. We have the new website in staging for now, we hope to push it live next week (hopefully Tuesday, so March 3rd 2020if all the fixes are done by then).

The new website will be answering your questions about who’s sponsoring it, and sharing this information has required us go through a long process of approval with some of the public relationship team of some of our members. But there are already quite a few things that I can share with you today.

I apologize, my answer is long, but the goal is to be thorough, and I think that since you want the industry to discuss our legitimacy, it requires to be thorough. The first section is the direct answer to your direct questions, while the other sections will give you an overview of who we are, what we did and what we will do, it’s likely worth a read.

Finally, if you (or anybody else) have additional questions that I’ve missed, please ask them.

I’ll go through:

0. The answers to your specific questions, one by one

1. Who we are legally: Staff, Board, Members, bylaws etc.

2. What have we done so far

3. What is on our 2020 roadmap

4. Our relationship with NeTEx (I’m putting a whole section on it since you’ve raised that question multiple times)

# 0. Point by point answer

> “For the unfamiliar, a private successfull but decentral operating initiative was taken over, and put in place above a large community. “

About the “private” part, we are non profit, our members (see section 1.2) are industry stakeholders (mostly public transit agencies, software vendors and mobility apps). They are electing our board (see section 1.1) which is the governing body of the organization. So we are indeed “private” (since we are not public), but we are a non-profit organization, which has given the power to its members (currently 11 voting members, see section 1.2). We’ve explained that in the workshops, and this will be documented in our new website which is currently in staging stage.

> “Then enforced license changes”

I don’t know what you are referring to. AFAIK we didn’t change any license in GTFS. We asked Google to clarify if they put it under Apache 2.0 or CC 3.0, and no definitive answer came from it. Could you please tell me what you are referring to?

> “Received significant donations form the industry”

Yes we did, which funded our work. Currently 13 companies gave us money. We have been through a long process of approval with some of them to be allowed to disclose it. It will be part of next week’s press release and website overhauling. The name of the companies and the “bracket” in which they are (we have 12 brackets, so you’ll get a quite precise idea of the amount) will be public.

> “Putting the community into a "if you are not with us, you are against us."”

I don’t understand what you’re referring to. Could you be more specific? All the work that we publish is open source and we haven’t changed the governance of the GTFS specification. If you’re frustration comes from GTFS-Vehicles, that you have the feeling that you’ve been put in front of a finished specification, and that you haven’t been included in the process (describing that as “if you are not with us, you are against us” would be pretty strong though), then yes, I agree that we should have shared earlier versions of GTFS-Vehicles. We did it with GTFS-ServiceChanges, and since the proposal wasn’t backed enough, we had to re-write it a second time, then a third time, then a third-point-one time, and I think we exhausted the community by all those back and forth. The same thing happened with GTFS-Flex v2, which has been overhaul after a lot of community discussion. We are learning, and trying different things. I’m convinced that GTFS-Vehicles should have been shared earlier, and we are trying to streamline the process gradually. However, the proposal is under discussion, and we are responding to your (and others) feedback in the thread, and we are expecting modification to happen (including possible renamings). While working with the community, we get feedback and we improve not only the proposals, but also our work and our processes.

> “It is clear that MobilityData is not publishing who is sponsoring them.”

I’ve answered that above. For your information, it took us almost 2 years to get the approval of some private company to share their engagement, and we are thrilled to now have it. The press release is ready, the new website is almost ready, we only need some design tweaks and some phrasing polishing and you’ll get all those informations.

> “Hence can we trust their work is in fact independent and with best intentions? Or could one ask if the work is only done if it is directly paid for by an actor that wants to remain anonymous.”

Again, you’ll get those answers next week. We have been able to share more information about our sponsors in our workshops, because it wasn’t written. Only now do we have the approval to share those information in writing.

> “Or more in a closed national standard effort: you can only discuss or suggest additions if you pay for a annual subscription fee.“

We haven’t changed the GTFS Specification Amendment Process, everybody can vote and contribute. We are engaged at keeping this modification process as open as it is currently. GTFS-ServiceChanges, GTFS-BoardingRestrictions, GTFS-Flex have all been overhauled after conversations that happened publically. Yes, we do try to prepare a good enough draft before sharing it publicly, to avoid wasting the time of stakeholders who will not read 10 times an evolving draft. 

Becoming a member is free for non-profit and governmental agencies, and is indeed 1.2k EUR for for-profit (those are the non-voting member rates, so you’re not electing the board indeed). It doesn’t give you more right to discuss or suggest additions. It keeps you more in the loop. Anyone that wants to have more information can contact us and we’ll be more than happy to share more about our work and how to involve them. 

Becoming a member gives you access to workshops, but nothing is decided during workshops and the first one is always free. We want to have stakeholders that bring something to the table and so far, we have achieved that with those who came to our North American and European workshops. 

We have never refused to share any information with you because you haven’t paid.

> “I see. MobilityData is doing all this work. It does not feel this way at all. Or does it? And can we only observe?”

I’m unsure if you’re suspecting us of doing all the work of drafting the extensions and leading the conversation (and it would be bad)? Or if you’re suspecting us of not doing the job? Or, oddly, both?

The overhaulings that happened publically in the past (again, I’m speaking about GTFS-Flex and GTFS-ServiceChanges, to name only them) seems to be showing that, based on public feedback, we went back to the canvas and tried again. So no, I don’t think you can only observe. Everytime, we took into consideration the comments we received from each stakeholder in order to reach a valid consensus including every stakeholder.

As you know, the GTFS governance follows a bottom-up model. The organizations producing and consuming data drive the addition of specification features. New features are tested in software prior to adoption to ensure that they are practical and grounded in real use.

> “It feels like MobilityData is positioning itself, in the same position as OSMF: If you are not with them, you are against them. And you may not appear on their outlets, or not be consulted in their conversations. “

We have no experience interacting with OSMF, so I cannot answer that part. I still don’t understand what you mean by saying “If you are not with them, you are against them”. Regarding “not appear on their outlets”, you declined coming to the workshop, and haven’t reached out to us since. Therefore yes, we haven’t included you in the invite for the Annual General Meeting, and we were planning to politely re-invite you next year, expecting another negative answer. You haven’t tried to contact any of us, asking to be more involved in any part of our work. We have tried to do our best to answer the constructive sections of your comments on GTFS’s GitHub.

> “if these key consumers do not update their software - or do partial implementations - it would mean that travel information is wrongly presented hurting the entire ecosystem“

As far as I know, all the changes that MobilityData proposed to GTFS so far have always been backward compatible. E.g. If you read a dataset including GTFS-Pathways extension, you will not get less data that you were getting before this extension was added.

> “I would like to have an open discussion if we as ecosystem should allow a third party - a lobby organisation - that is not a technical implementer of data to draft marjor changes that would require key consumers to update their systems. “

I don’t think we have ever requested you to update your system. Which section of which proposal we made is generating an issue with your data? Regarding the question of whether or not we are a “lobby organization”, I’m unsure of what you mean by it (“lobby” has many meanings, and can be used to describe a factual reality — advocating for a specific vision on a specific topic — or is sometime use as a broad political accusation of being a shadow power), In the section 1 below I’m sharing as many facts as I can about who we are (members, board, vision, mission, bylaws, scope) and at the end I’m trying to see, depending of which meaning you put behind “lobby”, if we could be defined as such.

More broadly, yes, MobilityData is working on making data related to mobility move forward. We try our best to be listening to industrial needs, answering them with draft of proposals, leading conversations around those draft, then toward their beta implementation by stakeholders, and finally toward their official adoption as part of the spec. The project started in 2015 and has improved a lot since then. Becoming a non-profit was a long process, and it’s only since November that we had the resources and frameworks to hire full time transit experts, eager to get feedback from industry stakeholders like you, and dedicated to improve our processes on specification work. 

Now, since you’ve open the question of who we are and what we do, let’s take the time to review that.

# 1. Who we are legally

Legally, we are a “Canadian non-for-profit Corporation” as defined by the Canadian “Non-for-profit Corporation Act”.

About our governance, in short, as Executive Director, I’m leading the whole staff, and I’m hired & responsible toward our Board of Director (section 1.1), which is elected by our voting members (section 1.2) during our Annual General Meeting of members, last one was on January 15th in DC, to which all the stakeholders which came to our workshops were invited (aka not only our current members), and to which 16 stakeholders came. Our vision, mission and scope are described in section 1.3. All of our constitutive documents are public, I’ve listed them in section 1.4. 

## 1.1 The Board of Director

Our Board of Director is:

composed of persons working in non-profit;

composed of persons involved in the mobility world; and,

international.

### Elsa Bruyère, Chair (Montréal, Canada)

She is French & Canadian, she lives in Montréal (Canada) and works in different projects including La Fabrique des Mobilités Québec (FabMob QC). Stefan, you likely know the French counterpart of them, La Fabrique des Mobilités (FabMob), with Gabriel Plassat.

LinkedIn: https://www.linkedin.com/in/elsabruyere/

FabMob QC: http://lafabriquedesmobili tes.fr/qc/ (she is the one of the right of Gabriel on the picture)

### Felix Delattre (Berlin, Germany) 

He works for Humanitarian OpenStreetMap Team (HOT) and was involved in informal public transit mapping back in the days when it started in Nicaragua, and is still at a certain extent involved in the DigitalTransport4Africa project.

LinkedIn: https://www.linkedin.com/in/felixdelattre/

DigitalTransport4Africa: https://digitaltransport4africa.org/about-us/

### Britta Gross (Orlando, Florida, USA)

Works for the Rocky Mountain Institute (RMI), a Colorado-based non-profit working on helping to shift the economy toward sustainability. They incubated us from 2015 to 2019. Personally, she worked around 7 years in Germany for Opel, then 17 years for General Motors in the US, therefore she is coming from the car-industry-part of the mobility world.

LinkedIn:https://www.linkedin.com/in/britta-gross-956bb0b/

RMI page: https://rmi.org/people/britta-gross/

## 1.2 The Members

We currently (as of Feb. 27 2020) have 29 members, including 11 voting members.

The full list will be public hopefully on Tuesday. We have been through months-long processes with some of those stakeholders to be allowed to say “[Such company] is a member of MobilityData”. We are finally getting at the end of it (and, TBH, we are pretty excited by next week). Also, the level of sponsorship of each of those members will be public, grouped “sponsorship levels” (as defined in the “Role and Responsibility” document, see section 1.3).

What I can say right now is that among our 29 members, we have:

10 public transit agencies, from Canada, France, Spain, Sweden and the US.

9 software vendors, from Canada, France, the UK and the US.

5 mobility apps, from Canada and the US.

A few non-profit involved in the mobility industry, from the US & France.

As previously mentioned, our last General Meeting was on Jan 15th in Washington DC, 16 stakeholders attended (it was open to non-members). Every stakeholder who attended one of our workshops was invited.

We created the difference between voting members (called “Core Members”) and non-voting members (called “Regular Members”) to allow both:

Observers, which can for a small amount (free for non-profit, 1.2kEUR for for-profit) show support, come to our yearly event and get the updates of our projects. The 1.2kEUR fee — which is a yearly fee — being lower than the fee that some events ask for a two days event only.

Voting members, which are going to provide a higher amount of money (we still need ressource), and which get the power to vote for the Board in exchange.

All of that is described in the Role and Responsibility document (see section 1.4).

For the non-members, I’m gonna quote still the same document (Role and Responsibilities), which states of “Role and Responsibilities Vision”:

> MobilityData IO aims to help all of the stakeholders of the mobility industry to improve their data, regardless of their relationship with the Organization. To work toward this common goal and ensure MobilityData IO has sustainable funding, MobilityData IO offers forms of value only to members, in addition to what is provided for the world.

Therefore, all of the specifications or documentation that we are producing are public and open source. To choose on which project we are going to work, we do prioritize the needs of our voting members (since, they are the one paying our salaries), and we do aim to make a “first round” of feed amongst them, before sharing with the general public. It gives us a sampling of feedback from a diverse category of stakeholders, and our goal with that process to reduce the rewrittings that we faced in the past (GTFS-Flex, GTFS-ServiceChanges), so avoid exhausting the implication of the public community. We are struggling to get some new stakeholders involved in the GTFS conversations, we value their time, and therefore we would like to involve them not too soon and not too late.

You’ve asked us if we were a “lobby”. There are many definitions of that word, and depending on the language, it sometimes has a descriptive meaning and sometimes a negative political meaning, so it’s hard for me to provide a factual answer to that question.

The facts that I can share are that:

MobilityData is a non-profit (it didn’t have to be, and it wasn’t obvious when I joined).

Its membership isn’t limited to private companies, and it currently has — as voting members — a nice balance of public public transit agencies (3 over 11), software vendors (4 over 11) and mobility applications (4 over 11).

The bylaws we wrote in which those voting members are choosing the board, which can fire the ED if they want to.

I could have easily decided to create a for-profit, to split the shares between Aaron Antrim (Deputy Executive Director) & I, and to keep the “power” in our hands (and the value). We decided to put this power & value in the hands of our members, of the industry, because we believe it’s the right thing to do. To be honest, it was — and still is — a frightening thing to do. But we believe it is the right thing to do. 

## 1.3 Vision, Mission and scope

For the vision and the mission, they are defined in our by-laws, so let me just provide you the relevant extracts:

Article II, Section 1, Vision:

> The Corporation envisions a world where more people choose to travel without driving alone, including by walking, biking, public transit, on-demand transit, and shared cars. It is easy for travelers to find, understand, pay for, and use non-drive-alone transport modes.

Article II, Section 2, Mission:

> The Corporation enables interoperability in transportation systems by identifying interests shared by stakeholders, responding with data formats and shared data infrastructure, and supporting the adoption of standardized data practices worldwide.

I believe they are clear, so to come back to your question of if we are a lobby, let’s understand that word with the definition of “seek to influence (a politician or public official) on an issue”. Politicians and public officials are not the type of stakeholders we interact the most with. We do try to show to public transit agencies the value of having high quality data. On the political level, we had state-level and federal-level representatives at our NYC workshop, and I did have meetings at the European and French level, during which I did explain our vision and mission described above. I let you see if it is what you’ve meant by “being a lobby”

I don’t have the feeling that this vision and this mission are particularly conflictual within our industry.

About our scope(s).

We have an international scope, which brought us (outside of North America & Europe) to Australia, Japan, Ivory Coast and India in the past 12 months. One of our colleagues is currently in New Delhi, and we just decided to postpone the Workshops we were planning to have in Tokyo in April, because of the coronavirus.

We are working on both public transit and shared mobility. We have been working on GBFS last year since we had been selected by GBFS owner, NABSA (North American Bikeshare Association) to improve it and lead the community discussion, and we plan to keep on working on it in 2020. We had conversations with related specifications (about parking, road closure, indoor mapping) but haven’t worked per se on those subjects so far.

About the specifications themselves, we see them more as a mean then as a scope. We worked so far on GTFS and GBFS. Our goal being passenger information (“It is easy for travelers to find, understand, pay for, and use non-drive-alone transport modes.”), the question of which spec is used to provide this information is rather secondary. We worked on those specifications because they are already adopted, because there was an industrial need, and because our members asked us to. We do not see ourselves as the “GTFS Foundation”, both because we do not have the exclusivity of proposing changes on the proposal (we haven’t changed the voting process), and because we do not see GTFS as an end-goal. Passenger information is.

I’ll go in further details about our relationship with NeTEx in the relevant section. But, as spoiler, I can say that the success of the NeTEx would/will be totally aligned with our mission and vision, and that if it successfully replaces GTFS in 5 or 10 years, we would see that as a huge win for the industry. That said, we hear a short term need for extensions of GTFS by our members, and we are addressing this need. We believe that NeTEx has way enough strength in itself, so that its success doesn’t require any undermining of the GTFS ecosystem. We even believe that the GTFS ecosystem, by showing the value of public transit data, by building an industry around it and by teaching to public transit agencies its value, will be the historical foundations on which NeTEx will be able to succeed, and that it was the lack of such foundation, of such ecosystem, which lead the failure of the US version of the NeTEx, called the TCIP, in the 2000s.

By fostering the mobility data community and ecosystem, we are putting everything in place to ease the transition, in Europe, to NeTEx. I’ll explain more about that in the relevant section.

## 1.4 Legal documents

By-laws: https://docs.google.com/document/d/1Q2kMbsaIpEQC1_ZILvCL3EXJnK1RRuQk

Role & Responsibilities: http://bit.ly/mobilitydata-roles-and-responsibilities 

# 2. What have we done so far

MobilityData is the continuation of the GTFS Best Practices project (Section 2.1), then we created GTFS extensions (section 2.2), we created OpenMobilityData.org through a partnership with TransitScreen (section 2.3), we worked on GBFS through a contract with NABSA (section 2.4), and we organized workshops (section 2.5).

## 2.1 GTFS-Best Practices

MobilityData started as a two years (2015-2017) project by the Rocky Mountain Institute, it was called back then “Interoperable Transit Data Project” IIRC. Back in those days I personnaly joined as the Transit app representative. The result of the work is available on the following website: https://gtfs.org/best-practices/. The list of organizations involved is at the bottom. You can see this project as the embryo of MobilityData, and this list of members are the first stakeholders which have been involved. You can note that all the stakeholders back then were North American (Transit app & IBI being Canadian). We worked hard since then to involve European stakeholders (which is a success seeing our list of workshop attendees, and our list of members), and we are currently working on expansion in East-Asia & India, as hinted above, and on informal transit in Africa.

## 2.2 GTFS extensions

We did answer some stakeholder’s requests about extension of GTFS. Some of them includes:

The description of public transit station, requested by MBTA, with agencies working on producing the data include MBTA (Boston), MTA (NYC), SFMTA (SF), STM (Montréal), and Google & Transit consuming it. It’s the GTFS-Pathways extension.

The description of stop names as they should be said, called GTFS-TextToSpeech. Portland (TriMet) is the only producer I know so far, and Transit app is the only consumer I know so far.

GTFS-Translations, which is a standardization of Google’s private extension.

Some others, to which you contributed for a few of them.

Some others are still in the pipelines. We are working on improving our consistency in the process of drafting them. Some proposal that we thought being still at an early stage move faster that we thought, like GTFS-Vehicles (or “GTFS-VehicleCategories”, or “GTFS-VehicleTypes”, TBD), when some others are being discussed since quite some time without moving forward (GTFS-Flex v2, GTFS-Fares). The full list will be on the new website, and we have now somebody working full time on the proposals, who will be in charge of keeping track of the process (Tim, with who you already interacted I think).

Our first employee was hired in September (so 5 months ago), and we’ve done our best to provide the best level of usefulness to the industry, through the two workshops decided, planned, organized and happening in the fall, the GTFS spec work, the GBFS spec work, and all the legal implications of creating an organization. The first months, as always for an organization, were intense. There is a lot of space for improvements, we know it, and we are working on putting in place a better process to share the proposals at the right moment. I understand how some of them could have tasted “pre backed” for some stakeholders. We sometimes shared too early (like GTFS-Flex v2), forcing overhauling when most of the stakeholders had already exhausted the time they could spend on it. We sometimes faced multiple overhauling (like GTFS-ServiceChanges), exhausting even more the industry. And sometimes we shared too late, like for GTFS-Vehicles, when we should have shared earlier. 

## 2.3 OpenMobilityData

Quentin Zervaas, the founder and coder of TransitFeeds.com, emailed every contact he had in the industry at the end of 2018, saying that either somebody will take over TransitFeeds.com, or he will let it die, because he didn’t have time to spend on it, and the change in Google Maps API rate was making it too costly to keep alive.

Many stakeholders forwarded us his email, seeing us as the logic home for such repository. Since we had no legal entity back then (we were still incubated by RMI), we partnered with TransitScreen to create OpenMobilityData.org and to keep the project alive. Thanks to the support of TransitScreen, the maps of the website are now using OSM and not Google Maps, solving the API rate issue.

Now that we are a legal entity, we are doing the paperwork to fully be in charge of OpenMobilityData, and are working on open source improvements of it.

Jan. 2019 Press Release: https://www.prnewswire.com/news-releases/transitscreen-and-mobilitydata-launch-openmobilitydata-building-the-openstreetmap-for-transportation-300776016.html

# 2.4 GBFS

NABSA (the North American Bikeshare Association) was looking for some help to improve GBFS (General Bikeshare Feed Specification) that they created, to create a governance and to foster the community around it. We answered the RFP, and based on the success we were having with GTFS, they selected us.

We organized shared mobility data workshops, one in Indianapolis during NABSA annual summit, and another one outside of NABSA’s scope, in Paris in December. Both have been successes, and both showed interest by the shared mobility industry to have an organization like ours helping them moving data format forward.

# 2.5 The workshops

I dislike describing events as accomplishment, since workshops are means and not goals. But the European workshops we organized in Paris, especially the public transit one, surprised me. I saw stakeholders from the same industry, working on the same continent, introducing themselves to each other by explaining what their company was, and what they were doing. I wasn’t expecting the European public transit industry to not know each other at this point. We had stakeholders from Canada, Czech Republic, France, Germany, Hungary, Portugal, Spain, Sweden, Ukraine, United-States, United-Kingdom.

I’ll speak again about that in the NeTEx section, but since I’m speaking about workshop, please note that we spent a few hours on NeTEx during this two days workshop in Paris, and a few stakeholders presented their work on NeTEx:

- Christophe Duquesne, on Transmodel & NeTEx.

- Emmanuel de Verdalle, from ITxPT, on the PSA.

- Julie Williams, from Traveline UK, on the UK implementation of NeTEx (and the fare extension that Nick wrote).

If you want NeTEx to succeed, I do think that conveing those stakeholders (PTAs, software vendors, mobility apps, member states data portals) in the same room is the way to go. I know that the PSA *will* work on that. I can’t wait to see it being in motion. On our side, this is what we have done so far.

# 3. Our 2020 Roadmap

We have a few things in the pipeline for 2020, on the spec work (3.1), the tooling (3.2), the community fostering (3.3).

## 3.1. The spec work

### GTFS

As I already stated, we are going to keep on answering industry needs regarding GTFS extension.

You have read about GTFS-Vehicles/VehicleCategories/VehicleTypes.

We hear a broad need for fare specification. We have a proposal on the table. We have quite a few stakeholders commenting on it. We hope to get some early adopters this year.

GTFS-Flex v2 and GTFS-ServiceChanges may get some partial implementations. Some US state DoTs have expressed interest for GTFS-Flex for countryside agencies, so things may move faster than expected.

A few smaller extensions will likely move forward, like GTFS-BoardingRestrictions.

### GBFS

On GBFS, a few subjects are in the pipeline, but I’m unsure if you have an interest for those. Geofencing for parking and speed of vehicles. Description of the different types of vehicles (e.g. bike, scooter, car…).

## 3.2 Tooling

### GTFS Validator

A few stakeholders told us about the lack of agreement on what is a “valid” GTFS, and the fact that every validator has its own rules, which leads agencies to produce GTFS “valid” according to their own tools, but then rejected by some GTFS consumers as “invalid”. We offered to define, code, host and make available an open source canonical validator, and in both workshops (NYC & Paris) we heard interest and support for such a project. So we’re working on it.

### Mobility Database

A few stakeholders told us about the lack of link between GTFS datasets. We cannot define that a stop is shared between two agencies. I know that in Europe there is (or there is meant to be) IFOPT, but such a thing doesn’t exist for different reasons outside of Europe. We have discussed the project of defining a Mobility Database, which would provide stable identifiers for public transit entities (not only stops, but also fare agreements, code sharing…).

Other non-profits have said that they were planning to work on the same thing, but that since they are geographically limited they cannot host a world-wide instance, so we are planning on working together.

Again, I included a few NeTEx stakeholders in that conversation, and they expressed interest in that. The decision of which data model to use in the database isn’t solved yet. Many of us (including us) would lean toward transmodel, because having the finer granularity of transmodel would be easier to export in both NeTEx and GTFS, than the coarser granularity of the GTFS. But, again, if the spec isn’t public nor open, we cannot rely on it.

### OpenMobilityData.org

We are planning to add a hosted instance of GTFS Validator on OpenMobilityData.org, and some sync with other equivalent projects, like TransitLand. 

I have discussed with ITxPT, enRoute and the DG MOVE the idea to add NeTEx support to OpenMobilityData, using the existing code of open source projects like Chouette and/or OTP. The goal would be to both convert any NeTEx uploaded into GTFS (with a major loss of data and granularity obviously), and each GTFS uploaded into a light NeTEx. We expect that some GTFS consumers would slowly be frustrated to consume a degraded version of the (NeTEx) dataset outputted by the producer, and that if they need more granularity, some of them switch to ingest directly NeTEx datasets. And that would also be IMHO a powerful way to spread the world about NeTEx outside of Europe. 

## 3.3 The community fostering

We have a few workshops in the pipeline:

North American Public Transit workshop in San Francisco in July

European workshops (both Public Transit & Shared Mobility) in Berlin in September

North American Shared Mobility workshop in Guadalajara in October, during NABSA’s summit

East Asian workshops (both Public Transit & Shared Mobility) likely in Tokyo in November

On an everyday bases, as you know, we do our best to foster conversations on:

GTFS & GBFS GitHub repos

GTFS-changes Google Group

MobilityData’s public Slack

We are also likely to pilot some smaller event, with a narrower focus, but it’s still to be defined.

# 4. MobilityData and NeTEx

In many comments, scattered in different GitHub thread, you’ve mentioned Transmodel & NeTEx. For example:

> “Indeed, your thinktank tries to reinvented the wheel, introducing new terminology and new data models, while not improving or implementing best practises on the same topic. http://www.transmodel-cen.eu/category/tutorials/” (15 days ago, so 12 Feb 2020, PR#200)

> “Elephant in the room: Transmodel, CEN-NeTEx” (19 Dec 2019, PR#195)

Let’s take some time to go through the implication that I personally then MobilityData, had with Transmodel & NeTEx (section 4.1), then our current position toward it (section 4.2) and our roadmap on this subject (4.3).

## 4.1 MobilityData and Transmodel & NeTEx

Here is personally how I got involved with NeTEx. 

I discovered NeTEx, and met Kasia (and IRC also Christophe) in June 2017 at the French DoT, where they explained to me the NeTEx project.

In October 2017, during RMI’s workshop in NYC, I personally gave a 5 minutes presentation about Transmodel & NeTEx to a room of North American stakeholders of the mobility industry. I believe that I likely was the first one to speak to them about this project. I was still working at Transit app back then, and I wasn’t even planning to join RMI’s project before this workshop.

In December 2017, I requested authorization (and obtained it) from my then employer, Transit app, to let me go one week in Paris to attend a NeTEx workshop. This is where you and I met. I had longer conversations with Kasia & Christophe at this point.

In April 2018, I was back in Paris, continuing the conversation with the French stakeholders of NeTEx.

In October 2018, only a few months after I started working for MobilityData (as an RMI’s project back then), you and I had a meeting, to discuss those questions, and I shared with you my vision.

I made a few other back and forth between Europe and Montréal in 2019, trying to better understand the strengths, challenges and — in my humble opinion — complementarity of the two projects: GTFS & NeTEx. I had a few meetings with Nick (in London) and Christophe (in Paris), discussing this question of complementarity.

In Fall 2019, you are the one who informed me that a one day meeting was happening in Brussel, at the DG MOVE (The European DoT), to speak about NeTEx and the National Access Point. It’s thanks to you that MobilityData has been looped back directly in the heart of those conversations.

I had no time back then (one week later I was flying for the State of the Map Africa in Abidjan), but I still flew to Brussel for the one day of the meeting, landing after a red eye at 9AM and arriving at the meeting 10AM. But didn’t want to miss this opportunity to better understand the state of the project, and to discuss the challenges that we were facing with NeTEx.

I’ll explain in section 4.2 what I have said during that meeting, that you’ve attended, and which constitute most of MobilityData’s position on this subject.

Since then, as I already mentioned, we took a few hours in our December European Public Transit Workshop to discuss NeTEx state, with interventions from:

- Christophe Duquesne, on Transmodel & NeTEx.

- Emmanuel de Verdalle, from ITxPT, on the PSA.

- Julie Williams, from Traveline UK, on the UK implementation of NeTEx (and the fare extension that Nick wrote).

## 4.2 MobilityData position on NeTEx & Transmodel

As I stated above: 

> “The success of the NeTEx would/will be totally aligned with our mission and vision, and that if it successfully replaces GTFS in 5 or 10 years, we would see that as a huge win for the industry. That said, we hear a short term need for extensions of GTFS by our members, and we are addressing this need. We believe that NeTEx has way enough strength in itself, so that its success doesn’t require any undermining of the GTFS ecosystem. We even believe that the GTFS ecosystem, by showing the value of public transit data, by building an industry around it and by teaching to public transit agencies its value, will be the historical foundations on which NeTEx will be able to succeed, and that it was the lack of such foundation, of such ecosystem, which lead the failure of the US version of the NeTEx, called the TCIP, in the 2000s.

> By fostering the mobility data community and ecosystem, we are putting everything in place to ease the transition, in Europe, to NeTEx.”

We believe that a data format, whichever it is, is like a dictionary & a grammar. Creating the data format is the easy part, it’s like creating a new language. What is complex is turning this seed into a plant, and turning a plant into an ecosystem. What is complex is creating a litterature, a culture around that language.

The CEN (European Committee for Standardization) is doing for NeTEx part of what we are doing for GTFS, but a part only. They are not the one conveying workshops, they are not building tools, they are not building documentation nor tutorial. They do not send anybody in India or Japan trying to understand the roadblockers for the production of open public transit data. We are.

In Europe, the PSA is in the hands of ITxPT, which has a strong member-base in the operational part of the public transit data, but a weaker one in the passenger information side of things (e.g. they do not have any mobility app as member, we have a few of them). We have opened (#spoiler) discussions with them to see how we could work together. 

But, as you know, the issues that we are facing toward Transmodel are with the license, which is a huge issue.

Firstly, we cannot share a URL with the official specification to anybody. Stakeholders must pay to buy the specification. I voice that issue in Brussels, and I wasn’t the only one. This should be solved if we want to move forward. 

Secondly, even if the spec was public, it is still not open. If we (MobilityData) were reading the specification, and then inspiring ourselves (voluntarily or involuntarily) when working on GTFS, or even only being suspected of inspiring ourselves (since, likely, they are not 20 ways to describe a bus or a schedule), we could be sued, accusing us to steal CEN property in the GTFS extension. GTFS is an open format, anybody can use, reuse, change, alter, extend or whatever the specification, without any fees nor obligations. But as with everything, it still has an owner (which owns, for example, the name). And you know that this owner is still Google, for historical reasons. It doesn’t change anything in everyday work, but if we were to be accused to inspire ourselves of Transmodel in our work on GTFS, it would be accusing Google of stealing IP from the CEN, and you’ll understand why we don’t want to deep our toes in those waters.

The DG MOVE knows about those two issues, and said they are working on it. Solving them would greatly simplify our work.

## 4.3 MobilityData’s roadmap on NeTEx & Transmodel

We have already been through a few projects, but let’s recap them here.

### OpenMobilityData.org

We are discussing adding NeTEx support to OpenMobilityData, to host, convert (in both direction) and validate NeTEx datasets.

### Mobility Database

We are discussing using Transmodel as model on the Mobility Database, and currently the biggest issue is, again, the legal one.

### The workshops

We did, and we are still planning to do, workshops which will convey the European public transit stakeholders. We did keep time for NeTEx conversations, and we are planning to keep on doing it in the future.

### MobilityData’s implication in the CEN

Back in 2017, the CEN offered me to involve myself more in the CEN conversation. As you know, you have to be designated by the normalization body of your country (e.g. AFNOR in France) as a delegate, to attend the CEN meetings. Since Canada is not a E. U. member, and is not a member of the CEN, none of our transit experts can be sent through that mechanism. The CEN offered me to get ISO affiliation in Washington DC, and to be sent as ISO representative to the CEN meetings. As explained above, the only thing which is currently preventing us from doing that is the license issue.

# Conclusion (finally)

It took me a few hours to write those 16 pages, describing as precisely as possible who we are, what we did and what we intend to do. They obviously would be much more things to say, but I assume that a 16 pages overview is a long enough one.

If some questions that you have are still unanswered, please ask them. The only one that I couldn’t answer here is the list of our members and their level of sponsorship, since we are still waiting for some approval for disclosure, but we should be able to get them for early next week. 

Thanks for opening that thread.

Léo Frachet, as Executive Director of MobilityData