Recently at Mapbox we open sourced RoboSat our end-to-end pipeline for feature extraction from aerial and satellite imagery. In the following I will show you how to run the full RoboSat pipeline on your own imagery using drone imagery from the OpenAerialMap project in the area of Tanzania as an example.

Goal

For this step by step guide let’s extract buildings in the area around Dar es Salaam and Zanzibar. I encourage you to check out the amazing Zanzibar Mapping Initiative and OpenAerialMap for context around the drone imagery and where these projects are heading.

High-level steps

To extract buildings from drone imagery we need to run the RoboSat pipeline consisting of

• data preparation: creating a dataset for training feature extraction models
• training and modeling: segmentation models for feature extraction in images
• post-processing: turning segmentation results into cleaned and simple geometries

… See full entry

At Mapbox we are happy to open source RoboSat our production ready end-to-end pipeline for feature extraction from aerial and satellite imagery. In the following I describe technical details, how it will change the way we make use of aerial and satellite imagery, and how OpenStreetMap can benefit from this project.

Berlin aerial imagery, segmentation mask, building outlines, simplified GeoJSON polygons

… See full entry

Wir (Mapbox) haben soeben RoboSat unter einer MIT Lizenz auf Github veroeffentlicht. RoboSat ist ein generisches Ecosystem um aus Luft- und Satellitenbildern Daten zu extrahieren. Im Folgenden beschreibe ich die technische Umsetzung und wie es fuer OpenStreetMap eingesetzt werden kann.

Luftbilder von Berlin, Segmentierungsmasken, Gebaeudeumrisse, vereinfachte GeoJSON Polygone

… See full entry

In the following I describe how we implemented reasonable alternative routes in the Open Source Routing Machine’s Multi-Level Dijkstra mode.

Final result: generating reasonable alternative routes incredibly efficiently

Our main goals when designing and implementing reasonable alternative routes were two-fold:

• provide reasonable alternative routes for end-users and use-cases such as generating many alternative routes letting users or developers decide between them (e.g. runner’s app, start and end is the same but provide different route each day), and
• guarantee for fast query times in the tens to lower hundreds of milliseconds to fit the Open Source Routing Machine’s trade-off of doing heavy pre-processing and then get incredibly fast exact responses

But what exactly do we mean by “reasonable” alternative routes? When we find a fastest route and compute alternatives these are the criteria we try to optimize for:

… See full entry

Im Folgenden beschreibe ich wie wir Alternativrouten in den Multi-Level Dijkstra Algorithmus der Open Source Routing Machine implementiert haben.

Endprodukt: effiziente und plausible Alternativrouten

Unser Fokus beim Designen und Implementieren von Alternativerouten lag dabei auf:

• hoch-qualitative Alternativerouten zu generieren: fuer den Endanwender und fuer Anwendungsfaelle die von vielen Alternativerouten profitieren koennen (z.B. eine Jogging-App bei der Start und Ziel ueber die Woche hinweg gleich bleiben aber die Route sich aendern soll), und
• gleichzeitig fuer schnelle Antworten der Routingengine garantieren zu koennen, die im Bereich von 10-100 ms liegen und damit in das Konzept der Open Source Routing Machine passen wobei pre-processing benoetigt wird aber dafuer extrem effizient und schnelle exakte Routen berechnet werden koennen.

Hier sind die Kriterien nach denen wir die Qualitaet der Alternativerouten beurteilen:

… See full entry

We are releasing 10.4k turn restriction detections located across 5.2k intersections for the OpenStreetMap community.

Map

Raw GeoJSON data

---

These turn restriction detections were sourced by applying our machine learning computer vision models to Bing Streetside imagery. Mapbox has acquired the right to contribute these detections to OSM.

“Detections” are not really the same thing as turn restrictions. Rather, they are suspected, but unverified turn restrictions. We are planning to manually verify these turn restrictions, and our data team is working through the list, but the first pass produced thousands of candidates, so verification will take a while. We do think these can be useful to the OSM community, who may wish to move faster on improving OSM based on these detections.

… See full entry

It isn’t always obvious where to position a highway=motorway_junction node that connects a motorway way to a motorway_link way (also known as an off-ramp or slip road). Over the years, mappers have used three different approaches.

Inconsistent placement of junction nodes can affect turn-by-turn navigation software, particularly instruction timing and rerouting. I’d like to raise awareness about the preferred placement, which is at the beginning of the gore, and explain why the other two approaches are suboptimal.

Throughout this post, I will refer to the term gore. A gore is a wedge that separates a ramp from the main motorway. A physical gore may be a barrier or a grassy area, whereas a theoretical gore simulates this separation using pavement markings and empty space. By “gore”, I am referring to the beginning of the theoretical gore, if present, or alternatively the physical gore.

… See full entry

