Hi, I mentioned this for another reason than the the Routing profiles linked there page (I did not add that piece myself).
The examples I mentioned were cases where I added that they use a penalty for some ways that do not have explicit access-tags on the way in OSM (despite the fact that these tags are seen as default in the tables in that wiki): Brouter and Graphhopper.
Some individual deployments of particular routers might give rubbish results, but that doesn’t mean that the route software used is inherently “bad”, just that it has been poorly configured.
I did not mean to suggest by adding those links that these routers are bad, on the contrary: in my opinion it is wise for routers to give a penalty to highway=path without a positive tag on the OSM-way for cycling, at least in the country where I live. For most of the areas in my country I would advise to use bicycle=no as a default on untagged highway=path
The reason I added those examples to the wiki is that is that we have had different assumptions on the concept of defaults and routing behavior, which have led to repeated undiscussed mass deletions (example) of valid foot=yes and bicycle=yes tags from highway=path and other highways. Mapper argued that these tags are needless and should be removed because they are the same as the values in the default table (at that time, the some values in the default tables in the wiki have changed…)
Furthermore it was argued that all routers use (or should use) the country specific defaults in that wiki and that these tags are needless because deleting them would not influence routing behavior. These examples show that routers may very well use other default values and that routing results can be changed when deleting access tags that some consider “needless because they are default”.
All the default BRouter bike profiles route over highway=path (with no additional tags) if you force them to do so: BRouter web client (playing around with the two no-go areas will reveal how big of a detour they would take in order to avoid this segment).
Adding foot=yes or even bicycle=yes to such a path would only make things worse (from the perspective of these routing profiles): BRouter web client (the trekking profile is mislead by the bicycle=yes in this case).
I am not saying that this is the behavior that a router should exhibit. But those profiles do not do it that way because they are stupid. They do it because it works well most of the time (in Germany).
@SomeoneElse, but Germany is only one of those countrys which have some sort of Freedom to roam which does affect the meaning of undefined access tags.
My argument would be that forcing the use of foot=yes and bicycle=yes on highway=path would actually further reduce the usability of highway=path in these countries, since there would no longer be a distinction between undefined and yes.
if you explicitely state an implicit rule, what do you do if the implicit rule changes later on?
if foot=yes or bicycle=yes is already implied, people tend to use explicit foot=yes or bicycle=yes to indicate actual usability (which is wrong, but common practice). If we now change the default logic (in these countries) this might break more than it fixes.
Your examples show that the standard Brouter trekking bike profile uses a cost factor of
100 000 $/km for a bare highway=path (without any access tags) and
1 050 $/km for a highway=path with bicycle=yes added
That seems just fine to me for usage in my country, and also in parts of Germany, since I understand that
Is riding a bike in certain parts of the forest forbidden?
[…] Each Bundesland has their own rules, so there’s no general answer for all of Germany. It’s possible you are only allowed to ride on gravel roads, or on pathways wider than 2 m, etc.
Which I also read sometime ago in a German cycling magazin and is also illustrated by this example:
In 1995, Baden-Württemberg tightened up §14 of the Federal Forest Act, which generally allows bicycles to ride on paths, by introducing the two-meter rule in §37.3 of the State Forest Act BW. This prohibits cycling in the forest on paths less than two meters wide.
If you worry that a path where cycling is legally allowed (bicycle=yes only means it is legal), but which is practically not really suitable for general cycling, is being used by routers, please
add information to the way in OSM that reflects this (such as surface= and smoothness=horrible etc.)
suggest to the person maintaining the routing profile to use a penalty for highway=path which is missing smoothness=* and/or surface=* tags (or to increase the penalty if they already do that)
The problem is that, even in Germany, it’s not an implicit rule everywhere (as noted already). It’s an assumption that you can make if you don’t have better data. It still makes sense to add an actual tag that says “yes, cycling (or walking, or whatever) is allowed here” if someone has checked all of the myriad of things (is the path in BaWu? is it <2m wide?) that might affect it.
those examples show that Komoot does not take the 2-m rule into account which in turn means they also make a difference between implicit yes and explicit yes.
Again, I’m not saying we should care, I’m just saying that forcing the use of explicit access rules will certainly break things - just as getting rid of explicit rules in favor of implicit rules broke things as you mentioned above.
Then I guess you must believe that an implicit vs explicit value for any access tagging would differ in meaning. Seems a bit confusing. Perhaps that’s why someone recently came through my area and added bicycle=designated to all the previously mapped highway=cycleway. It seemed entirely unnecessary to me.
We have had the discussion implicit vs. explicit several times in the german forum in regard of different tags (in most cases acess=*). The problem with an implicit access=yes (or no) is that it does not give any proof if the mapper is happy with the implicit value or if the mapper just has forgotten to check if the implicit value is correct. You do not have this problem with an explicit value. Anyhow these discussions never came up with a clear consensus as far as I remember. I believe it depends on the given situation which approach is the better one.
It seems to me that this discussion is based on different views of what “implies foot=yes / implies bicycle=yes” mean:
(a) some interpret this as "when bicycle= is missing on a way the suggested fallback-value for data-users is “bicycle=yes”*
(b) others go a step further and interpret this as “if bicycle=yes on a path in the real world, you should NOT tag this on a highway=path in OSM, because this is already implied / default”
That is a very good argument against interpretation (b) -that prohibits tagging implied values-, but not against interpretation (a) -that is aimed at data consumers and not mappers.
If you look at the history of the proposed default values in the country-specific tables in OSM tags for routing/Access restrictions - OpenStreetMap Wiki , you’ll see changes in cases where the interpretation of the default value have changed (even if the traffic/access rules themselves have remained the same) .
When such a change in default value (from A → B, for say bicycle=* on a bridleway) occurs and you believe that this is also a rule for what to tag and what not to tag, you are left with a problem:
removing all the tagged (bicycle=B) 's from ways in OSM -because it is the newly declared default- is deleting valid data (where a mapper has concluded that the presumed default indeed applies on that way)
adding value (A) to all the bridleways in OSM that are not tagged for bicycle=* is also not a viable option, because you can not tell which of these ways are (1) evaluated for bicycle-access and found to be the same as the default value or (2) which ways have not been evaluated for bicycle-access by a mapper
These problems can be avoided by being clear and explicit to your fellow mappers and data users about access tags and use as little hidden assumptions as possible.
Only consider leaving out tags when they can be inferred by definition (such as bicycle=designated on a highway=cycleway), not by some assumed default that may be interpreted differently by area, by different people, over time and per usecase.
This is the first time that I have heard of this, and I have not read this in the access-documentation either. Surely some people will act this way (I’ve seen stranger things come along), but I would be very hesitant to assume that this is a widespread interpretation internationally, since it seems to be in such clear violation of the described primary scope of the general wiki for key:access :
Access values describe legal permissions/restrictions and should follow ground truth; e.g., signage or legal ruling and not introduce guesswork. It does not describe common or typical use, even if signage is generally ignored.
I don’t think so. Komoot answered a few months back in a PM that they -based upon the OSM wiki- just assume you may ride there that when a highway=path is not tagged for bicycle=* . They don’t seem to use a penalty for a missing bicycle=yes like Brouter does.
This despite the data in OSM showing that the majority paths that are tagged for access in that state have a negative value (bicycle=no / private ).
The routing behavior was consistent with this and this was the reason for contacting Komoot after complaints by forest owners about routing suggestions over paths that are prohibited for cycling in real life, but untagged for bicycle in OSM
As noted earlier, on most paths in OSM that are still untagged for bicycle=* in my country cycling is NOT allowed, they just arent’t tagged yet.
So you can not be sure that an untagged way complies to a presumed default, the only way to reduce uncertainty is to be explicit in tags, regardless if they do or don’t comply to a default.
“meaning” is probably the wrong word, but yes, I would argue that there is almost always a difference between implicit vs. explicit. We also add source:maxspeed to speed limits (which are only implied by a road sign) because of this.
No, this is actually an argument for removing unnecessary access tags whenever possible. In BaWu, if you tag a way narrower than 2m with bicycle=no because it is narrower than 2m, then you would also have to add width=x where x < 2m, or source:bicycle=2m rule Baden-Wuerttemberg, because otherwise a change in legislation would cause a massive amount of work.
Yet another argument for keeping it implicit, because otherwise such a change would become impossible.
I fully agree that there are advantages to making it explicit, but I am not quite convinced yet that they outweigh the disadvantages.
I would love to gradually shift to a phase where highway=path becomes analogous to highway=road. This would of course require that we have a consensus about which alternative tags we use to cover most of the use cases that highway=path now fulfills.
Actually, this problem is as old as path itself. You just raise awareness. And that is highly in order.