MODI FAQ

This FAQ is continuously being improved and expanded and may change at any time.

Q: Why does SOSM oppose the MODI bill, isn’t improving the efficiency of our mobility infrastructure a good thing?

A: We have always supported making more mobility data available and suggested that it is one of the missing pieces to creating viable competing services to google and Apple. We are simply opposed to regulation that couples access to that data to use of the navigation data of a single market player.

Q: What is Verkehrsnetz Schweiz and why is it a problem?

A: Verkehrsnetz Schweiz is swisstopos new product entry in to the navigation data market.

Verkehrsnetz CH is a completely conventional set of geodata suitable for navigation and similar purposes just like the products Tomtom, Here, apple, google, OpenStreetMap and others have been creating since decades. As any of these players will attest to, aggregating data from multiple sources, applying quality checks, arranging for updates and so on is the name of the game, and not something that is unique to swisstopos product.

The navigation data market is healthy with many competitors to choose from even though most consumers use products from google, a further player with a “me too” product is likely not a concern for any of the other players or us.

Matter of fact we are a bit tickled by the fact that OSM it important enough that one of the key competitive features of Verkehrsnetz CH is that it will be available in an OSM compatible format so that swisstopo it can easily use it to push out OpenStreetMap of existing applications.

Realistically the market for such a product in isolation is small, however legally and technically coupling the access to the mobility data infrastructure to use of Verkehrsnetz Schweiz changes this equation and will tilt the playing field substantially to the advantage of swisstopo.

Q: Do you have an example why the coupling of MODI access to Verkehrsnetz Schweiz would be anti-competitive?

A: Consider the following scenario:
You are running a, hypothetical, e-bike rental service, and the bikes have OSM-based navigation devices. You want to use the federal government’s mobility data (MODI) to improve navigation, e.g., to avoid closures or traffic jams. As required, you must use the Verkehrsnetz CH to retrieve the relevant data. In other words, you either have to make additional efforts to continue using original OSM in your navigation systems, or you can simply get data from swisstopo in an OSM-compatible format and frictionlessly access MODI.

And if you want to (automatically) make the usage status of your bike docks available to everyone, since multimodal navigation systems can then, for example, direct users to a dock that still has bikes, you will of course also have to use Verkehrsnetz CH data to upload the data to MODI, even if you otherwise use OSM to manage your locations.

If the access to the MODI data were designed to be both technically and legally provider-neutral, no one would be favoured. As planned, regardless of if we provide workarounds for access in the future or not, there will always be additional friction and uncertainty as to whether it will work correctly and users will gyrate to using Verkehrsnetz CH because it is “guaranteed” to work.

Q: This is Switzerland, shouldn’t have any disagreements on the bill been worked out before it got to this stage?

A: Yes you would have expected as one of the few organisations that are directly impacted by the regulation we would have been addressed early. However not only were we not invited to the consultation phase and had to, after we had found out, submit our statement within a day, our concerns have not been taken seriously by any of the bodies we have contacted.

It has to be said that we are arguing a fine techno-legal point here and the importance may be lost on many. Not to mention that we are small voice compared to the many swisstopo receptions, handouts to consultants and not to forget the cantons expecting free money from the federation.

Q: Won’t this rein google in and provide more opportunity for small businesses to provide services?

A: swisstopo has naturally played the bad big tech card in promoting Verkehrsnetz Schweiz a quote from their “Faktenblatt Verkehrsnetz CH” promotional material:

Kartendienste wie OpenStreetMap oder Google verfügen über umfassende Verkehrsdaten. Diese sind jedoch nicht in jeder Hinsicht frei zugänglich oder sind mit kommerziellen Interessen verbunden, z.B. werden beworbene Informationen bevorzugt angezeigt. Zudem ist nicht immer transparent, woher die Daten kommen.

The reference to OpenStreetMap was removed after intervention by us, it however nicely illustrates the mind frame of the authors.

But naturally companies like google and apple are unlikely to be affected at all as they do not provide direct navigation data access and can, if they even want to use the MODI data over what they already have access to, hide this behind their APIs and likely will save money in the process.

A look over the border to Austria where more than a decade ago a similar project was passed in to law, doesn’t show any less use of google, it does show a distinct lack of products that use OpenStreetMap or other sources and instead a de-facto monopoly for certain sectors that is based around the GIP (Verkehrsnetz CH equivalent) and the VAO (semi-private MODI equivalent). It should be noted that the VAO services are not free, which is the likely longer term MODI scenario too.

Q: Where can I find the text of the bill and related material?

A: Documentation of the MODIG bill from the federal council

Q: Isn’t this all open data and therefore not a problem?

A: Most parts of Verkehrsnetz CH and MODI are expected to be available as open data. However besides that not guaranteeing that the terms will be compatible with OSMs distribution licence, there are carve outs that might actually require update commitments and similar that would not be possible to fulfil in an OSM context, see fossgis.de Stellungnahme zum Mobilitätsdatengesetz for a similar issue with German regulation.

