
On Tue, 2020-07-28 at 08:52 -0400, Greg Troxel wrote:
Ticker Berkin <rwb-mkgmap@jagit.co.uk> writes:
With the data as it stands, for sensible routes in the above situation and others as expressed in my earlier email, mkgmap needs to generate footways that join up all ways that lead into the car park with a footway. With the current technology this can be done with circumference footway and mkgmap:set_{semi_/un}connected_type provide a really good way of not doing this where the footway won't solve any routing issue and might cause routing island problems.
And it will generate paths that may not actually exist, or might be signed no trespassing. Gerd has said that he doesn't want to synthesize data that isn't in OSM, and I think this is wise.
It is a public car park; you need to be able to walk to or from any point as that's where your car might be.
I wouldn't object if OSM mappers joined all paths and the entrance road/parking aisles within the car park and maybe there should be a policy to do this and then there is no problem.
There is broad consensus that this is the right thing to do. Editors warn about "way end close to other way".
However, there is a good argument that the correct OSM mapping is to show paths exactly as they are and not have to invent and add 'virtual' bits of footpath just to keep routing engines working sensibly because "mkgmap expects it like that".
It is not about mkgmap. It is pretty much all routers. A path represents "you can travel along this way with this mode and this access". That's exactly what is going on, at a simple level. At a more complicated level, you can claim that the parking lot is pedestrian way, but that isn't really true. It's really that the thing that looks like a path comes to the edge of the path and there is a way to continue walking onto pavement to get to the space between aisles.
I'm trying not to imagine anything that looks like a path, but I would consider it like a pedestrian area where you can walk anywhere reasonable within it. There isn't a method of representing this in a Garmin .img such that routing works in the expected way, and the next best thing, that solves the routing problems and that we can do with current technology, is to generate a foot routable navigation around the circumference. If this was to use an invisible line would you object less?
If there is a sidewalk around the lot, then map it. And add ways to get from sidewalk to the middle.
I wouldn't want to add more than the minimum extra routes. The circumference is this minumum number. Routes to the middle are not the problem, but, as Gerd points out, having mkgmap decide where the middle is could be very wrong.
Other things that have been mentioned:
- What about a path that runs up to or along the side of a car park but there is no access between them, eg an enclosed car park with a road along-side. I'd say that this is just incorrect mapping if the car park shares a node with the road but there is a barrier between.
It is almost always (alwyas?) incorrect to have a parking lot share a node with a road. That would imply that the parking lot beings on the road centerline.
- If starting within the car park, the route might tell you to walk around the edge rather that direct to the highway. Yes and no; it will plot a route to the closest edge and then to the best exit for the final destination; It should be obvious to the GPS user that they can just walk directly to the best exit. Without the change the only option you might get is onto the road network which could be entirely wrong.
with correct mapping, you usually get a sensible route along parking aisles.
The debate about what is correct mapping is open. I think mkgmap/default style should provide the best routing given the existing data.
I really do not understand the resistance to making the map data represent what you can do on the ground. It seems really obvious that this is sensible, and that is the majority view within osm tagging.
I don't have any objection to this, but it doesn't work with what I often see on the ground, which is: 1/ an area where (sometimes free-format) parking is allowed. 2/ an access track that runs to the boundary that allows vehicles and links to the road system. 3/ multiple foot paths that start on the boundary of the car park. Ticker