Route, Stellplätze, Etappen und Reisekosten stecken bei der Wohnmobil-Planung meistens in drei nebeneinander offenen Tabs. Diese Case Study zeigt, wie wir daraus ein Werkzeug gemacht haben – und warum die interessanteste Entscheidung darin bestand, bestimmte Zahlen bewusst nicht auszugeben.
Wer eine Reise mit dem Wohnmobil vorbereitet, arbeitet in aller Regel mit drei Werkzeugen gleichzeitig. Die Strecke entsteht in einem Routenplaner, der für PKW gebaut wurde. Die Übernachtungsplätze werden in einer Community-App gesucht. Spritkosten und Maut bleiben im Kopf oder landen in einer Tabelle. Am Ende steht eine Reise, die in keinem der drei Werkzeuge vollständig abgebildet ist, und jede spätere Änderung muss von Hand durch alle drei nachgezogen werden.
Dazu kommt eine Frage, die ein PKW-Routenplaner strukturell gar nicht kennt: Wie hoch, wie breit, wie schwer und wie lang ist das Fahrzeug. Für ein Wohnmobil sind das keine Randnotizen, sondern die Bedingungen, unter denen eine Strecke überhaupt fahrbar ist. Wir haben ausführlich aufgeschrieben, warum ein Auto-Routenplaner für Wohnmobile zu kurz greift.
Camperada ist unser Versuch, diese drei getrennten Schritte zu einem zusammenzuziehen. Das Produkt ist kostenlos, deutschsprachig und läuft im Browser. Für uns als osnabyte war es gleichzeitig ein ernsthafter Praxistest für einen Karten- und Routing-Stack, den wir vorher nicht in dieser Tiefe im Einsatz hatten.
Die Kernthese des Produkts passt in zwei Sätze: Die anderen planen eine Strecke oder einen Platz. Camperada plant eine Reise. Aus dieser Unterscheidung folgt der gesamte Aufbau der Anwendung. Route, Zwischenstopps, Übernachtungen, Tagesetappen und Kosten entstehen nicht nacheinander in getrennten Ansichten, sondern in einem einzigen Fluss, in dem jede Änderung sofort auf alle anderen Größen durchschlägt.
Verschiebt sich eine Etappe um hundert Kilometer, ändern sich Fahrzeit, Spritkosten und die Auswahl der erreichbaren Plätze mit. Genau dieser Zusammenhang geht verloren, sobald die Planung auf mehrere Werkzeuge verteilt ist. Wie Etappen und Übernachtungen in einem Plan zusammenspielen, ist deshalb kein Zusatzfeature, sondern der Kern der Anwendung.
Der interessanteste Teil dieses Projekts ist keine Optimierung, sondern eine Reihe von Entscheidungen darüber, was das Produkt bewusst nicht behauptet. Ein Reiseplaner, der Kosten ausgibt, steht permanent vor der Versuchung, eine glatte Zahl zu liefern, weil eine glatte Zahl besser aussieht als ein Bereich. Wir haben uns an mehreren Stellen dagegen entschieden.
Streckenmaut in Italien, Frankreich oder Kroatien hängt von Fahrzeugklasse, Achszahl und Abschnitt ab und lässt sich aus einer geplanten Route nicht exakt ableiten. Camperada gibt deshalb eine Spanne aus statt eines Punktwerts. Ein Punktwert wäre geraten, eine Spanne ist ehrlich. Dasselbe Prinzip greift bei den Spritpreisen: Für Nicht-EU-Länder wie die Schweiz existiert keine EU-weite Preiserhebung. Statt dort einen Wert zu erfinden, rechnet das System mit dem Preisniveau der übrigen Strecke und weist genau das aus. Wie die Reisekosten- und Mautberechnung im Detail arbeitet, ist offengelegt und nicht in einer Blackbox versteckt.
Am deutlichsten wird das Prinzip bei einem Feature, das es nicht gibt. Tunnel lassen sich in der Routenberechnung nicht meiden: Weder OpenRouteService noch OSRM kennen eine entsprechende Option (Stand 07/2026). Ein Schalter mit der Beschriftung „Tunnel meiden“ wäre schnell gebaut gewesen und hätte in keinem Fall etwas bewirkt. Er wurde deshalb nicht gebaut. Ein Bedienelement, das nichts tut, ist keine Vereinfachung, sondern eine Attrappe.
Diese Haltung nehmen wir direkt in die Kundenarbeit mit. Was sich nicht seriös beziffern lässt, wird bei uns ein benannter Hinweis statt einer erfundenen Zahl. Das ist unbequemer in der Abstimmung und in der Oberfläche schwerer unterzubringen, aber es ist der einzige Umgang mit gerechneten Werten, der einer Rückfrage standhält. Eine falsche Zahl fällt irgendwann auf, und dann steht nicht nur diese eine Zahl in Frage, sondern das ganze Werkzeug.
Die Karte läuft auf MapLibre GL, bewusst auf Version 5 gepinnt: Version 6 rendert unter Next.js 16 mit Turbopack keine GeoJSON-Layer, und ein Kartenprodukt ohne GeoJSON-Layer ist kein Kartenprodukt. Die Vector-Tiles kommen von OpenFreeMap im Style Positron. Geroutet wird über OpenRouteService mit dem Profil driving-hgv, das Fahrzeugmaße berücksichtigt; als Rückfallebene dient die OSRM-Demo mit PKW-Profil. Das Geocoding übernimmt Nominatim mit einem Rate-Limit von einer Anfrage pro Sekunde, was die Eingabe-Logik im Frontend spürbar mitprägt.
Die fertige Strecke wird anschließend gegen die OSM-Tags maxheight, maxheight:physical, maxwidth, maxweight und maxlength in einem 50-Meter-Korridor geprüft. Das Ergebnis ist im UI bewusst als mögliche Engstellen formuliert und nicht als Garantie: OSM-Tags sind unvollständig, und eine Zusicherung, die auf lückenhaften Daten beruht, wäre genau die Art von Behauptung, die wir vermeiden wollten. Der Abgleich der Fahrzeugmaße mit möglichen Engstellen ist entsprechend als Hinweis gebaut, nicht als Freigabe.
Die Plätze stammen aus einem eigenen OSM-Bestand mit rund 87.000 Einträgen in Europa, der monatlich erneuert wird; Overpass dient nur noch als Rückfallebene. Dabei war uns eine Abgrenzung wichtig: OSM-Rohdaten schlagen keine kuratierten Community-Bestände. Statt so zu tun, als wäre man die bessere Platzdatenbank, verlinkt jede Platzkarte in die Umgebungssuche von park4night und Campercontact. Die Stellplätze entlang der Route sind damit ein Planungswerkzeug und kein Konkurrenzprodukt zur Community.
Gespeichert wird in Postgres, adressiert über einen Speicher-Code statt über einen Konto-Zwang; ein optionales Konto über Better Auth gibt es zusätzlich. Die Spritpreise kommen aus den wöchentlichen Landesdurchschnitten des EU Weekly Oil Bulletin und werden nach Streckenanteil je Land gewichtet, optional ergänzt um Tankerkönig beziehungsweise MTS-K für tagesaktuelle Preise in Deutschland. Das Wetter je Halt liefert Open-Meteo, der Export erfolgt als GPX 1.1 für die Übernahme ins Navigationsgerät. Alle verwendeten Quellen stehen bei den offengelegten Datenquellen des Projekts.
Im Juli 2026 haben wir die Zielgruppe geschärft: Camperada priorisiert Einsteiger, die ein Wohnmobil mieten. Diese Gruppe kennt ihre eigenen Zahlen noch nicht. Sie unterschätzt vor allem die Kilometerpakete im Mietvertrag, weil der Unterschied zwischen der gebuchten Pauschale und der tatsächlich gefahrenen Strecke erst bei der Rückgabe sichtbar wird. Daraus folgten eine Mietkosten-Rechnung, ein Abgleich mit dem gebuchten Kilometerpaket und Fahrzeugklassen als Richtwerte für alle, die ihre Maße noch nicht auswendig kennen. Wer sich vorher einlesen möchte, findet auf camperada.de auch einen Ratgeber zum Mieten eines Wohnmobils.
Wichtig war uns, dass diese Entscheidung niemanden ausschließt. Erfahrene Camper bleiben vollwertige Nutzer, die Einsteiger-Hilfen sind additiv und lassen sich ignorieren. Ebenfalls Teil der Produktentscheidung: kein Tracking, keine Werbung und keine Weitergabe der Reiseplanung. Eine Urlaubsplanung ist ein persönliches Dokument, und ein kostenloses Werkzeug muss sich nicht über die Daten seiner Nutzer refinanzieren.
Ob ein Wert als Punktzahl, als Spanne oder als benannter Hinweis herauskommt, entscheidet sich im Datenmodell und nicht im Textfeld der Oberfläche. Wir planen diese Unterscheidung inzwischen in jedem Kundenprojekt ein, in dem gerechnete Werte nach außen gehen.
Ein Schalter, der nichts bewirkt, kostet weniger Entwicklungszeit als seine Umsetzung – und mehr Vertrauen, als jedes Feature zurückgeben kann. Wenn eine Funktion technisch nicht tragfähig ist, empfehlen wir Kunden, sie wegzulassen und den Grund zu benennen.
Tile-Quellen, Routing-Profile, Geocoding-Limits und Versionsstände von Karten-Bibliotheken verhalten sich in Produktion anders als in der Dokumentation. Diese Erfahrung fließt direkt in jede Beratung zu Projekten mit räumlicher Komponente.
Ein serverseitiger Speicher-Code hält den Einstieg offen und bleibt trotzdem teilbar. Für viele Kundenprojekte ist genau das der bessere erste Schritt, bevor eine vollständige Nutzerverwaltung überhaupt nötig wird.
Wenn Sie eine Idee haben, die mehr ist als eine Website, sprechen wir gerne darüber. Wir denken Datenmodell, Oberfläche und den ehrlichen Umgang mit gerechneten Werten von Anfang an zusammen.