Es ist nicht immer offensichtlich wo eine highway=motorway_junction Node, an der ein motorway_link Way abgeht, gemappt werden soll. Im Folgenden betrachte ich die drei am häufigst genutzten Modellierungsmethoden mit ihren Vor- und Nachteilen insbesondere im Hinblick auf die Routenplanung und Navigationsansagen.

Dabei dient folgendes Schema als Grundlage in welchem der “physical gore” die physische Abgabelung der Strasse und der “theoretical gore” den Beginn der Fahrbahnflächenmarkierung darstellt.

Modellierung I: Node am Ausfahrtsschild

In manchen Fällen gibt es ein letztes Überhangs-Schild an dem das Abbiegemaneuver noch getätigt werden kann.

… See full entry

Here’s a map I got out of our Open Source Routing Machine when I built a validator for sharp turns onto ramps. The idea behind this validator is that turns onto highway ramps should never be sharp (i.e. < 90’ish degree). There is a high chance a turn restriction is missing at those locations.

With these checks enabled I found roughly 30k intersections on the planet. I visualized the results in the map below; the redder the circle, the sharper the turn angle onto the ramp.

Click for interactive map

In the results I found an issue that frequently re-occurred. Consider the situation below: heading east on Goff Mountain Road (the yellow line), there is a ramp on the right that you can legally take. Around the bend, there is another ramp onto the same road for drivers going west on Goff Mountain Road.

… See full entry

Hier ist eine Karte die ich mit unserer Open Source Routing Machine generiert habe als ich nach spitzen Winkeln beim Abbiegen auf Ausfahrten gesucht habe. Solche Abbiegevorgänge sollten niemals vorkommen und sind ein gutes Indiz für fehlende Abbiegeeinschränkungen.

Hier ist eine Visualisierung; je röter desto spitzer der Winkel.

Interaktive Karte

Ein Problem was immer wieder aufzutauchen scheint ist das Folgende (siehe Bilder unten): aus dem Westen kommend auf der Goff Mountain Road gibt es eine Ausfahrt auf der rechten Seite. Kurz nach dieser Ausfahrt ist eine zweite Ausfahrt für die Gegenrichtung.

Wenn man nun aus dem Osten kommend auf der Goff Mountain Road fährt und die Ausfahrt verpasst gibt einem die erneute Routensuche die Anweisung die nächste Ausfahrt der Gegenrichtung zu nehmen! Hier fehlt die Abbiegeeinschänkung in den OpenStreetMap Daten.

… See full entry

The Open Source Routing Machine supports bearing constraints for quite a while now. In the following I want to highlight their use-cases and effects on routing.

Suppose you are driving north and make a routing request. An instruction to take a U-turn — since the routing engine does not know your heading — would be undesirable. This is the primary use-case for setting bearing constraints.

Setting a constraint of bearings=0,90 tells the routing engine you are heading north and you want to allow for a variation of +-90 degree around true north. The format is value, range with

• value in 0, 360 degree for the direction; 0 degree represents true north, 90 represents east and so on
• range in 0, 180 degree for the allowed variation around the value; a variation of 90 degree allows for +- 90 degree

The bearings=0,90 constraint therefore allows the route to start off towards north +- 90 degree. But not in the opposite direction you are currently heading. Sweet!

Another interesting use-case I came across at FOSSGIS is fire truck routing where your vehicles have to arrive at the right side of the street. Using bearing constraints not only for the route’s start but its end location we can let the routing engine generate optimal routes which guide vehicles to the right side of the street.

Here are two routes from a fire department in Berlin to an arbitrarily chosen location:

• In orange with a bearing constraint of 0,90 guiding the fire trucks to the location from the northern direction (raw request)
• In green with a bearing constraint of 180,90 guiding the fire trucks to the location from the southern direction (raw request)

… See full entry

Die Open Source Routing Machine unterstützt seit längerem das Einschränken der Richtungen bei der Abfahrt und Ankunft. Im Folgenden zeige ich Anwendungen dafür auf und wie sich das Feature auf die Routenfindung auswirkt.

Angenommen wir fahren in Richtung Norden und machen eine Routing Anfrage. Was wir auf keinen Fall hören wollen ist die Aufforderung sofort eine Kehrtwende zu machen, nur weil die Routing Engine unsere Fahrtrichtung nicht kennt. Und genau das ist der perfekte Anwendungsfall für das Einschränken der Richtung bei der Routenplanung.

Wir können eine Einschränkung der Richtung erzwingen indem wir den Parameter bearings=0,90 setzen, was der Routing Engine mitteilt, dass wir in Richtung Norden fahren und +-90 Grad Variation zu Nord erlauben. Die Option bearings=value,range erklärt sich wie folgt:

• value in 0, 360 Grad für die Richtung; 0 Grad für Norden, 90 für Osten und so weiter
• range in 0, 180 Grad für die erlaubte Variation; eine Variation von 90 Grad erlaubt +-90 Grad

