#17542 closed defect (fixed)
Check segregated keys before autofixing foot/cycleway access [PATCH]
Reported by: | anonymous | Owned by: | team |
---|---|---|---|
Priority: | normal | Milestone: | 19.03 |
Component: | Core validator | Version: | latest |
Keywords: | Cc: | mkoniecz |
Description
After #9257 JOSM could delete usable information.
For example, if we have a tagging, like this:
highway=cycleway
foot=designated
bicycle=designated
segregated=yes
in this example the new autofix rule wants to delete the bicycle=designated
tag. It would be okay, but it ignores the segregated
key.
I suggest that before running the above autofix rule (added in r14918), check segregated
key and if it present with yes
or no
value, change the highway value to path. This way it becomes a valid tagging.
See the wiki for the tagging scheme: https://wiki.openstreetmap.org/wiki/Tag:highway%3Dpath
Please check it on overpass. I can't do it on global scale, because it running out server memory:
(highway=footway or highway=cycleway) and foot=designated and bicycle=designated and segregated=*
The new rule could be applied to:
highway=<footway/cycleway>
foot=designated
bicycle=designated
segregated=<yes/no>
Attachments (0)
Change History (15)
comment:1 by , 6 years ago
comment:3 by , 6 years ago
But first I need to wait for https://josm.openstreetmap.de/changeset/14942/josm to replicate to a JOSM git mirror.
comment:4 by , 6 years ago
https://github.com/matkoniecz/josm/commit/2b4c6e13e5daf7271a4392c847cc371c632ad584
patch at https://github.com/matkoniecz/josm/commit/2b4c6e13e5daf7271a4392c847cc371c632ad584.patch
Complains also about underlying data issue (highway=footway
+ bicycle=designated
was already detected).
comment:5 by , 6 years ago
Summary: | Check segregated keys before autofixing foot/cycleway access → Check segregated keys before autofixing foot/cycleway access [PATCH] |
---|
follow-up: 7 comment:6 by , 6 years ago
If preferable I may also make patch solely stopping validator from running autofix in such situation.
comment:7 by , 6 years ago
Replying to mkoniecz:
If preferable I may also make patch solely stopping validator from running autofix in such situation.
I don't know which is better. Autofix to path or just simply warn. The affected ways were probably already tagged with path but since iD doesn't support the generic path scheme (yet), users replacing it with footway or cycleway.
This was reported by you nearly 5 years ago... https://github.com/openstreetmap/iD/issues/2327
comment:8 by , 6 years ago
This was reported by you nearly 5 years ago...
In that situation waiting for iD is probably not too useful.
Autofix to path or just simply warn.
My current patch shows warning, suggests path and is not running bicycle=designated
removal for such case.
I may add autofixing to path.
comment:10 by , 6 years ago
I just note that OSM wiki is not consistent in this question (highway=cycleway + foot=designated + segregated=yes/no vs. highway=path + bicycle=designated + foot=designated + segregated=yes/no)
According to this page the highway=cycleway+foot=designated is still a legal combination:
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dcycleway
In my country (Hungary) this is the preferred tagging method for combined cycle- and footways.
By the way if you change a
highway=cycleway (implies bicycle=designated !)
foot=designated
tag to
highway=path
foot=designated
bicycle=designated
you will unintentially enable horse=yes on that road, according to this often referred proposal:
https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions
Best regards,
András
comment:12 by , 6 years ago
Milestone: | 19.03 → 19.08 |
---|---|
Resolution: | fixed |
Status: | closed → reopened |
The ticket main reason was the segregated
key problem, the secondary the path thing. mkoniecz's fix solved that, which invalidated the segregated issue because the path scheme has integrated preset support and it is automatically adding the segregated key.
Some people like the non-path scheme in #17901. I don't get it, but don't care. The fix is reverted and there is still no segregated key check. The wiki says "this key has no default value and should be tagged on all shared ways".
I care about the data. Where is the segregated key check?
Scheme | Type | @count | @count:nodes | @count:ways | @count:relations |
---|---|---|---|---|---|
Path | foot&bicycle designated | 346 456 | 7 | 346 429 | 20 |
Path without segregated key | foot&bicycle designated | 74 722 | - | 74 712 | 10 |
Non-path | cycleway | 158 770 | 5 | 158 764 | 1 |
footway | 33 695 | - | 33 687 | 8 | |
cycleway+footway | 192 465 | 5 | 192 451 | 9 | |
Non-path without segregated key | cycleway | 77 584 | 3 | 77 580 | 1 |
footway | 17 663 | - | 17 658 | 5 | |
cycleway+footway | 95 247 | 3 | 95 238 | 6 |
Some calculations from the table:
- the path scheme has a 17,74% error rate(=shared way without segregated key)
- the non-path has 33,10%
- the path scheme used 1,46 times more
- the non-path error rate is 1,87 times bigger
I don't see a reason why would the error rate going down in the future. I assume we are building a database and don't want to make a few people happy at the expense of the data quality.
Overpass example query https://overpass-turbo.eu/s/KWt The data in the table was gathered on 2019.07.21.
comment:13 by , 6 years ago
I shouldn't do math after midnight... The above calculations are wrong, here are the good ones:
- the path scheme has a 21,57% error rate
- the non-path has 49,49%
- the path scheme used 1,80 times more
- the non-path error rate is 2,29 times bigger
comment:14 by , 6 years ago
Milestone: | 19.08 → 19.03 |
---|---|
Resolution: | → fixed |
Status: | reopened → closed |
Let's keep that ticket for the specific fix in march.
New enhancement ticket: #17973
@mkoniecz: can you please make a patch?