People have been known to be wrong.
The table is supposed to document the default access for ways without access tags, expressed in OSM terminology. This is never going to be perfect, as I pointed out above there are things that are just not easy to model in OSM, but it is at least far better than the futile exercise of trying to explicitly tag everything.
Yes, we know that the US beats the UK in exceptionalism hands down, you never tire of reminding us of that.
The point being, what is the page supposed to accomplish? Can it accomplish that better than the status quo? Maybe it can for some regions but not others. I think thatâs a useful discussion to have, more than a binary decision of which approach is better for everyone.
What is the status quo in the states?
The status quo here is to explicitly tag access restrictions for the most common modes of transportation. Thereâs some debate over whether some less common access restrictions should be explicitly tagged. One factor in that debate is that some editors strongly imply that there are default values, so sometimes people go around deleting access tags that match.
(Maybe that shouldnât be a universal set of defaults?)
As most folks in this thread well know, thereâs a lot of missing coverage if we expect even these common modes of transportation to be explicitly tagged everywhere. Does that automatically make a centralized matrix of default access restrictions a winning solution? Iâm not so sure about that.
Assuming this wiki page is intended to provide half-decent fallbacks in the absence of explicitly tagged access restrictions, then thereâs not a whole lot we can confidently say about the U.S., basically just the globally relevant restrictions you might expect in the infobox of the individual highway=* value:
highway=motorway through service allows motor_vehicle (no need to split hairs about different kinds of motor vehicles).highway=busway allows bus.highway=pedestrian, footway allow foot and disallow motor_vehicle.highway=cycleway allows bicycle and disallows motor_vehicle.highway=bridleway allows horse and disallows motor_vehicle.highway=steps implies bicycle=dismount and disallows motor_vehicle (but of course).Any assumption beyond that would probably be asking for trouble somewhere or other. On the other hand, any data consumer that hews too strictly to these core access rules would fail to return a reasonable route much of the time.
These are merely observations about statistical norms, not the sort of blanket regulation that the pageâs author evidently sought. So the BRouter and cycle.travel developers are doing the responsible thing, using these observations as merely a recommendation. Another router developer could very reasonably arrive at somewhat different defaults depending on their tolerance for error or liability.
The preference for explicit tagging is informed by on-the-ground verifiability. The signs here have to explicitly list each of the prohibited conveyances. A highway=motorway should probably have an explicit foot=no and bicycle=no and horse=no if thatâs what the sign says:
But plenty of freeways in mountainous areas allow bikes, up to a point.
Of course the sign only has regulatory effect because of a regulation, but the regulation is predicated on the sign being posted. Can we just err on the side of caution and say that highway=motorway implies bicycle=no, then map the exceptions as exceptions? Maybe, but in some regions, this is tantamount to mapping the restriction explicitly on a routine basis.
What does this mean for something less regulated like highway=path or highway=track? Itâs anyoneâs guess â specifically, the routerâs guess. 
My error, however Iâm still pretty sure that 2010 came after 2008.
Why would describing suggested defaults for routers and explicit tagging of the actual access-restrictions on OSM exclude each other?
They are complimentary, not mutually exclusive.
Explicit tagging will never be totally complete and has to start from zero, so routers will need to have default assumptions anyway, and local mapping communities can help with suggestions.
And here the results of explicit mapping can help to shape these suggestions that are less horrible as routing defaults than many of the values that you see now in the wiki tables (which may still be fine for describing legal defaults) .
When enough ways in the actual world are mapped explicitly, the distribution of tags can show for which types of OSM-ways the actual access restrictions on the road are different from the legal default from a traffic rule
(which can be overruled by a traffic sign or access sign on the road). The âonly tag the exceptions from the default -approachâ is useless for this purpose:
Not only is it an unnecessary work-multiplier for other mappers (if a road is untagged, does that mean that
(a) it has not yet been evaluated by another mapper ?or
(b) it has been evaluated and the other mapper found it corresponded with the default but did not map it because of that, so the next mapper has to check it again
But also exception-only tagging gives a skewed view on the relation between recorded access values in OSM and actual access in the real world.
For instance:
A couple of years ago bicycle=no on highway=primary was tagged on 20% of highway=primary in the Netherlands
An exception-only mapper/data user might think "fine, for the other untagged 80% the legal default described in the table applies"
(default: bicycle=yes , special a priori legal restrictions apply only on motorway / motorroad , not on other main roads )
Nowadays bicycle=* mapping is nearing completion in the Netherlands on mayor road types : 97% on highway=primary ; 87% on secondary
The result :
bicycle=yes applies on only 0,26% of all highway=primary
96,8% of all highway=primary now has a negative value (bicycle=no or use sidepath because of a traffic sign or mandatory cycleway)
And the 3% that is now still untagged for bicycle=*?
With explicit tagging one might assume that on >99% of these the legal default will also be overruled by a sign, so bicycle=no would be the suggested default for routers
With exception-only tagging one would assume that these are not tagged because the default applies, so use bicycle=yes as routing default?
And this does not only apply to this example;
other mappers in the Netherlands are doing excellent collaborative work with explicit state-by state maxspeed-tagging for 7 OSM-road types (for which there are also OSM-maxspeed defaults). Completion levels in some states range from 98% to 100% between OSM-way types.
And also here it is found that for some road types the most common actual maxspeed on a road-type is not the legal speed limit from the general traffic rule, but a different limit set by a traffic sign along the road that overrule the legal default from a traffic rule (such a a sign 30 km/u in a built up area for which the traffic rule is 50 km/u).
Router-developers looking for a sensible routing-default can use the values from the tagged roads for inspiration and local mappers can help interpret them further in a wiki.
So to discard explicit tagging beforehand because it would be a âfutile exerciseâ does not seem either constructive or accurate to me.
I totally agree with Simon. Usually, we donât tag just for renderers and routers, but thatâs exactly what the proposed solution is doing by saying, âWe have to add bicycle=yes explicitly because XYZ router needs it.â
I think we should stick to some global defaults and let routers adapt. There hasnât been a global agreement on needing explicit tagging, so pushing it as a universal standard doesnât seem right.
If a place like the Netherlands is doing well with explicit access tags, thatâs awesome, but it shouldnât be forced on everyone else.
This just reinforces the idea that OSM should have global defaults for routers. Instead of letting these complaints pile up in DWG mailboxes, we should use them as an opportunity. If we send them to the developers of the maps or routers with the global defaults in mind, theyâre more likely to make changes.
This is pulling things way out of context. The argument is not âYou should just tag what the situation is (also when it is similar some default) because routers need itâ
Different reasons for explicit tagging for keys that can reasonably have different values are:
you just want to make clear what the situation is, like with most things in OSM
this saves other mappers unnecessary work for rechecking items over and over again because with exception-only mapping it is not clear whether it has been evaluated already
this decreases the need for end users (whether they are rendering, routing or doing data-analysis to fall back to (country / region specific?) default values which are often hard to interpret like @SomeoneElse already illustrated
this also gives insight in the portion of elements already evaluated for a key and which are yet to be evaluated, which helps mappers to focus their efforts
this also helps answer the question how representative the values on the tagged elements might be for the not-yet tagged elements
and yes: as an added bonus routers can use this the define better defaults for an area than the defaults now mentioned in the wiki tables that are mainly based on applying traffic rules to OSM-categories and not the real world access-situation on these element
These arguments donât just apply to the Netherlands.
And to describe explicit tagging as tagging for the renderer / router is also a non-helpfull misconception (and simplification):
âTagging for the rendererâ, also known as âlying to the rendererâ, is the bad practice of using incorrect tags"
With explicit tagging you donât use incorrect tags, but correct tags, so the above does not apply.
However, exception-only mappers often use an argument that much more resembles tagging for the renderer, like:
âyou should omit / remove this tag from the OSM-database because routers will use this value anyhow since it is mentioned in the wiki default-tablesâŠâ
Yes, some of these pro arguments are valid and positive. Yet there are counter-arguments on why explicit tagging can be problematic, we have already shared a few, so I hope this will be healthy debate and discussion.
Fair enough, but Iâve already pointed out that explicit tagging can confuse new mappers and lead to incorrect usage.
In Thailand, most trails donât have legal access restrictions except for national parks. Since highway=path already allows all non-motorized traffic by default, adding bicycle=yes, foot=yes, and horse=yes is unnecessary and from experience will just confuse mappers into thinking itâs about feasibility/difficulty rather than legal or signage aspect.
I only just noticed that this has gained international attention. This whole debacle is essentially fallout from Foot=no op autowegen on the Dutch forum.
@multimodaal seems to be taking a stance that access tags for specific vehicles should be tagged explicitly as often as possible, while everyone else in the conversation seems to be of the opinion that itâs perfectly fine to assume certain tags like foot=no and bicycle=no on motorroads, and we can safely remove those tags in these cases.
This disagreement has led to multimodaal doing some wiki-fiddling, and the rest as they say is history.
P.s. @multimodaal Can you keep your messages shorter, plz? The sum of your messages approaches the length of a scientific paper by now and you canât expect everyone here to have the time to read through all of it.
I think we should stick to global defaults and let routers adapt.
isnât the page about local defaults rather than global ones? Particularly when it comes to default bicycle access, things are not very uniform globally so that in absence of explicit tags people likely have different expectations locally.
Also within the same country, the real situation can vary, despite having the same laws (as opposed to e.g. the US, where every county can have its own rules as far as I understood from previous discussion) it may be custom (and required to get typical routes) to cycle on certain ways where it would not be tolerated in other areas of the country.
@Friendly_Ghost : That is quite rich from someone who has managed to already accumulate 3 users blocks mentioning [1]
Please donât make these types of edits. Go out and record some great detailed POI information in an area where you actually have first-hand knowledge, or trace some data from aerial imagery if you must, but this world-wide tag fiddling doesnât help.
And yet again you are taking up other users time with a long list of possible fiddling edits referring to the default tables discussed here (not motorroad) as an excuse to go on and delete valid data (besides some good additions for mofa the also contain horrible suggestions such as deleting bicycle=yes on highway=secondary).
And yet again you ignore warnings and requests from other mappers (also in PM) not to do this and go on and make sloppy edits that make things worse instead of better, taking up time from other mappers that have to review your edits for the quality-checks that you lack.
And yes, giving actual arguments and examples takes more text than just shouting out some slogans.
It would also save a lot of time if you would listen to what other mappers have written before (also about motorroad, just like @Minh_Nguyen just did here or the motorroad wiki) .
And what would save to biggest amount of time is if people with a preference for exception-only mapping would not force that view on other people by deleting (or proposing to) or discourage explicit tagging when a key can reasonably have multiple values, as no one forces you to be explicit in your tagging if you donât want to.
Yeah, I was just suggesting a middle ground between the unadopted per-country defaults and the impractical explicit tagging camps.
And please do not make a mockery by deliberately misquoting me, what I wrote translates to :
And roads with an explicit motorroad=yes are of course a special case, because that is a kind of access tag and personally I would not quickly add bicycle=no etc to it.
But I wouldnât remove it either, because also the effect of that tag internationally is unfortunately less obvious than you might think / hope, as indidcated in its wiki
The OSM communityâs ability to relitigate things that you thought were settled never ceases to amaze me.
But even I am surprised that here we are in 2024 - the 20th anniversary of OSM - and people are still arguing about the very oldest OSM meme of all, horse=yes.
As I understand it, many of the complaints are about hikers being sent down challenging or downright fictitious trails, or trails that are designed for pedestrians but are off-limits anyways. Default access restrictions wonât help with that, unless you mean enforcing an assumption that highway=path implies foot=no and a modification to the ODbL that prohibits mashups with external user-generated trail recommendations.
The page has both a âWorldwideâ table and a number of per-country tables. The first couple of countries that appeared on the page probably wonât come as much of a surprise. Presumably, in these countries, the communityâs highway classification practices happened to align well enough with real-world access restrictions that a table of this sort would seem useful. Itâs too bad it wasnât coordinated with editor and router developers at the time; we couldâve wound up in a much better spot by now.
As with many global tagging pages, itâs only a matter of time before someone sees a per-country breakdown, feels a pang of FOMO, and rushes to fill in superficially similar details for their own country. When this happened to the motorroad=* page, it took a foreigner like me quite a bit of research and many confused questions to understand the conceptual basis for the key and finally conclude that, despite an authoritative-sounding definition for my country, it doesnât apply at all.
I think I understand the basic desire for implicit defaults. It would save mappers a lot of menial work in regions where the local community frowns upon bulk edits â and where the most basic mapping has already taken place, so mappers increasingly split hairs about minor differences between vehicles. Meanwhile, in Southeast Asia, it would just be nice if global routers wouldnât assume full-size cars are the main motorized transport everywhere. And if the local community prefers the flawed highway=path tag over more specific highway=* values, thatâs even more access tags to maintain, just so this tag can have any meaning at all.
So yes, editors and data consumers should fall back to some sensible value in the absence of an explicit access tag. Sometimes these default values need to differ because of real-world legal or physical differences. Data consumers couldnât practically support this kind of regional variation a decade ago, but the state of the art has improved somewhat since then. For OSRM, this capability came with left-hand driving support. Iâm sure the UK mappers are quite thankful they donât have to tag driving_side=left on every single roundabout in the country to keep the app from going the wrong way around! Each new kind of implicit default we pile on will incur a steep performance penalty, but more reliable routing could justify the additional overhead.
Implicit defaults begin to break down when we additionally expect strict conformance and automation among data consumers. An athlete might appreciate a router that can send them anywhere pedestrians are technically allowed, so they can complete the map, but a website showing parents safe walking routes to school wouldnât want to be so bold. Besides, this pageâs focus on highway=* values is somewhat ironic, because most routers donât place very much importance on highway classification anyways. Mostly they use it as a very crude fallback strategy for default speed limits. (Widespread adoption of the âDefault speed limitsâ page remains a pipe dream, but not for lack of trying.) The only values that matter are the ones that donât represent roads per se.
As for automation, weâve all heard the argument that a country could go topsy-turvy overnight, suddenly allowing bikes on all sidewalks or mopeds on all motorways. Wouldnât it be nice if someone in the OSM Master Control Room could just flip a switch and all the routers would get with the program? Part of the problem with this idea is that most deployed routers update much less frequently than the data they route on. If we really need to expedite a fix, a bulk edit to OSM would have a more immediate impact anyways. But a reliance on implicit defaults makes that kind of edit much riskier.
Darn, that page hasnât aged well, even in the Wayback Machine. Maybe someone in the crowd has stashed away a working time capsule to open on the occasion of OSMâs 20th birthday?
Another reason why âwith exception-only tagging you only need to change a single default valueâ does not work in the real world is that when a traffic rule changes, often in many places traffic signs are added / changed in conjunction as to overrule the new traffic rule and keep the actual regime from the old traffic rule (or something in between).
Road authorities may find the new rule not to be possible or desirable to apply in all situations. So every element in OSM has to be evaluated anyhow for possible changes.
A change in legal default maxspeed on Dutch motorways years ago went along with a massive addition in traffic signs overruling the new legal default maxspeed.
Now our legal default maxspeed is 130 km/h and with 99,98% of motorways tagged in OSM for maxspeed=* 93,8% has maxspeed=100 , and 65% has an additional maxspeed:conditional=*âŠ
This is totally off-base and exactly what Iâve been pushing against and will continue to do so.
For marking trail difficulty, use the sac_scale tag. If a trail seems to be missing, use lifecycle tags like not:highway or highway=road if it needs to be surveyed first. For trails that are abandoned use abandoned:highway, or smoothness=impassable. If an outdoor app canât handle these tags, itâs not worth relying on.
Using legal access tags in these cases is a problem because:
A highway=path is meant for all non-motorized traffic (like walking, biking, or horseback riding) by default. If a trail is legally only for pedestrians, just tag it as highway=footway.
The issue is that many outdoor routers will route end-users through paths with no extra info. In Thailand, this is a big problem because 99% of paths donât have additional tags. Tagging tough or non-existent trails with access=no isnât the solution. Itâs better to discuss tagging unsurveyed paths as highway=road or asking routers to only use paths with extra tags.
That sounds reasonable enough. So for highway=path, is the default foot restriction yes or no? Your first paragraph says yes from a legal perspective, and your second paragraph says no from a practical perspective. This is essentially the contradiction that data consumers currently face when interpreting this page, but maybe some clarification of the expectations would be in order.