Die bearings=0,90 Einschränkung erlaubt es also dass die Route grob in Richtung Norden startet mit einer Variation von +- 90 Grad. Dadurch filtern wir also Routen die gegen unsere aktuelle Fahrtrichtung starten. Perfekt!

Ein weiterer Anwendungsfall den ich auf der FOSSGIS aufgeschnappt habe ist Feuerwehr Routing, wobei die Fahrzeuge auf den richtigen Strassenseiten ankommen sollten. Wenn wir die Richtung nicht (nur) für den Start einer Route einschränken, sondern für das Ende, können wir die Routing Engine benutzen um optimale Routen zu generieren die uns auf die korrekte Strassenseite führen.

Hier sind zwei Routen von einer Feuerwehr in Berlin (im Bild weiter im Süden) zu einer beliebig ausgewählten Position:

• In Orange mit einer Einschränkung von 0,90 welche die Feuerlöschfahrzeuge aus dem Norden kommen lässt (Anfrage Details)
• In Grün mit einer Einschränkung von 180,90 welche die Feuerlöschfahrzeuge aus dem Süden kommen lässt (Anfrage Details)

… See full entry

In which I explain the differences between the exit_to= tag on the highway=motorway_junction node and the more recent destination= tag on the way branching off of the motorway. In addition I will show the need for handling both tags and leave you with a tool for automatic rewriting.

To provide great guidance for our Open Source Routing Machine users we want to include ramp information for highway navigation.

There are two established tagging schemes for highway ramp signage:

• Using the exit_to= tag on the highway=motorway_junction node where the ramp branches off of the motorway. This tagging scheme was established mainly because the default Mapnik style displayed the tag quite nicely.
• The more recent destination= tag on the way branching off of the motorway.

Why do we have two completely different tagging schemes? Have a look at the following example where a ramp branches off the continuing motorway:

a . . . b . . d .
          ` . c .

In this case the exit_to tag is placed on the node b together with the highway=motorway_junction tag. So far so good. Now consider the common situation where multiple numbered exits diverge at a single point.

            . c
a . . . b `
          ` . d

Now there are destination signs for the ways bc and in addition for bd. There are workarounds like exit_to:left and exit_to:right tags but as you can imagine these do not suffice for more complex situations.

For these situations the destination tag is the better alternative.

Here in an example for where we need such a workaround.

… See full entry

Um den Nutzern unserer Open Source Routing Machine anständige Instruktionen liefern zu können, wollen wir Informationen zu Schildern an Autobahnausfahrten einbeziehen.

Es gibt zwei Tagging Varianten für Autobahnausfahrtsschilder:

• Den exit_to= Tag, gesetzt auf der highway=motorway_junction node an der der Ausfahrtsweg abgeht. Diese Art des Taggings wurde hauptsächlich verwendet da der standard Mapnik Stil es recht gut aussehen lies.
• Der neue destination= Tag auf dem Way der Ausfahrt.

Warum brauchen wir zwei grundweg unterschiedliche Tagging Varianten? Hier ist ein Beispiel für eine fortfahrende Autobahn und eine Ausfahrt:

a . . . b . . d .
          ` . c .

Hier kann der exit_to Tag auf der node b zusammen mit dem highway=motorway_junction Tag gesetzt werden. Soweit so gut. Was passiert nun aber bei mehreren Ausfahrten die sich alle an einer einzelnen node auftrennen?

            . c
a . . . b `
          ` . d

Hier wollen wir Ausfahrtsinformationen für bc als auch bd setzen. Dafür gibt es Workarounds wie exit_to:left und exit_to:right, die aber schon bei gering komplexeren Situationen versagen.

Für genau diese Fälle ist der destination Tag die bessere Alternative.

Hier ist ein Beispiel wo ein solcher Workaround verwendet wird.

… See full entry

Some days ago we released the latest stable Open Source Routing Machine release: version 5.5. In addition to some neat routing engine features I want to highlight two often overlooked improvements in usability.

Docker Images

We now publish pre-build Docker images for the latest releases to Docker Hub. Setting up your own routing engine and running the HTTP API is now as easy as:

wget http://download.geofabrik.de/europe/monaco-latest.osm.pbf

docker run -t -v $(pwd):/data osrm/osrm-backend:v5.5.2 osrm-extract -p /opt/car.lua /data/monaco-latest.osm.pbf
docker run -t -v $(pwd):/data osrm/osrm-backend:v5.5.2 osrm-contract /data/monaco-latest.osrm
docker run -t -i -p 5000:5000 -v $(pwd):/data osrm/osrm-backend:v5.5.2 osrm-routed /data/monaco-latest.osrm

curl 'http://localhost:5000/route/v1/driving/7.436828612,43.739228054975506;7.417058944702148,43.73284046244549?steps=true'

