Help required for adding access information to track roads

Dear OSM Community,

At Amazon we are coming across a situation where unmaintained track roads have no access tags. We would like to know your suggestions/feedback on how to tag these roads.

Track Roads:
By definition track roads implies traversal of motor vehicles and are mostly used for agricultural use. We have private GPS traces showing where delivery vehicles go, and when we match them against OSM data, we see they’re going along highway=track ways. We want to add appropriate access tags so that routers can route correctly along the data in the future.

The driver trace is on-the-ground evidence that the road can be used by motor vehicles for deliveries, but we have no evidence either way that the road can be used for general traffic.

There are four different ways we’ve come up to tag this information:
1. motor_vehicle = yes
Our editing team used to do this, but the community has pointed out that it’s incorrect because we don’t know if the roads can be used for public motor vehicle traffic. This is particularly a problem for track roads that could connect two roads.

If the track road were tagged as motor_vehicle=yes, the data would show that anyone could connect from one side to the other. We don’t have evidence on that.

2. motor_vehicle = destination
This indicates that local traffic can go there. Unfortunately, it also says through traffic can’t use it, which we also have no evidence on apart from our delivery partners route information.

3. motor_vehicle = delivery
This is the same as #2, except it indicates delivery only. All public traffic will be blocked from routing via this road.

4. service = driveway + surface = unpaved
Since most of the track roads are leading to independent houses or commercial entities, these track roads can be converted to driveways and add ‘surface=unpaved’ information as per available sources. This might not be applicable to all the track roads but only to roads leading to housing entities and vehicles visible in satellite images.

Our personal preference is the combination of #2 and #4 as we think this correctly captures the information we have.

What do community think is the most appropriate tag for this case?

As per community request, we’ve stopped adding motor_vehicle=yes to track roads and reverted all the changes we made previously in UK while we sort this out. Do let us know your suggestions.


Welcome to the forum!


You can’t make such edits solely based on GPS traces and aerial imagery.
Local knowledge is required (road signs, …).


Yes, Road Signs.


For access-roads to residential-houses highway=service may be more appropriate than hw=track.

You know where the vehicles go and therefore can assume that there is some kind of road which is technically usable by motor vehicles.

But do you know (in every single case) that this road is really allowed to be used by any motor vehicles for delivery?
Maybe a driver is using a shortcut? Or the road is only allowed to be used at specific times? Or a private road has a sign “access denied except for amazon delivery”? Or the road has a maximum load or height? I can’t think of a generic solution. It’s best to check the traffic signs of every single road and tag what they indicate.


Hello jguthula,

thank you for clarifying with the community.

Hoenstly, I think none of 1., 2., or 3. are valid for the given data, GPX tracks and satellite pictures.
The GPX track does not tell you anything about the access that is defined by traffic signs other signs. You only know that the delivery driver went there along, but not whether he was allowed to drive there and what the restrictions are.
If you have mapillary or Openstreetcam pictures, it would be possible.
Only missing highways, for which you have GPX tracks and that can be verified with the satellite picture, can be added in my opinion.


Hi Jothirnadh,

I agree Rainero, JochenOSM and Mondschein. A GPX track of a vehicle does not say anything about the access restrictions tagged with access=, motor_vehicle= etc. You need on the ground knowledge (or recent photos as a replacement) to judge that. OSM’s strength is on the ground knowledge, especially in Germany where we did not use official data for mapping the road network from scratch. (We aren’t the U.S. where a tiny number of mappers maintains a huge public domain dataset)

You should think about first doing a OSM data import without taking access restrictions into account or with a liberal interpretation thereof into your routing engine (or any other engine of your choice), matching GPX tracks against the network, updating the edges (or OSM ways in your copy of the planet file) where your vehicles used “unusable” roads. It seems sensible to me to maintain a separate set of accessible “private” streets and use this to update an OSM data file during or before the import.

There might already be features to update edges somehow with OSRM which is able to import real-time traffic data in MLD mode. There is no possiblity to update a GraphHopper graph but as long as you don’t use GraphHopper with contraction hierarchies or landmarks, adding that feature seems quite cheap and easy [1].

If you use OSM data to route delivery vehicles to individual buildings, you will have to use roads with access=private. That’s valid tagging and you have to be able to handle that. Other companies developing software for delivery services using OSM data are able to treat private access ways appropriately. If all solutions fail, you can still maintain your own dataset of accessible roads 8as buffer polygons around the edges) and mark all edges as accessible during the import if they significantly intersect with any polygon.

