mobi.mapr aims to make mobility tangible. Mobility is a multifaceted yet complex topic. It is therefore inevitable that mobi.mapr involves a great deal of complexity that is not always easy to grasp.
This documentation provides an overview of the concepts and the model behind mobi.mapr. If you still have questions, feel free to check out the FAQs or contact us!
mobi.mapr in Posts
To mark the launch of mobi.mapr in the fall of 2025, we prepared a four-part blog series covering key concepts. It provides a good introduction to the platform’s methodological foundations.
Mobilität durch verschiedene Augen sehen
Dieser Beitrag ist Teil 4 von 4 der Dokumentationsreihe, wie der mobi.mapr funktioniert. Unten im…
Von der Personengruppe zur Persona
Dieser Beitrag ist Teil 3 von 4 der Dokumentationsreihe, wie der mobi.mapr funktioniert. Unten im…
Wie Mobilitätsqualität regional vergleichbar wird
Dieser Beitrag ist Teil 2 von 4 der Dokumentationsreihe, wie der mobi.mapr funktioniert. Unten im…
Wie gut funktioniert unsere Alltagsmobilität?
Dieser Beitrag ist Teil 1 von 4 der Dokumentationsreihe, wie der mobi.mapr funktioniert. Unten im…
mobi.mapr examines how easily and efficiently people can get around in their daily lives and uses a scoring system to make mobility quality measurable and comparable. The results provide a solid foundation for understanding how to design sustainable and livable cities.
You can read below about exactly how this works. mobi.mapr explains step by step which factors are included in the assessment, how data is collected and analyzed, and how this results in an objective picture of mobility quality. This provides a transparent and clear understanding of how complex information is transformed into clear, actionable insights for urban planning and mobility development.
Do you have questions, feedback, or just want to chat with us? Feel free to email us anytime at mobimapr@bw-im.de—we look forward to hearing from you!
The basic concept behind mobi.mapr is closely aligned with the study Mobility in Germany (MiD), but it can be easily expanded.
Version 1.0 focuses on everyday mobility (i.e., errands, shopping, and leisure activities), as these account for the majority of daily trips. Work-related mobility, education, and accompanied trips are planned for future versions.
Info
mobi.mapr is not a tool for meter-precise planning, as an on-site analysis would be. With a hexagon resolution of approximately 200 meters, the goal is clearly defined: to assess regional mobility quality without losing sight of the local context.
“Traditional” planning applications are ideal for modeling local situations. While traffic surveys, measurements, and other techniques can be used to develop location-specific models, they generally lack a “bird’s-eye view.” For example, is there little traffic on a bike highway because it is not sufficiently developed, or rather because the path leads to nowhere?
mobi.mapr, on the other hand, takes a human-centered approach. At the end of every journey lies an activity that people want to reach. Mobility means opportunities. If a person cannot access these opportunities using a particular mode of transportation, their mobility is limited and must be compensated for by another mode, for instance.
The philosophy of bwim is deeply rooted in mobi.mapr. For further information and other projects, we recommend visiting the bwim website.
General
Function
At its core, mobi.mapr is an analysis showcasing accessibility, but does this by taking subjective factors into account. This can be explained using an example.
A person is at home and wants to go to the next bakery. This bakery is either 12 minutes away by foot, 5 minutes by bike, or 8 minutes with the bus. With a standard accessibility analysis, taking 5 minutes with the bike would be deemed the quickest mode. In mobi.mapr additional factors are included in the scoring.
The result is an adjusted time, which is explained in more detail below. This is calculated and weighted for all modes and activities, and finally compared to the average time. This index is graded, resulting in our SIGMA score on a scale from A to F.
Places und Activities
At the end of every trip, there is an activity. Whether it’s grocery shopping, the commute to work, or getting an ice cream. This journey to the activity generates the traffic we know.
A location is the physical manifestation of an activity; for example, the location for the activity Bakery is “Café Bäckerei am Schloss”.
Defining an activity is no simple matter. Is a bakery a place where you can buy bread rolls, or is it more of a place where you can have a cup of coffee? The mobi.mapr uses the classification from OpenStreetMap. Other classifications, such as those used by Google Maps, Apple Maps, or Overture, have proven unsuitable for this purpose.
Categories
Since a person engages in more than one activity, a logical grouping of activities is needed. Such a grouping is called a category. For example, if an activity is “supermarket,” a category might be “daily needs.”
This generalization makes it possible to build on well-known studies, such as Mobility in Germany, by translating the abstract activities used in those studies into actual activities seen in the real world.
Each category consists of more than one activity, each of which may have a weighting. For the “daily needs” category, a supermarket is more important than a bakery, in this case.
In addition, the categories influence the weighting of the routes for each activity.
Weighting
Weighting
Bisher wurde immer davon gesprochen, dass der Score von einem Start zu einem Zielpunkt berechnet wird. In der Realität ist es aber oft wichtig mehr als ein Zielpunkt zu haben. So ist es beispielsweise wichtig mehrere Bäckereien zur Verfügung zu haben, falls eine qualtitativ nicht ausreichend ist oder mangelhafte Öffnungszeiten hat.
Das Modell betrachtet immer drei zwei Alternativen zur schnellsten Option, die je nach Kategorie gewichtet werden. Die Funktion für die Gewichtung ist die Folgende:
e^{-lambda * (i-1)} mit i = 1,2,3
Das ergibt die folgenden Gewichtungen, je nach Lambda:

