logo separator

[mkgmap-dev] default style lines enhancements

From Greg Troxel gdt at lexort.com on Tue Jul 28 00:28:02 BST 2020

"Mike Baggaley" <mike at 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.


More information about the mkgmap-dev mailing list