Lost Places beschäftigen mich schon länger. Nicht als Trendthema, sondern als Orte, die irgendwann aus der Nutzung gefallen sind und trotzdem noch etwas erzählen. Eine stillgelegte Industrieanlage, ein leeres Verwaltungsgebäude, ein Gelände, das man kennt, ohne dass dort noch jemand arbeitet. Oft beginnt das bei mir mit Fotografie: genauer hinsehen, Strukturen, Licht und den Zustand, in dem etwas stehen geblieben ist.
Was daraus geworden ist, hat weniger mit einer großen Ankündigung zu tun als mit einer Haltung, die mich als Entwickler ohnehin begleitet. Wenn mich etwas länger beschäftigt, will ich irgendwann nicht nur wissen, dass es geht. Ich will verstehen, wie es geht. Und irgendwann kommt fast zwangsläufig die Frage, die auch auf dieser Website eine Rolle spielt:
Warum sollte man das nicht selbst bauen können?
Genau daraus ist LostPlaces.app entstanden: der Versuch, Karten, Navigation, GPS und ein persönliches Interesse in einer Anwendung zusammenzubringen, die unterwegs tatsächlich brauchbar ist.
Aus Interesse wird eine Idee
Karten gibt es. Navigationsdienste gibt es. GPS gibt es. Geodaten sind zugänglicher als noch vor ein paar Jahren. Moderne Browser können Standort, Offline-Verhalten, Push-Nachrichten und eine Bedienung abbilden, die sich auf dem Smartphone kaum noch von einer installierten App unterscheidet.
Wenn man sich Urban Exploration und Lost Places genauer anschaut, merkt man schnell, dass dabei nicht nur einzelne Adressen eine Rolle spielen. Es geht um Wege, Entfernungen, Reihenfolgen, eigene Notizen, darum, was man schon gesehen hat und was unterwegs überhaupt sinnvoll erreichbar ist. Eine einfache Liste oder eine Karte mit Markern deckt davon nur einen Bruchteil ab.
Mir war außerdem klar, dass man so etwas nicht als klassische Desktop-Webseite denken sollte. Wer sie nutzt, tut das unterwegs. Der Standort ändert sich, die Verbindung ist nicht immer gut, die Bedienung muss auf einem kleinen Bildschirm funktionieren. Mich hat interessiert, was passiert, wenn man Karten, echte Navigation, GPS, Tourenplanung und persönliche Entdeckungen in einer Anwendung zusammenführt, die speziell auf diesen Anwendungsfall zugeschnitten ist.
Das ist der Punkt, an dem aus Interesse ein Projekt wird. Nicht, weil es unbedingt noch eine weitere Plattform gebraucht hätte, sondern weil die technischen Bausteine da waren und die Frage offenlag, wie weit man sie kombinieren kann.
Mehr als Punkte auf einer Karte
Eine Datenbank mit Lost Places und Markern auf einer Karte wäre relativ schnell gebaut. Das ist kein besonders schweres Problem. Man speichert Koordinaten, zeigt sie an, klickt auf einen Punkt und sieht ein paar Informationen. Für einen ersten Prototyp reicht das.
Mein eigentliches Ziel war das aber nicht. LostPlaces.app sollte sich zu einem Werkzeug entwickeln, mit dem man Orte nicht nur findet, sondern Touren planen, eigene Entdeckungen festhalten und unterwegs damit arbeiten kann. Dann reicht es nicht, dass ein Marker auf der Karte sitzt. Dann muss die Anwendung mit Wegen, Standortänderungen und eigenen Notizen umgehen können.
Deshalb stecken in der Anwendung heute unter anderem:
interaktive Karten
reale Straßenrouten und Entfernungen
GPS-Live-Tracking
Tourenplanung
Suche nach Lost Places entlang einer Route
persönliche Marker
Favoriten
„Ich war hier“
Entdeckungslog
Nearby-Benachrichtigungen
Das sieht nach einer Featureliste aus. Für mich ist es eher eine Reihenfolge von Problemen. Jede dieser Funktionen ist entstanden, weil eine einfache Kartenansicht irgendwo nicht mehr gereicht hat.
Luftlinie reicht mir nicht
Bei geografischen Anwendungen sieht man häufig zuerst die Luftlinie. Zwei Koordinaten, eine Distanzformel, fertig. Das ist einfach zu rechnen und für eine grobe Übersicht manchmal auch völlig ausreichend.
Für Urban Exploration ist sie oft wenig hilfreich. Zwei Orte können geografisch nah beieinanderliegen und über das Straßennetz trotzdem weit voneinander entfernt sein. Ein Fluss, ein Werksgelände, eine Bahntrasse oder einfach eine fehlende Verbindung reicht, und aus „drei Kilometer Luftlinie“ wird eine deutlich längere, umständlichere Fahrt. Wer eine Tour plant, braucht deshalb keine theoretische Nähe, sondern eine realistische Route.
LostPlaces.app setzt dafür auf OSRM, die Open Source Routing Machine. Statt nur Distanzen zwischen Punkten zu berechnen, werden reale Straßenrouten und tatsächliche Fahr- bzw. Wegentfernungen ermittelt. Darauf aufbauend lassen sich nicht nur einzelne Ziele anfahren, sondern Touren mit mehreren Lost Places zusammenstellen. Außerdem kann die Anwendung entlang einer bereits berechneten Strecke nach weiteren Orten suchen.
Technisch läuft das unter anderem über ein Korridorprinzip: Entlang der Route wird nicht die ganze Karte durchsucht, sondern ein Bereich um die Strecke herum. Das klingt nach einer Kleinigkeit, macht in der Praxis aber den Unterschied zwischen „alles irgendwie in der Nähe“ und „wirklich unterwegs erreichbar“.
Solche Berechnungen sind aufwendig. Deshalb arbeitet die Anwendung mit progressiver Berechnung und mehrstufigem Caching. Nicht jede Kartenbewegung und nicht jede kleine Änderung an einer Tour darf dieselbe schwere Arbeit noch einmal auslösen. Die erste Anfrage ist machbar. Interessant wird es, wenn dieselbe Logik unterwegs und bei wechselndem Kartenausschnitt zuverlässig bleiben soll.
Genau das hält mich an dem Projekt. Die Oberfläche kann man relativ schnell so weit bringen, dass sie nach einer Karten-App aussieht. Die eigentliche Arbeit sitzt darunter.
Das Smartphone wird zum Werkzeug
LostPlaces.app kann den Standort nicht nur einmal bestimmen, sondern kontinuierlich verfolgen. Auf der Karte verhält sich das ähnlich wie bei einer Navigationsanwendung: Die eigene Position bleibt sichtbar, verschiebt sich mit, und die Umgebung wird darüber lesbar.
Dabei reicht es nicht, den Browser einfach dauerhaft nach dem Standort zu fragen. Positionsupdates kommen in unterschiedlicher Genauigkeit, sie kosten Datenverkehr, und auf dem Smartphone merkt man das vor allem am Akku. Wenn eine Anwendung unterwegs genutzt werden soll, muss sie diese Updates steuern. LostPlaces.app drosselt die Abfragen deshalb, statt sie unkontrolliert permanent auszuführen.
Während des Trackings können Nearby Notifications auf Lost Places in einem konfigurierbaren Radius hinweisen. Das Entdeckungslog hält fest, welche Orte während einer Tour neu gefunden wurden, und gruppiert sie nach Datum. Zusammen mit persönlichen Markern, Favoriten und „Ich war hier“ entsteht daraus eine eigene Historie – als Werkzeug, nicht als öffentliches Tagebuch.
Eigene Marker sind dabei bewusst alltagsnah gedacht. Ein Zugang, eine Parkmöglichkeit, eine private Location, die man per GPS-Koordinate festhält, bearbeitet und später wiederfindet. Dinge, die man nicht in einer öffentlichen Liste haben will, die für die nächste Tour aber entscheidend sein können.
Touren statt einzelner Ziele
Einzelne Lost Places auf einer Karte zu sehen ist eine Sache. Mehrere davon in eine Reihenfolge zu bringen, die sich unterwegs tatsächlich fahren oder gehen lässt, ist eine andere. Der Tourenplaner in LostPlaces.app ist genau dafür da.
Mehrere Ziele lassen sich zu einer Tour kombinieren. Bestehende Favoriten können übernommen werden. Routen lassen sich speichern und teilen. Wenn man für die eigentliche Navigation dann lieber die Karten-App nutzt, die auf dem Gerät sowieso da ist, kann eine berechnete Route oder ein Ziel an Google Maps oder Apple Karten übergeben werden.
Besonders interessant finde ich den Routenmodus von A nach B. Man plant nicht zuerst eine Sammlung von Orten, sondern eine Strecke – und sucht anschließend Lost Places, die entlang dieser Strecke liegen. Das dreht die übliche Reihenfolge um. Nicht: „Hier sind Orte, wie komme ich dorthin?“, sondern: „Ich fahre sowieso von hier nach dort. Was liegt unterwegs?“
Solche Funktionen interessieren mich, weil Software dann aufhört, nur Daten anzuzeigen. Eine Karte voller Punkte ist eine Ansicht. Eine Route, die man speichern, teilen und unterwegs benutzen kann, ist ein Werkzeug.
Geodaten können noch viel mehr
Lost Places und Fotografie führen bei mir auch zum Thema Drohnenaufnahmen. Nicht als Aufforderung, überall zu fliegen, sondern als praktisches Problem: Sobald eine Kamera in die Luft soll, spielen Zonen, Schutzgebiete und Einschränkungen eine Rolle. Die Information dazu existiert, ist aber oft über verschiedene Stellen verteilt.
LostPlaces.app bindet deshalb amtliche Geodaten für den DiPUL-Drohnen-Check ein. Auf der Karte können damit unter anderem relevante Flugzonen und Einschränkungen sichtbar gemacht werden, etwa Naturschutzgebiete, militärische Bereiche und weitere geografische Vorgaben, die für Drohnen relevant sind. Die Daten werden für den aktuell sichtbaren Kartenausschnitt geladen und clientseitig zwischengespeichert. Wo möglich, kommen zusätzliche Gebietsinformationen und Verweise auf amtliche Rechtsgrundlagen dazu.
Wichtig ist mir dabei eine klare Grenze: Der Check ist eine Informations- und Planungshilfe. Er ersetzt keine rechtlich verbindliche Flugfreigabe. Wer eine Drohne nutzt, bleibt selbst dafür verantwortlich, die geltenden Vorschriften einzuhalten. Technik kann solche Informationen zusammenführen und auf einer Karte sichtbar machen. Die Entscheidung und die Verantwortung bleiben beim Nutzer.
Gerade das finde ich an Geodaten spannend. Sie sind nicht nur Dekoration auf einer Karte. Richtig eingebunden werden sie zu einer Schicht, mit der man planen kann – und bei der man gleichzeitig ehrlich bleiben muss, was sie leisten und was nicht.
Sicherheit gehört ebenfalls dazu
Urban Exploration ist kein reines Kartenthema. Wer sich mit verlassenen oder schwer zugänglichen Orten beschäftigt, bewegt sich in Situationen, in denen Vorbereitung sinnvoller ist als Nachlässigkeit. Deshalb gibt es in LostPlaces.app unter anderem farbcodierte Gefahrenstufen, Safety-Funktionen und einen SOS-Flow mit Countdown und ausdrücklicher Bestätigung, bevor ein Notruf ausgelöst wird.
Ich will das nicht dramatischer machen, als es ist. Eine Anwendung beseitigt keine Risiken. Sie kann aber Informationen verfügbar machen und bestimmte Abläufe so vorbereiten, dass sie im Zweifel nicht erst aus dem Kopf zusammengesucht werden müssen. Der Countdown und die Bestätigung sind dabei Absicht: Ein Notruf soll nicht durch einen versehentlichen Tipp entstehen.
Für mich gehört das zur gleichen Denkweise wie das Routing. Wenn man eine Anwendung für unterwegs baut, muss man die Realität mitdenken: schlechte Verbindungen, Akkustand, unübersichtliche Gelände – und die Tatsache, dass nicht jeder Ort unproblematisch ist.
Warum eine PWA?
LostPlaces.app ist eine Progressive Web App. Die Entscheidung war für mich weniger eine Modefrage als eine praktische. Die Anwendung läuft über den Browser, lässt sich auf dem Smartphone installieren und verhält sich dann ähnlich wie eine klassische App. Updates kommen ohne einen eigenen App-Store-Release. Push-Benachrichtigungen sind möglich. Teile der Anwendung funktionieren offline oder mit eingeschränkter Verbindung.
Gerade bei einer Nutzung unterwegs ist das entscheidend. Eine Desktop-Webseite, die nur am großen Bildschirm wirklich bedienbar ist, wäre für diesen Zweck das falsche Format. Die Karte, das Tracking, die Tour, die Nearby-Hinweise: All das muss auf dem Telefon funktionieren, auch wenn gerade kein perfektes WLAN in der Nähe ist.
Eine PWA ist kein Allheilmittel. Sie zwingt aber dazu, die Anwendung von Anfang an als etwas zu denken, das installiert, aktualisiert und mitgenommen wird. Für LostPlaces.app passt das besser als eine klassische Website mit ein paar responsiven Anpassungen.
Ein Projekt, das wahrscheinlich nie wirklich fertig ist
LostPlaces.app ist für mich keine Website, die man einmal programmiert und danach in Ruhe lässt. Es ist eine praktische Anwendung, ein technisches Experimentierfeld und die Verbindung aus Softwareentwicklung, Karten, Geodaten und einem Interesse, das mich unabhängig vom Code beschäftigt.
Viele Funktionen entstehen aus einer einfachen Frage: Was wäre eigentlich, wenn …? Wenn man nicht die Luftlinie nimmt. Wenn sich eine Tour unterwegs erweitern lässt. Wenn amtliche Drohnen-Daten auf derselben Karte liegen. Wenn das Smartphone den Standort nicht nur einmal setzt, sondern wirklich mitläuft.
Genau solche Projekte machen mir als Entwickler Spaß. Eine Idee ausprobieren. Das eigentliche Problem erst beim Bauen richtig sehen. Eine Lösung hinbekommen. Und feststellen, dass daraus wieder drei neue Fragen entstehen.
Am Ende ist das derselbe Satz, mit dem das Ganze angefangen hat: Warum sollte man das nicht selbst bauen können? Manchmal ist die ehrlichste Antwort: Man kann. Und dann merkt man, dass „bauen können“ erst der Anfang ist.