[mkgmap-dev] default style lines enhancements

Tue Jul 28 18:18:33 BST 2020

Ticker Berkin <rwb-mkgmap at jagit.co.uk> writes:

>> 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 thought we were talking about things that were outside of the car
park, with paths that sort of went to it, that people declined to attach
to the ways.

>> 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.

I think we are not really communicating well and that could be my
fault.  I am seeing the larger OSM system, with tags that have meaning,
and routers that process those tags.   So the first goal is to have the
tags/objects in OSM actually represent reality.  Then to transform those
into the data that the routing engine uses.

In a car park, there are essentially always parking aisles, and that is
normally used for foot navigation only.  A carpark that is a big area
that doesn't have these is more or less not mapped correctly and should
be fixed.

If there really aren't any, then it needs some kind of tags that
everyone - not a special mkgmap custom - agrees that it represents a
pededstrian area.

> 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 you are only talking about making the Garmin routing follow the
semantics that everybody agrees is already expressed in OSM, then I
don't have any problem with it.  But in this discusison people are
talking about routing between paths that come close to a car park and
are not joined to the aisles as if that is correct.  That's really what
I think is wrong.

>> 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

I am talking about adding things that exist to OSM here.

> 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.

Do you think that there is a consensus in OSM that amenity=parking is by
definition a routable pedestrian area?  I find no trace of that notion
at  https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking
which shows parking aisles in the example.

> The debate about what is correct mapping is open. I think
> mkgmap/default style should provide the best routing given the existing
> data.

I think it's reasonable to process multiple tagging styles if each has
some adherents.  What I don't think ok is to magically join paths that
are near car parks to the car park.  I haven't heard anyone say that
this is a good representation and that routers should interpret these
gaps as routable.

>> 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.

If it's not free form the aisles should be drawn.  So we are now only
talking about areas that have no aisles.

> 2/ an access track that runs to the boundary that allows vehicles and
> links to the road system.

What I do for basically dirt parking lots with no lines, is to draw the
driveway going more or less in the middle basically to the other edge.
That is a proxy for being able to drive anywhere, a blend of what's
phsyically there and conveying semantics that are closer to correct than
having to stop at the edge.

When I map, I consider having a highway-type way share a node with
amenity=parking to be incorrect.

> 3/ multiple foot paths that start on the boundary of the car park.

So then either

  1) add an explicit pedestrian routable area in OSM

  2) join those paths to the central driveway, possibly adding more
  notional aisles

  3) add a footway around the perimeter, representing that you can walk
  there, and join the paths to that.  Ignore the fact that maybe you
  can't see the footway in the dirt as not very important compared to
  creating objects that are not really wrong and convey the correct
  semantics.

Option 2 and 3 will work fine with substantially all routers.  Option 1
I expect to be trouble in many of them.  I see tagging as the process of
encoding semantics so that it can be used by data consumers,
particularly routers as it pertains to this discussion.  So the purity
of "there isn't a visible path" is far far less important than
representing connectivity so that a router gets a sensible answer.  I
see the map as strongly implying that if there isn't a connected path
you can't get from here to there.

One of the cases I'm worried about is a car park with a fence and then
making that way a pedestrian way and confusion with paths joined to the
fence.  Of course joining a path to a non-highway way is a bit sttange,
but we do it at building entrances.

The other case is simpler: a path that ends 1m before the fence.  From
that it's pretty clear you can't walk from the path into the car park.
It's important that routing not misjudge this case.

If you have tried multiple other routers with the data, and this is
about making the combination o mkgmap+garmin find similar routes that
most of the other routers finds, that's something else.