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
Up until now, we’ve spoken about the score being calculated from a starting point to a destination. In reality, however, it’s often important to have more than one destination. For example, it’s important to have several bakeries available in case one doesn’t meet quality standards or has inconvenient opening hours.
The model always evaluates three alternatives to the fastest option, which are weighted according to category. The weighting function is as follows:
e^{-lambda * (i-1)} with i = 1,2,3
This results in the following weightings, depending on lambda:

Profile and Modes
To get from A to B, you select a mode of transportation. In the simplest case, you can walk, but other modes are also possible, such as driving, biking, or taking public transportation.
To make it easier to use, mobi.mapr distinguishes between profiles and modes. A profile is a variant of a mode. Here’s a simple example: In mobi.mapr, “cycling” is a mode, while “road bike” or “cargo bike” would be profiles. Strictly speaking, it should therefore be called “mode-profile,” but the short form is used instead.
A profile involves many subjective factors. Examples include the maximum speed the bike can reach in different configurations, or the time it takes to park the bike—which takes longer with a cargo bike than with a trekking bike.
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
If you want to aggregate multiple categories, it is important to give them different weights. After all, not all routes lead to places where people go for daily essentials, just as not all routes lead to children’s playgrounds.
mobi.mapr therefore uses personas as a way to synthesize these values. Version 1.0 therefore also uses the personas defined in Mobility in Germany.
This makes it possible to determine, for each municipality, county, or state, which categories are relevant and to what extent.
For more information on personas, check out the blog post “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!
