#19996 closed defect (fixed)
[PATCH] Warning "motor_vehicle=yes is unnecessary" for multiple highway types is incorrect; leads to deletion of valid data
Reported by: | Owned by: | team | |
---|---|---|---|
Priority: | normal | Milestone: | 21.06 |
Component: | Core validator | Version: | |
Keywords: | unnecessary access tag | Cc: | Penegal, AlfonZ, mkoniecz, Klumbumbus |
Description
The validator warning "motor_vehicle=yes is unnecessary" that appears when this tag is detected on several highway types (such as highway=service/unclassified/residential) is incorrect.
Rationale is the same as https://josm.openstreetmap.de/ticket/19862
(other values then yes are possible for motor_vehicles on these ways and valid data should not be removed)
Thanks for repairing the validator rules.
Attachments (3)
Change History (18)
comment:1 by , 3 years ago
comment:2 by , 3 years ago
Given the rationale in #19862 all warnings for combinations of highway=* and motor_vehicle=yes should be excluded.
For instance on a highway=residential motor_vehicle is NOT yes by definition, it can be destination; permissive OR yes. So the tag motor_vehicle=yes contains information that is not present by the mere presence of a highway=* tag and should not be deleted.
These situations with other values than yes will be more frequent on lower level road types but even on higher level road types such as trunk you may find roads where -given the somewhat unfortunate tagging scheme for access- the correct tag for motor_vehicle is permissive (such as on Schiphol Airport / Amsterdam, as confirmed in court rulings).
Thanks for repairing this and so preventing the automated loss of valid data by using "auto-fix" option in the validator!
comment:3 by , 3 years ago
Do we really want to have all access tags on every highway=*
? Do not forget to check from both sides and use *:forward/:backward
if needed. I am also not happy with the outcome from #19862 but fine, let's start from the top and add foot
, horse
, bicycle
, carriage
, vehicle
, snowmobile
and all access tags to highway=motorway
and highway=trunk
as we cannot count on defaults.
Do not forget to add oneway
, lit
, surface
, lanes
, sidewalk
, cycleway
, shoulder
, bus_bay
and every tag which can be added to highways as value no
gives more information.
I already find cycleway:both=no
and cycleway=no
somewhat annoying, especially, as quite a lot are wrong and should be separate
instead of no
. I doubt that is will be different with motor_vehicle=yes
.
On the other hand removing only the auto-fix might lead to have users take a closer look which could lead to better decisions if this tag is really useful/needed.
comment:4 by , 3 years ago
Shall we try to stay on point?
(if someone wants to deprecate lit=*
for certain road types that is a different discussion)
As explained above the statement motor_vehicle=yes
is unnecessary" is incorrect.
(and yes, there is a difference with foot=no on a motorway
, because it can be argued that on a motorway by definition don't have access. However the same can not be said about motor_vehicle=yes
on a highway=residential
, that could very well be destination
, permissive
etc..)
A mapper that just looks at the outcome of conventional routers may not think that such tags are necessary.
But mappers that try to give a complete overview of access limitations in an area will want to make explicit that motor_vehicles are allowed on a specific road. Otherwise there is no verifiable difference between roads that have been classified for access (where no limitation was found) and roads that have not been classified.
Critical data-users that are aware that not all roads in OSM have been classified for access can also appreciate explicit access-tags, because access-limitations for motor_vehicles are not uncommon in the real world and the absence of a tag limiting access- in OSM does not have the same informational value as a tag that confirms that motor-vehicles do have access. To assume these two would have the same value could be regarded as a logical fallacy also known as an argument from ignorance . So it should be no surprise that multiple apps such as Osmand/Orux/Locus have possibilities to visualize explicit access (that some mappers find "unnecessary" since they consider them "default") for data users who value them.
You can of course disagree in how you weigh the importance of such tags, but the point in this context is that a validator in a map editor should not force one viewpoint in this discussion upon its users. Users should be able to trust that when a validator states that a tag is "unnecessary" (whether with or without an auto-fix), there is a strong consensus in the mapping community that this is indeed true. In this case there is no strong consensus that these tags are (a) unnecessary and (b) should be removed.
On the contrary: even in the extreme case of a motorway
(where I personally would't take the effort to add motor_vehicle=yes
) wiki states
While the box on the right lists some implied tags, they have been changed several times, they are often country-specific and the community does not agree about the implications. It is suggested to include implied tags when mapping motorways regardless.
And on the wiki for the proposal formerly known as Default it is stated:
Note that explicit tagging of access repeating what following tables imply may be still useful.
So if someone wants remove or discourage explicit access tags that some may consider unnecessary, this validator is not the place and therefor the removal of this warning would be very much appreciated.
comment:5 by , 3 years ago
So then the question I guess is: do we keep the warning that motor_vehicles=yes
on highway=tertiary
and above is unnecessary and remove the warning for anything below highway=tertiary
? That way there is a compromise AND I think it would be safe to say the general consensus would be that on highway=tertiary
and above the usage by motor_vehicles
is implied.
I do agree that on highway=residential
roads motor_vehicles=yes
could be useful and that motor_vehicle=yes
might be unnecessary on highway=tertiary
and above.
Either way this is an easy patch to make.
by , 3 years ago
Attachment: | 19996_v1.patch added |
---|
Here is the patch that removes the warning on features with highway=<anything less than tertiary> and motor_vehicles=yes.
comment:6 by , 3 years ago
Thanks for proposing this compromise!
For my personal mapping interests (which focus on lower level highways) that would be sufficient if at the same time the autofix would be removed for the higher level roads (to prevent undiscussed mechanical edit of tags) and the warning would be downgraded to info-level (just like the solution for #19930).
At the same time the O in OSM requires us to consider other people's mapping interests as well and from a wider (and also more principal) standpoint I still think it would be best (and simplest) if the warning would be removed altogether.
This is because even in the case of motorway
(where I would not bother to tag motor_vehicle=yes
) removing such a tag is controversial As the wiki for motorway states
Implies: motor_vehicle=yes [...]
It is suggested to include implied tags when mapping motorways regardless.
And please consider the example I gave about existing highway=trunk
where motor_vehicle
is not yes
but permissive
:
If another mapper wanted to register which trunk-roads have a legally enshrined right of access for motor_vehicle (right-of-way) and on which access is only permissive, he or she may -following the wiki for access- very well use motorvehicle=yes
on the ways where a right of has has been established (looking at current taggin of trunr roads that are only permissive shows that you can not rely on the absence of a motor_vehicle=permissive tag to know what the basis for the right of way is).
Why would we obstruct such a project by deleting (or discouraging) tags the you and I may not find that interesting?
A motor_vehicle=yes on such a road does not hurt anyone's interests (easy to scrub of when handling downloaden OSM-data), but deleting it from our shared database might. Cheers.
by , 3 years ago
Attachment: | style1.JPG added |
---|
comment:7 by , 3 years ago
motor_vehicle=yes also include the possibility to use the road for mofa, moped but also agricultural
Routing from A to B, calculated, but others are routing using the map, like to see the map (overlay style) and decide on each corner where to go. A *=yes conformation for a type of transport or combination (hierarchy) is important.
A map for overview and detail.
I use this in OSMand, my own style. For a transportation mode, what can I ride and where not.
How to write a style, what takes into account country defaults and also take into account the hierarchy.
For me a default does not work that well, motorway okay, but all the other highway a conformation on some ways is welcome.
In this image the tab moped hierarchy is styled (right side) to see the transportation mode yes above a higher combination in the hierarchy.
From this website,MTM Which is not working well, older code and the amount of code in the style, retrieved with the overpass query.
Map, you want also overview, that is not working well here.
A yes conformation is important, mainly for the not such a big groups like mofa, moped, agricultural.
When possible use a combination transport key.
If people are tagging it, it is okay. Do not push to delete it.
by , 3 years ago
Attachment: | 19996_v2.patch added |
---|
This patch gives warning that "motor_vehicle" on tertiary_link and above have the warning "Optional tag motor_vehicle=yes". Anything below tertiary_link is excluded.
comment:8 by , 3 years ago
patch 19996_v2.patch gives warning that "motor_vehicle=yes" on tertiary_link and above have the warning "Optional tag motor_vehicle=yes". Anything below tertiary_link is excluded.
comment:10 by , 3 years ago
Summary: | Warning "motor_vehicle=yes is unnecessary" for multiple highway types is incorrect; leads to deletion of valid data → [PATCH] Warning "motor_vehicle=yes is unnecessary" for multiple highway types is incorrect; leads to deletion of valid data |
---|
comment:11 by , 3 years ago
Cc: | added |
---|
comment:14 by , 3 years ago
Milestone: | → 21.06 |
---|
So what exactly needs to be removed here? What scenarios and combinations of tags are to be excluded?