OSM is a database for many data consumers. We don’t map for a single routing application.

Best regards


[1] I am writing this as someone who maintains his own GraphHopper fork.

So your answer to the question how they can use their data to enhance OSM for delivery applications is:

  1. the data does not say anything

  2. they should not use it to enhance OSM but maintain an additional dataset

I object, because track access is in a bad shape, seems we need some push here and just singing the “signs, only signs” song of the craftmapper fraction does not help.

Any external settlement without “destination” access is a bug in the database.

But the “untagged” tracks are actually not the problem: it’s a widespread assumption that the default access for track is agricultural+forestry+destination, and it’s more or less safe to assume that a grade1-track without access tags is good for delivery.

The problem are the tracks with “naive” access tags: motor_vehicle=no on a track can mean anything from “no general access” to “no physical access for double-tracked vehicles”, you just don’t know. And replacing that by motor_vehicle=destination if you can prove physical access by GPS tracks is, in my opinion, a valuable contribution to the database.

I think it’s a better idea to have every abode in Germany accessible by at least a highway=service, because highway=track cannot be the only way to access a valid (with address) destination. The assumptions made by highway=track are correct, if highway=track is used what it is meant to be, a road for forest workers and farmers.

Let your delivery vehicles use openstreetcam or mapillary and use this data for access tagging with for example this tool:,1026-36

Just because someone was driving there does not mean that the road is motor_vehicle=destination.
This approach might instruct other drivers to violate the law.

I saw in my Amazon account that they make photos to prove the delivery of the parcel.
I’m sure that Amazon is also able to instruct their drivers to document possible access restrictions.

Thanks for all the responses. I have also posted the same content in UK forum ( and talk GB mailing list along with a diary post ( I will wait until this weekend to get more responses from the community members and also to cover as many edge cases as possible. Later this week I will compile all the information in all forums and come up with a list of possible solutions.


Hallo an alle Nicht-Amazonen, die nicht in die Benutzerblog schauen,

jguthula hat die gleichen Fragen auch in seinen Benutzerblog gestellt, der auch einige Kommentare bekommen hat. Die Kommentare dort sind ganz anders ausgefallen. Das Problem ist nämlich kürzlich in England hochgekocht, dort hat die DWG die Amazon-Edits im großen Stil rückgängig gemacht. England und Wales haben jedoch gewisse Besonderheiten, was das Wegerecht angeht. Anders als bei uns, stehen dort an den Feldwegen weniger Durchfahrtsverbotsschilder.

Viele Grüße


Vielleicht wäre es auch bei Amazon richtiger, länderweise einen Ansprechpartner zu nennen. Es sind ja auch länderspezifische Regelungen, die es betrifft.

Auch bei uns in Oberschwaben gibt es an Feldwegen fast keine Verbotsschilder mehr, eigentlich nur noch eine wenige aus früheren Zeiten.

Das kann sein. Mir fällt gerade auch ein, dass in Anhalt, wo ich gewohnt habe, die Feldwege oft auch nicht beschildert sind. Aber auf den grade3- bis grade5-Wegen will so ein Amazonfahrer hoffentlich nur einmal fahren …

Tracks als Zufahrt zu einem Aussiedlerhof etc. sind ja auf jeden Fall falsch. Gibt es eine Möglichkeit nach solchen falschen Klassifizieren zu suchen?

Sagt wer? Hier (Berlin-Brandenburg, MV, Sachsen) gibt es genug Tracks, die beim besten Willen keine öffentlichen Straßen sind und nur Zufahrt zu Forsthaus/Hof - teilweise mit klarer Waldweg-Beschilderung + Ausnahme-Zusatzschild. Jahreszeitabhängig kommt da ein Amazon-T6 oder DHL-Sprinter auch gar nicht durch.

Und da wohnen Leute, die sich damit abfinden drei Monate lang keine Post zu bekommen?

Für mich ist auch eine unbefestigte Zufahrt immer noch ein highway=service (evtl. mit service=driveway). Meiner Meinung nach ist der Zweck des Weges da entscheidend. Ergänzen kann man dann ja entsprechend etwa surface=unpaved und/oder smoothness=bad.

Wiki sagt:


Dann gibts im Winter keine Pizza? :sunglasses: