[mkgmap-dev] default style lines enhancements

Tue Jul 28 17:12:17 BST 2020

On Tue, 2020-07-28 at 08:52 -0400, Greg Troxel wrote:
> Ticker Berkin <rwb-mkgmap at 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