Profile and Modes
Um von A nach B zu kommen benutzt man einen Modus. Im einfachsten Fall geht man zu Fuß, es sind aber auch andere Modi denkbar, wie Auto, Rad oder ÖPNV.
Für eine einfachere Verwendung wird im mobi.mapr zwischen Profilen und Modi unterschieden. Ein Profil ist dabei eine Variante eines Modus. Ein einfaches Beispiel: Fahrradfahren ist im mobi.mapr ein Modus, Rennrad oder Lastenrad wären Profile. Korrekterweise müsste es daher Modus-Profil heißen, die Kurzform wird stattdessen verwendet.
Ein Profil bringt viele subjektive Parameter mit sich. Ein Beispiel sind hier die Geschwindigkeit, die das Fahrrad in den unterschiedlichen Varianten maximal erreichen kann oder die Zeit, die benötigt wird, um das Fahrrad abzustellen – bei einem Lastenrad dauert das länger als bei einem Trekkingbike.
Regionalization
The quality of mobility also always depends on a person’s location. If they are in a rural area, they tend to engage in different activities than in the city, and the average travel time varies.
mobi.mapr uses the RegioStaR7 classes, which divide Germany into seven different spatial types.
Based on these RegioStaR classes, different reference values are used, and the categories for personas (see below) are organized differently.
For more information on regionalization, check out the blog post “How to Compare Mobility Quality Across Regions”
Personas
Möchte man mehrere Kategorien aggregieren, ist es wichtig diese zu gewichten. Schließlich führen nicht gleich viele Wege zu Orten des täglichen Bedarfs, wie zu Kinderspielbereichen.
Der mobi.mapr verwendet daher Personas als Mittel diese Werte zusammenzusetzen. Inder Version 1.0 werden daher auch die Persona aus der Mobilität in Deutschland verwendet.
So kann für jede Gemeinde, Landkreis oder Bundesland betrachtet werden, welche Kategorien in welchem Maße relevant sind.
Mehr Infos zu Personas findest du im Blogbeitrag “Von der Personengruppe zur Persona“.
Spatial Resolution
To determine mobility quality, routes are calculated. These routes have the locations of activities as their destinations but require a starting point. The smallest spatial unit used in Germany is the municipality. However, this unit is still far too large.
In mobi.mapr, the area is therefore divided into hexagons. The smallest hexagon has a edge length of 200 meters. It is therefore possible to represent mobility quality at the following levels:
- Hexagon
- Municipality
- County
- State
- County
- Municipality
Scoring
Once the routes have been calculated, a value must be derived from them. This value is called the Score in mobi.mapr and is, for example, 13 minutes.

Since mobility is typically compared relative to others, it makes sense to put this value into context. This context is the average travel time by regional class in the respective municipality. So if a trip takes 25 minutes on average, this value is below average. An index is created. It ranges from 0 to a maximum of 2, where it is capped for technical reasons.
To evaluate and finalize the results, a grade is derived from the index. This is divided into school grades, but to avoid confusion with the index, it is denoted by letters.
The intermediate steps are labeled with + and -. This is based on an exponential function, meaning that lower indices are weighted more heavily than higher ones.
The evaluation is based on the following criteria. If the index is greater than 100%, it is rated as unsatisfactory (E). The difference between “Good” and “Satisfactory” is 50% of the index.
This results in the following function: h(x)=0.2511169*1.122178^(x). For each x, the grades can be assigned in half-step increments; thus, x=1 corresponds to A+.
To ensure consistent notation, the symbol Σ (SIGMA) can be used at the end. It stands for Score-Index-Grade-Mobility-Accessibility. A municipality could therefore have a Σ B+.
Technical implementation
Frontend
The front end is an application written in Angular. PrimeNG is used as the framework. For maps, MapLibre and OpenLayers are primarily used. The project is rounded off with many small styling libraries.
Database
All data is stored in PostGIS, a derivative of PostgreSQL. This allows spatial queries to be performed directly on the data.
Backend
The backend is written in Python and uses Django as its framework.
Routing
The routing system is the most complex part of the application. The billions of calculated routes must be regularly updated and maintained. Most routes are calculated using the Valhalla Routing Engine, which is used for all walking, cycling, and driving routes.
We would like to extend our sincere thanks to MOTIS for their work on public transportation route calculation; they have succeeded in developing a remarkable routing engine that closely mirrors reality.
Do you have questions about mobi.mapr? Then feel free to check out the FAQ page or get in touch with us!
