Behind the Scenes

Rastplatz.app is more than a map of parking spots: behind it is our own infrastructure, our own data sources, and a deliberate choice to explain them openly. This page grows with every milestone: here you'll find how the technology works, where the data comes from, and which licences stand behind it.

Where the parking data comes from

Every parking spot on the map carries two kinds of knowledge at once: what the federal government knows about it, and what someone just experienced there. Both come from a different direction, and only together do they add up to a reliable picture.

The official side comes from the federal Mobilithek: static baseline data on location, size and facilities for every rest area, plus, where available, a dynamic live occupancy feed in the DATEX II format. This is complemented by an open interface run by the Autobahn GmbH, which feeds in closures and roadworks along the motorways.

The official occupancy data alone is not enough, though: it does not exist at every location, and where it does exist, it is not always current. That is exactly where the second source comes in: a report from a driver who is standing there right now. Vacant, occupied, police checks, roadworks, sanitary condition: information that is true at the moment it is sent, regardless of whether an official source has anything to say about that spot at all.

This fusion is the actual core of Rastplatz.app: the official data where it holds up, and the driver community where it knows better, because it is standing there right now.

Occupancy at official rest areas

The percentages at official rest areas come from the Toll Collect truck parking information service (Stellplatz-Informationsdienst). They are extrapolated from toll data, rounded up to the next 5 percent and published with a delay of up to 10 minutes. Occupancy may be shown too high or too low, for example because of vehicles without a toll unit, roadworks or near borders. For sites with fewer than 10 spaces the information is of limited use, so we show no bar there.

Where toilet and shower information comes from

Toilet and shower information, plus 421 additional locations (counted as of 16 September 2026), come from the federal government's nationwide static parking-facility file dated 2026-02-25: a one-time, frozen import.

We don't show a date at the individual site: amenities like a toilet or a shower rarely change, and a timestamp there would suggest a currency this data doesn't have.

How coordinates become a place

A rest area on the motorway often only has two coordinates and a technical name in official records: nothing a driver would recognise the place by. That becomes an understandable label: a self-run place-name service derives state, district and municipality from OpenStreetMap, separately for every location.

For a parking spot's title, we deliberately don't use the nearest municipality but the nearest city a driver would actually know, drawn from a filtered list of known city names. "Near Musterdorf-Nord" helps nobody, "near Passau" does.

"Self-run" means, literally, that no location leaves the house to resolve these details: no coordinate lookup goes out to a third-party service.

Building our own map, and why

The usual approach would be to embed a ready-made map from a provider. For this app, that doesn't fit for two reasons, and the first is the more important one: every tile request to a third-party map provider reveals where a driver is currently looking. Privacy isn't the second argument here, it is the first.

The second reason is independence. Prices, quotas and terms of service from third-party providers change, sometimes overnight, sometimes gradually. An app that is meant to stay free and ad-free cannot depend on that.

So instead, a machine of our own regularly recomputes the current OpenStreetMap state for the whole of Germany. A tool called Planetiler turns that into PMTiles archives: a single large file instead of millions of individual small tiles. These archives are served through our own infrastructure at tiles.rastplatz.app.

The genuinely interesting part comes after that. The new PMTiles archives are first only uploaded, then read back and checked, to confirm that what arrived is really what was meant. Only once that is confirmed does a pointer flip to the new state, in a single step: there is no moment where the app sees half the old and half the new state. If anything goes wrong along the way, the last confirmed-good state simply stays in place, and there is a path back to it.

What this means for the driver: the map keeps working offline, it costs nothing, and nobody outside learns where they are searching.

The weather: where it comes from and how we fetch it ourselves

The German Weather Service (Deutscher Wetterdienst, DWD) is the official source of all weather and warning data on this page. Four figures come directly from there: the current situation from observation stations, an hourly forecast up to 48 hours ahead, the rain radar for the next two hours, and the official weather warnings. The mandatory notice reads, verbatim, Quelle: Deutscher Wetterdienst, licensed under the Creative Commons Namensnennung 4.0 International (CC BY 4.0); the data source itself is at https://www.dwd.de.

