"Mike Baggaley" <mike@tvage.co.uk> writes:
In the case I showed, I would probably have tagged it as you mention in view A as there is a parking aisle drawn. However, many small car parks do not
I left a note to check it next time I'm there. My town is only a 10 mile march to the Old North Bridge :-)
have parking aisles, and in that case I would not probably draw a footpath right across the car park and would go for view B. As one can normally walk anywhere on a car park, by definition you can also walk around the edge to any connected point, hence it seems reasonable to me to add the car park perimeter as foot routable. If you use Foot (OSRM) instead of Foot (GraphHopper) for OSM routing, it does take you around the edge of the car park.
Interesting that it's doing that. It's odd, because it will only transition from parking_aisle to perimeter where the driveway crosses on the way out. And representing the way that is the perimeter as foot routable is also not how it really is.
For vehicles, I would only expect a car park to be a start point or an end point, so it does not need to be routable. In the case of a fence, the
I find it useful to be able to navigate to a particular point in a large lot.
route around the edge is a routing artefact and you would actually walk across it, so if two paths join a car park you should be able to walk between them whether or not there is a fence around the edge.
I don't follow that. Many lots have fences that humans cannot pass.
Perhaps a better solution would be to join each point that stops at the edge of a car park together with a routable way. A new option to handle this?
I don't see why ways that go in/out should be joined at all to the area, and would say it's wrong to do that. At least unless the perimeter way is represented as a routable area. As for "small car parks", I always draw a way that is how you get in and go betwween two places to park. I don't have trouble knowing how to draw this, given imagery and having been there. Really, I don't see what's wrong with A: directly represent things that can be done. The only objection feels theoretical. So far I am not at all convinced that mkgmap should do anything other than straigthforwardly translate the map data.