Opened 5 years ago
Last modified 4 years ago
#18763 new enhancement
Way terminates on Area is - sometimes - a False Positive? Slipway? Entrance?
Reported by: | AnkEric | Owned by: | team |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | Core validator | Version: | |
Keywords: | Cc: |
Description
Way terminates on Area is - sometimes - a False Positive ?
F.i.:
highway is connected to the boundary of [landuse=grass] and [natural=water].
Connecing Node: [leisure=slipway].
JOSM Validator: Way terminates on Area.
I found out - the hard way - two options are OK (accepted by JOSM Validator):
- highway, last node: [noexit=yes] (highway terminates and that's correct)
- highway --> [leisure=slipway] --> [waterway=*] (highway does not terminate and is "routable")
I noticed some mappers may decide to let highway and slipway END before it reaches the water.
Which is not correct for a slipway. IMO.
Same applies to a highway giving access to an Area/leisure. Even if I mark the connection as [entrance=main], JOSM Validator will trow a warning.
Again: [entrance=main] + [noexit=yes] will resolve. As a result: entrance that's not an entrance!
/ AnkEric
Attachments (6)
Change History (21)
comment:1 by , 5 years ago
Component: | Core → Core validator |
---|
comment:2 by , 5 years ago
Owner: | changed from | to
---|---|
Status: | new → needinfo |
comment:3 by , 4 years ago
Resolution: | → needinfo |
---|---|
Status: | needinfo → closed |
by , 4 years ago
Attachment: | Blokzijl_Haven_PDOK.png added |
---|
comment:4 by , 4 years ago
Resolution: | needinfo |
---|---|
Status: | closed → reopened |
This is not a DEFECT. Therefore not: Report Bug.
This is an enhancement on Validator, which might be regarded as "defect". But only if this warning is not correct.
Steps to reproduce: [highway=path] (landuse=grass) --> [leisure=slipway] --> [waterway=canal]
Tags:
- From Way (A) : highway=path (landuse=grass)
- Via Node (B) : leisure=slipway
- To Way (C) : waterway=canal (natural=water)
IMO: this is correct mapping.
JOSM Validator (Warning): "Way terminates on Area".
I can Resolve the Warning, by several options. But all options to Resolve - IMO - are less Quality Mapping.
Options to Resolve:
- OR: Delete [landuse=grass] (which is bad mapping).
- OR: Unglue <Via Node (B)>.
- OR: Unglue <Via Node (B)> and move slipway INTO the water or ONTO the land. Which is not preferred, because slipway is ON the boundary of land and water. Waterway ON land is not OK, highway IN water is not OK.
- OR: ADD [noexit=yes] to <Via Node (B)> (which is nonsense).
- OR: <To Way (C)> as [highway=path]. Now <To Way (C)> is routable. Therefore A does not terminate on Area! Is waterway=canal not routable?
This is just an example.
Similar issues:
- [highway=path] ends on [man_made=pier]. IF ([man_made=pier] + [highway=path]) it's routable and resolved. But this makes (more) sense since <Via Node (B)> is untagged and not slipway or entrance or barrier. Only objection: some routers do consider [man_made=pier] to be routable. Which does not require [highway=path].
- [highway=path] ends on [leisure=playground]
- [highway=path] ends on [leisure=playground] + [entrance=main] / [barrier=gate]
- Canoe Portage: [highway=path] + [portage=yes]. I don't know how to Resolve, how to Map. Except for 2x [noexit=yes] on Connecting Nodes, or DELETE [landuse=grass]. Which does resolve, but might be considered as "'Mapping' for the 'Validator'".
IMO:
- IF <Via Node (B)> = [leisure=slipway] or [entrance=*] or [barrier=*] (or ???) this should imply the highway does NOT terminates, but continues TO a "destination".
- Question: if the highway ends ON a destination (f.i. [leisure=playground] or building) this should imply the highway does NOT terminates, but continues TO THIS "destination".
- [waterway=*] is routable (should be considered as routable), therefore the original (first) example should not result in a warning.
by , 4 years ago
Attachment: | Canoe_Portage.png added |
---|
comment:5 by , 4 years ago
Owner: | changed from | to
---|---|
Status: | reopened → new |
comment:6 by , 4 years ago
Type: | defect → enhancement |
---|
comment:7 by , 4 years ago
Just my 2 cent:
For me a slipway is not only the part under water. I map also the part above water as slipway.
comment:8 by , 4 years ago
I agree your 2 cents makes sense.
But my two cents:
- I notice too many nodes [leisure=slipway] IN the water AND not connected to a highway. JOSM warning: "isolated node which must be connected to a way - leisure=slipway"
- OSM WIKI: [leisure=slipway] is NODE only. NOT: Way, Area. (https://wiki.openstreetmap.org/wiki/Tag:leisure=slipway)
Perhaps my request is not a JOSM enhancement, but should be an OSM Mapping issue.
But also: highway ends where water begins. Slipway is not a separate way. Slipway is: highway --> water.
To make this strange exception (a highway should never terminate on an area) acceptable, OSM Adds one node [leisure=slipway] to mark the "transition" highway --> water (way --> area). Like [entrance=*], [barrier=*].
Your argument also applies to canoe portage. Perhaps I should try to extend [portage=yes] ONTO land (like a bridge, also preferred not to terminate on landuse).
comment:9 by , 4 years ago
+1 for slipways as ways and with needed parts in both elements (water and air).
Meanwhile validator should
- treat
leisure=slipway
on open way ashighway=service
and not warn. - not warn about
highway=*
withentrance=*
with end node onbuilding=*
by , 4 years ago
Attachment: | leisure_slipway_2020-03-13.png added |
---|
comment:10 by , 4 years ago
[leisure=slipway]:
- Without (leisure=slipway) as Node slipway is not rendered (by JOSM).
- With (leisure=slipway) as Node I was expecting: "Nodes duplicating parent way tags". Not in this case, but for barrier=* (OSM, Used on: way, node, area) this warning would have be issued by JOSM Validator.
- [highway=service] + [leisure=slipway] OR: [highway=service] + [service=slipway] (IMO: last option is better). But again: NOT JOSM Validator issue, but OSM wiki.
More examples, highway terminates on ...:
- (building=yes, area): already accepted by JOSM Validator even without entrance (but not - always - accepted by Osmose).
- (amenity=parking, node/area) as : accepted by JOSM Validator.
- (tourism=viewpoint, node): accepted by JOSM Validator.
- (leisure=bird_hide, node): JOSM Validator Warning "leisure node connected to a highway". Therefore "my" footway will never connect to a bird_hide, which is IMO not correct.
- (leisure=playground, area): accepted by JOSM Validator, but ONLY if NOT ALSO Terminates on Area.
Other option (suggestion):
- A highway=service (and only highway=service) is allowed to Terminate ON or Connect TO (node or area).
- Therefore, bird_hide: [highway=footway] --> [highway=service] --> [leisure=bird_hide]. But this option is OSM, not JOSM Validator.
In general (for sake of arguments), IMO:
- JOSM Validator might have an effect on Mapping. Therefore JOSM Validator "False Positives" are not "harmless".
- JOSM renders Nodes, but not - always - Ways or Areas. Therefore (some) Mappers will prefer a Node to a Way or Area. This might be correct, or not...
- I would prefer this "Ticket for Enhancement" to have Status = "Discussion". Sorry, no option.
- We should agree first on what is best (or: good) before JOSM will Resolve/Enhance. Arguments by @mdk and @skyper are very useful (to me) in deciding what we want, or what we should want.
- OSM does/should decide how we should Map (wiki, best practice). JOSM should confirm to OSM "rules" (even if "we" or JOSM disagree). OSM wiki: leisure=slipway is Node only!
- Main question: should JOSM Validator be updated or OSM wiki? Which is leading?
- In general/exception: OSM proposals will takes years or decades to be "approved" (or "rejected")... Frustrating!
comment:11 by , 4 years ago
OSM does/should decide how we should Map (wiki, best practice). JOSM should confirm to OSM "rules" (even if "we" or JOSM disagree). OSM wiki: leisure=slipway is Node only! (@AnkEric)
This is "more or less complete and utter nonsense", even I don't agree: iD does set Mapping "rules" for Mappers!
Oké, than JOSM can do the same... IMO... -))
See: https://wiki.openstreetmap.org/wiki/Key:traffic_sign
traffic_sign:direction=forward/backward
The newest of the three tags, introduced by the iD editor in September 2018 because the editor couldn't handle traffic_sign:forward=*/traffic_sign:backward=*. This tag is equivalent to direction=*. (It is unknown why the key direction=*, which was also already in use, wasn't used instead.)
See: https://lists.openstreetmap.org/pipermail/tagging/2018-September/039481.html
Similar argument:
iD sets [area=yes] to "everything". Explicit tagging!??
And JOSM Validator warns: "unnecessary tag - area is unnecessary for leisure".
Who should I believe and trust?
follow-up: 13 comment:12 by , 4 years ago
I do not like what iD did/does with introducing tags or deprecating/changing tags like FIXME=*
, well, JOSM should not do it.
- Only tag I remember is
public_transport:version
which was introduced so far.- I did not check the ignores for
area is unnecessary for leisure
but there should be some. New ticket !
- I did not check the ignores for
- Validator will always be an edge case but false positives should be minimized on warning level.
- Geometry warnings are the more tricky ones and especially "way ends on area" and "crossing/overlapping ways/areas" need fine tuning. The second was fixed/updated, lately, and for sure is not perfect, yet. Please, either open tickets for each case or one listing each case, explicitly.
- In the past, the wiki was often not clear or outdated about the allowed object types for certain tags. I would tend to use taginfo as second source in these cases and start some discussion about adjusting the wiki and be more tolerant/open with object types than tags.
- For
slipway
the numbers on taginfo for ways are over 8000 (~22%).
- For
follow-up: 14 comment:13 by , 4 years ago
Replying to skyper:
- Only tag I remember is
public_transport:version
which was introduced so far.
- I did not check the ignores for
area is unnecessary for leisure
but there should be some. New ticket !
I just rechecked on the wiki and the only false positive with a doubtful wiki page is trampoline_park
which is not supported by JOSM at all. Only other tag with allowed type way and area is track
which is correctly ignored. All other values are only valid on nodes and areas.
comment:14 by , 4 years ago
Wait the wiki is controversial the leisure page lists it fo way + area and the own page only for node.
by , 4 years ago
Attachment: | OsmAnd_Low zoom_Slipway is Rendered.png added |
---|
by , 4 years ago
Attachment: | BAD Mapping by JOSM Validator.png added |
---|
by , 4 years ago
Attachment: | Way terminates on Area_Unconnected way.png added |
---|
comment:15 by , 4 years ago
Trying to finalize...
False positive Warning might have and will have less correct Mapping as a result. Self-critical example (AnkEric as inexperienced mapper, years ago).
Highway terminates on Area is a - correct and justified and valuable - Warning if it helps preventing unconnected highways.
Highway terminates on Area is a - correct and justified and valuable - JOSM Validator Warning IF:
- AND: Highway does ONLY terminate on an Area having [landuse=*], [natural=*], [landcover=*]
- AND: Highway does NOT terminate on an Area "suggesting a destination" ([leisure=*], [amenity=*], [tourism=*], [building=*]).
- AND: Highway does NOT have Node properties set on Last Node
- AND: Highway does NOT connect to a subsequent - routable - way.
Highway terminates on Area is False Positive if:
- OR: highway does connect to a subsequent - routable - way (highway or waterway), therefore routing continues, therefore highway does not terminate (subsequent way is "destination").
- OR: highway does connect to an Area having [amenity =*], [leisure =*], [tourism=*], [building=*] (area is "destination"). Best practice: add [entrance=main] or [barrier=gate) etc. on connecting node.
- OR: highway does have Node properties (tags) set on Last Node (node is "destination"):
- [noexit=yes] (implies: Unlikely, but Correct)
- [leisure=*] ([highway=slipway], [leisure =bird_hide], and ALL others)
- [amenity=*] (parking, bicycle_parking, restaurant, school, etc. Best practice: add [entrance=main] or [barrier=gate) etc. on connecting node.
- [tourism=*]
Arguments/discussion/justification/remarks/issues...
A highway does NOT "terminates" IF it continues as ROUTABLE way, or if it grants ACCESS to a Node or Area which might be considered to be a "destination".
JOSM Validator FIX: [waterway=*] implies routing (routable way).
To be ignored (not relevant for warnings): [highway/waterway] has [access=no] or [boat=no].
A highway terminating on [highway=street_lamp], [natural=tree], [tourism=information] (and 1001 other examples) does not make much sense.
But 90% of these exceptions do occur "on the ground" (as an exception to the "rule").
Also: what's the harm? If a path ends 5 meters before [tourism=information + information=map], [leisure =bird_hide] is this to be preferred to a connection?
JOSM Validor will NOT suggest (no warning) OSM should connect a highway to [amenity=bench], [leisure=picnic_table]. If OSM does connect (I don't agree), JOSM Validator will not issue a Warning. But there is no real harm if connected. Own responsibility of OSM Mapper.
No (missing) JOSM Validator Warning does not suggest Mapping could not be improved. ALL Mapping can be improved. Always!
Conflicting issue by JOSM Validator Warning: "tourism/amenity/leisure node connected to a highway".
JOSM Validator should (and often does) warn if a non-routable Object ([amenity=fuel],
[tourism=information + information=board/map/ guidepost], [leisure=picnic_table]) is connected to highway.
Which is conflicting to "Highway does have Node properties (tags) set on Last Node".
To Resolve: Do not warn if a Node-tag is Set on LAST Node of a highway (implies highway is "access to node").
Thanks for your report, however your ticket is incomplete and therefore not helpful in its current form.
Please add all needed information according to this list:
To ensure that all technical relevant information is contained, create new tickets by clicking in JOSMs Main Menu on Help →
Report Bug.
Remember: This is a generic notice so we don't need to write the same stuff again and again. It may only apply in parts to the specific case!