flag highway that terminates on amenity=parking

[GerdP]

We have a test WayConnectedToArea that complains when a highway terminates on a closed way tagged e.g. natural=wood or landuse=residential.
I was surprised to find out that this test doesn't complain when the closed way is tagged with amenity=parking.
I think it is a common tagging error. Mappers seem to assume that that a closed way with amenity=parking works similar to a closed way with highway=pedestrian?

A discussion in the mkgmap dev list shows there is no consensus about this:
​http://gis.19327.n8.nabble.com/default-style-lines-enhancements-tp5971280p5971549.html

If we decide that a JOSM treats an amenity=parking like a highway we should change other tests like UnconnectedWays,shouldn't we?

[skyper]

I'd prefer the opposite. amenity=parking is no highway=*. Adding area:highway=service would define it as the area of a highway but still it is no highway. Only highway=service together with area=yes is an highway=*

I even find amenity=parking share segments with highway=* for parking spaces along a road. I like to get a warning for this situation, as well.

[GerdP]

The current implementation may create multiple errors for the same highway end node, one for each area. In areas where landuse/natural areas are glued to roads this often means two or more error messages for the same node. I think JOSM should collect the parent area ways in one error message.
See e.g. n1205644259

[GerdP]

Another glitch: code added for #10655 doesn't suppress the warning when node is also connected to another landuse, see eg. n3541435109

[GerdP]

Work in progress:
Attached patch fixes the problems mentioned in comment:2 and comment:3
The code first checks if any connected way is a highway or another "valid" target like a building, a platform, a slipway or a route=ferry. If none is found and areas are found it will collect them for one error message.
The patch makes it more agressive as it will flag all areas listed in OsmPrimitive.hasAreaTags().

I'll try to use more code from UnconnectedHighways which also contains checks for "valid target nodes".
Not sure what to do with footways ending on leisure=playground, see e.g. way 132733958
It's probably not good to complain about this, esp. when I look at the other footway which ends before the playground.

[GerdP]

Thinking again about this I wonder why exactly this test was introduced with #2746. I don't understand the reasoning.
A highway ending somewhere is OK, but when it ends on a landuse boundary it produces a warning. What's the difference?
Is it about the rendering of landuse=residential which looks a bit like a minor highway?
The problem with amenity=parking exists when at least two highways end there at different nodes. In that case it is likely that a highway=service or highway=footway is missing, but this would require a different logic.

[skyper]

I am not sure, when highway end node near other highway was introduced, e.g. #4682 (duplicate of #2746) is about that. Once again we meet different styles of mapping concerning landuse and highway. A highway does usually not end at the border of an area (landuse) but either ends before or leads across into the next area. If a highway ends at the border it either has another highway connected at the end node or some barrier/entrance at the end node.

Is amenity=parking a route-able area? Reading the discussion at mkgmap-dev@, I would say we have two different kind of areas, route-able and non-route-able, but that only shifts the discussion to "which areas are considered route-able".

[GerdP]

I am not sure, when highway end node near other highway was introduced,

It was added with r3669, but I don't know how it worked then.

You are probably right, WayConnectedToArea is not about routing, more about mapping style. I'll change my patch to use the old filter for areas again and maybe I'll code something new for parking.

[reichg]

so is there any action that needs to happen for this ticket?

[reichg]

What're we thinking for this?