Hooking up the user-facing frontend is a npm install away.

Rendered API Documentation

We now host up-to-date documentation for both the routing engine’s HTTP API as well as for the C++ libosrm library doing the heavy-lifting. This is in addition to the existing documentation for the NodeJS wrapper node-osrm.

Check out our re-worked Landing Page and Wiki:

• https://github.com/Project-OSRM/osrm-backend/wiki
• https://github.com/Project-OSRM/osrm-backend#open-source-routing-machine

Hopefully this makes it easier to set up OSRM and experiment with OpenStreetMap-based routing. As always I’m more than glad for feedback!

Vor Kurzem haben wir Version 5.5 der Open Source Routing Machine veröffentlicht. Neben einigen netten Neuerungen zur Routenplanung möchte ich hier zwei Änderungen zur Benutzerfreundlichkeit vorheben.

Docker Images

Wir veröffentlichen jetzt Docker Images für die aktuellen OSRM Versionen auf Docker Hub. Um OSRM aufzusetzen und den HTTP Server zu starten genügt nun Folgendes:

wget http://download.geofabrik.de/europe/monaco-latest.osm.pbf

docker run -t -v $(pwd):/data osrm/osrm-backend:v5.5.2 osrm-extract -p /opt/car.lua /data/monaco-latest.osm.pbf
docker run -t -v $(pwd):/data osrm/osrm-backend:v5.5.2 osrm-contract /data/monaco-latest.osrm
docker run -t -i -p 5000:5000 -v $(pwd):/data osrm/osrm-backend:v5.5.2 osrm-routed /data/monaco-latest.osrm

curl 'http://localhost:5000/route/v1/driving/7.436828612,43.739228054975506;7.417058944702148,43.73284046244549?steps=true'

Ein Interface mit Karte und Geocoding ist jetzt nur noch ein npm install entfernt.

Aktuelle API Dokumentation

Wir publizieren nun aktuelle Dokumentation für die HTTP API und die C++ libosrm Bibliothek, zusammen mit der Dokumentation für den NodeJS wrapper node-osrm.

Hier ist die neue Wiki und Start Seite:

• https://github.com/Project-OSRM/osrm-backend/wiki
• https://github.com/Project-OSRM/osrm-backend#open-source-routing-machine

Damit sollte es einfacher sein mit der Routenplanung auf OpenStreetMap Daten zu experimentieren!

Ein kurzer Einblick in den junction=circular Tag.

Verkehrskreisel sind eine moderne Art von Kreuzungen. Bei der Routenplanung unterscheiden wir zwischen Kreisverkehr Kreuzungen, benannten und unbenannten Kreisverkehren. Kreisverkehr Kreuzungen sind dabei ein Spezialfall von Kreisverkehren, die relativ klein sind und bis zu vier gut unterscheidbare Ausfahrten haben.

Damit ein Verkehrskreisel sich einen Kreisverkehr im strikten Sinne der Definition nennen und damit junction=roundabout getaggt werden darf muss er bestimmte Kriterien erfüllen. Einer der wohl wichtigsten Faktoren ist, dass der Verkehr im Kreisverkehr Vorfahrt hat.

Nun gibt es Verkehrskreisel die wie Kreisverkehre aussehen und auch als solche von Mappern getaggt werden, aber tatsächlich keine sind, da sie die Kreisverkehr Kriterien nicht erfüllen.

… See full entry

In which I outline the need for the recent junction=circular tag.

Traffic circles are a modern feature of intersection design. They come in multiple forms and shapes.

OSRM distinguishes between roundabout intersections, named, and unnamed roundabouts. Roundabout intersections are a special case of roundabouts that are small and offer up to four clearly distinguishable exits.

To be considered a roundabout in the strict sense the road junction has to follow certain criteria. One of the criteria for a roundabout is that traffic in the roundabout has the right of way.

There are circular junctions which may look like and be commonly identified as roundabouts, but they are not roundabouts because they do not fulfill all of the criteria for being a roundabout.

… See full entry

Ab und an berichten uns OSRM Nutzer von Umwegen die wir auf Anhieb nicht erklären können. Das folgende Beispiel zeigt eine solche Situation: der Flottsundsbron, eine schmale Brücke mit abwechselndem Verkehr in eine Richtung, im Süden von Schweden. Um solche und ähnliche Situationen handhaben zu können wurde vor Kurzem der oneway=alternating Tag in OpenStreetMap eingeführt.

… See full entry

Every now and then OSRM users report routes that take puzzling, unrealistic detours. For example, a user reported this route that went to extensive means to avoid going over Flottsundsbron, a narrow bridge with alternating direction of traffic in the south of Sweden. Investigating this strange route led us to the oneway=alternating tag in OpenStreetMap.

… See full entry