More importantly, while the promise of open data is that it will fuel innovation and create more economic activity, that would require the publishing entity to not itself corner the market with its own products. There is no legal requirement in Switzerland for this, and as swisstopo shows, the main effect of allowing it to publish data on open terms now is that it is under substantially less pressure to justify its offerings on economic terms. “it’s open data” has literally become the universal excuse for all its activities.

As mentioned above there is some hope that we will be able to use the published data to shoehorn MODI compatibility onto an OSM data distribution if the legislator decides not to require a vendor neutral access. But by its very nature this will be a 2nd class, high friction solution.

It really shouldn’t matter if you are building your app or service on Tomtom, Here, google, apple, OSM or swisstopo data and services, the technology is there to make MODI vendor agnostic, what is missing is the political will to require it.

Q: What are SOSMs concrete demands?

A: SOSM demands that the MODI components Verkehrsnetz CH and NADIM are decoupled and that the bill requires geodata-provider agnostic access to NADIM.

We further suggest that the establishment of Verkehrsnetz CH is moved to a separate bill to allow an independent evaluation and decision on the merits of the undertaking.

Q: Doesn’t the bill require that the MODI is independent of market players?

A: Art. 6 a. of the MODI bill stipulates “Die MODI ist von den Marktakteuren unabhängig” (MODI is independent of market participants). However it then completely ignores that by any definition, including its own, swisstopo is such a market participant, and that Verkehrsnetz CH is a product that swisstopo is actively promoting on the market.

Not only has swisstopo positioned itself as a competitor to other mapping service providers in its promotional material for Verkehrsnetz CH, it provides map services to web developers in competition to other players, and even offers products to end users in competition to other market participants. See for example https://www.swisstopo.admin.ch/de/swisstopo-app

Statement on the draft bill for the Federal Act on Mobility Data Infrastructure

Today the Federal Council approved its proposal for a mobility data infrastructure law (MODI). While we support the fundamental goal of making mobility data more comprehensive and easily accessible, and emphasised this in our consultation response three years ago, this should not obscure what this proposal is also about:

  • financing the Federal Office of Topography’s entry into a market created over decades by private sector and civil society initiatives,
  • creating a market advantage for the Federal Office of Topography by linking MODI usage to their other data products – without any technical or economic necessity and without any discernible social added value,
  • introducing a de facto monopoly on navigation and related services following the Austrian model – with the result of less choice, higher costs for providers and users in the mobility sector and is a competition regulation misstep.

SOSM therefore continues to firmly reject the proposal in its current form. At the same time, we reaffirm our offer to cooperate with the Federal Council and the Federal Office of Transport to jointly develop a fair, market-oriented, and cost-effective solution.

More information can be found in the FAQs https://sosm.ch/modi-faq/.

Bergdietikon, May 14th, 2025

Proudly powered by WordPress

Two Important Tagging Proposals Passed, but Nobody Knows.

Browsing the German OSM forum today I noticed that the OSMAnd android routing app developers were asking the community for an opinion on which “lane” tagging proposal to implement. My first reaction was: well didn’t such a proposal pass just a while ago and why on earth don’t they know about it? But on reflecting a bit, I had to admit, that I probably really only happen to know that we have a fully functional lane tagging scheme by accident.

Our tagging proposal and voting procedure has often been belittled and is the target of many jokes. Myself being one of the larger offenders in that respect. It can be argued that for the typical “I need a value for tag X that doesn’t exist” situation it just leads to massive bike shedding instead of quick resolution. I have at times simply started documenting and using a tag completely ignoring the proposal process (see mofa).

However we have had two long ongoing disputes in areas that impact usability mainly for routing applications where a unilateral decision without community and developer buy in hasn’t worked: lane tagging and conditional restrictions.

While the effort to support the three or four different ways of tagging a cycleway in a style sheet  is small, expecting all routing applications to implement the 3 or 4 different lane tagging proposal was and is just unrealistic.The usual tiebreaker that the more sucessful in day to day use proposal wins (the voting with the feet principle) doesn’t seem to work in such situations. As we all know adoption and widespread usage of a tag in OSM is mainly driven by either being able to see it directly on a map or by it having direct effect on applications. Particularly with lane tagging this has led to a classical “hen and egg” situation were lanes have not been tagged because the tagging was not being utilized at all.

We now have resolution, as far as we can ever have resolution in OSM, in two significant areas of tagging. The missing piece of the puzzle seems to be simply to make our contributors aware of the change. A long time mapper that doesn’t follow the tagging list and has never mapped lanes is not going to magically look up the lane tagging guidelines the next time he adds a street, he will just carry on with his established way of mapping.

OSM lacks a method for actively getting this kind of news out to contributors. The closest we get right now is tweeting, but that only reaches a small percentage of the community and in the past hasn’t been used for such mundane news. I’ve done some thinking about extending the OSM API to include access to the users “inbox” and some kind of system wide message system  that could be used by editors to display such messages on start up. However until such a system is implemented and adopted by third party developers we will need to use Twitter and our blogs to get the message out.