This data doesn't reach us directly from the German Weather Service, but through Bright Sky, a relay we run ourselves, as a standalone service on our own infrastructure. The same independence and privacy reasoning as with the map building applies here too, only carried further: no driver's request ever leaves our own machines for this, there is no third-party API whose quota or pricing changes the weather display could depend on, and no history is kept of who asked for which weather when.

In the background, a scheduler of our own polls Bright Sky, each data type on its own rhythm: the rain radar every four minutes, warnings every five minutes, the current situation every 30 minutes, the hourly forecast once an hour. This polling runs per weather station, not per parking spot: every site is assigned the nearest forecast station, by distance AND elevation difference at once, because a station 300 metres lower in a valley measures different weather than a parking spot up on a mountain pass. If the nearest station is more than 20 kilometres away, or more than 300 metres higher or lower, the driver gets a visible caveat instead of a clean number. Honestly uncertain beats falsely precise.

Even a value that isn't perfectly fresh anymore stays visible instead of simply disappearing: rain radar and warnings count as current for up to 20 minutes, the current situation for up to 90 minutes, the hourly forecast for up to three hours, each comfortably above its own polling interval, so that a single missed fetch doesn't immediately trigger a false "stale" state. Once one of these limits is exceeded, the app explicitly marks the value as stale, together with its timestamp, rather than deleting or hiding it. In the end, it is the driver who decides whether a three-hour-old forecast is still good enough for their question.

The following details are the actual legal basis. The same registry also feeds the short attribution line at the bottom of every parking page, so nothing here can drift apart from there.

The aerial images: seeing the site first

A site on a list tells you little. How big is it really, how are the bays laid out, where is the entrance, is there a building on it? That is why every parking page carries an aerial image: not as decoration, but so a driver can form their own picture before making the turn.

For this we embed no satellite map from a commercial provider. That would be the convenient route, and the same one we already walked away from when building the map. Instead we fetch a single official aerial image per site directly from the state survey authority of the relevant federal state, and store it ourselves. Sixteen federal states means sixteen different authorities with sixteen different interfaces; each one had to be wired up separately.

The effort buys two things. An official orthophoto is rectified and surveyed: what looks straight on it is straight. And an image fetched once and stored by us loads fast, needs no third-party connection when the page opens, and does not vanish when some provider changes its terms.

Every state issues its own licence, and they do not all ask the same: some require attribution, some do not. The credit therefore sits on the image itself, and in full, state by state, on the Image credits page.

The ODbL extract

For our own map build, we derive a file of truck-relevant attributes from OpenStreetMap: height and weight restrictions, for example, exactly as they appear in the map data. This file is available as a download.

The data comes from the OpenStreetMap database and is available under the Open Database License (ODbL): anyone redistributing it must credit OpenStreetMap and its contributors, keep the licence attached when redistributing, and share alike any database derived from it under the same licence.

Download the ODbL attribute extract

The extract contains exclusively these OpenStreetMap-derived attributes, not the separate ADR tunnel list from official sources. No redistribution licence is claimed for the ADR tunnel list.

The licence details for the aerial photos on parking pages live separately on the Image Credits page.

What runs in the background

Rastplatz.app runs on Laravel and PHP, backed by a PostgreSQL database with PostGIS for the geo queries. Redis handles caching and queues, WebSockets via Reverb make sure a new report appears on every screen without a reload, and scheduled background jobs regularly pull in the official data.

The server is ours: a dedicated root server, not shared space at a provider. Alongside Rastplatz.app it carries further projects of our own, such as Schneespur.de, open-source software for winter road maintenance crews. They share the machine, not the data: every project has its own database and its own credentials.

Our hosting provider is involved as a data processor for running this infrastructure, fully named, with its legal basis, on the Privacy Policy page, so we won't repeat it here.

How this app is built: openly stated

Rastplatz.app is built through agent coding, and that isn't fine print, it's part of the story. The work runs in phases: first discussed, then researched, then planned, then executed, then reviewed. Every plan carries acceptance criteria that can be read back afterwards.

One rule holds throughout: every new check is deliberately made to fail once before it's accepted as passing, because a check that can never fail proves nothing. Decisions are recorded together with their reasoning, including the paths that were rejected.

For the driver, this means: things move faster, but nothing here counts as done because it sounds plausible. It counts as done once it has been measured.

This page will grow

Every larger expansion adds another section here. If you want to know what was added most recently, this is the first place to look.