logo separator

[mkgmap-dev] mkgmap-dev Digest, Vol 144, Issue 42

From Gerd Petermann gpetermann_muenchen at hotmail.com on Tue Jul 28 12:39:01 BST 2020

Hi John,

where would this node be? Think of L- or U-shaped areas around shops.

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von John Thorn <johnrthorn at gmail.com>
Gesendet: Dienstag, 28. Juli 2020 13:12
An: mkgmap-dev at lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 144, Issue 42

Just another idea....

Is it possible to make the car park a (pseudo) node that is on all the paths that connect to the car park?

John Thorn

On Tue, 28 Jul 2020 at 12:00, <mkgmap-dev-request at lists.mkgmap.org.uk<mailto:mkgmap-dev-request at lists.mkgmap.org.uk>> wrote:
Send mkgmap-dev mailing list submissions to
        mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk>

To subscribe or unsubscribe via the World Wide Web, visit
        http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
or, via email, send a message with subject or body 'help' to
        mkgmap-dev-request at lists.mkgmap.org.uk<mailto:mkgmap-dev-request at lists.mkgmap.org.uk>

You can reach the person managing the list at
        mkgmap-dev-owner at lists.mkgmap.org.uk<mailto:mkgmap-dev-owner at lists.mkgmap.org.uk>

When replying, please edit your Subject line so it is more specific
than "Re: Contents of mkgmap-dev digest..."
Today's Topics:

   1. Re: default style lines enhancements (Ticker Berkin)
   2. Virtual paths (ael)



---------- Forwarded message ----------
From: Ticker Berkin <rwb-mkgmap at jagit.co.uk<mailto:rwb-mkgmap at jagit.co.uk>>
To: mkgmap development <mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk>>
Cc:
Bcc:
Date: Tue, 28 Jul 2020 10:58:30 +0100
Subject: Re: [mkgmap-dev] default style lines enhancements
Hi all

In some major walking areas there are networks of paths with a few car
parks around the edge, normally set 100m or so into the park/woods. The
free maps one can obtain show suggested trails and these trails often
cross multiple car parks. The maps probably don't show a path within
the car park and there is no physical manifestation of it.

Without "paths around car park", if I try to use my device to generate
a walking route to some feature in the area (or back to the start), it
will probably generate a route that leaves the area, gets onto the
closest road, and re-enters elsewhere. Or it might give a "Route
Calculation Error" because paths closest to the start or end are not
connected to the rest of the network.

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.

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.

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

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.

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

Ticker





---------- Forwarded message ----------
From: ael <witwall3 at disroot.org<mailto:witwall3 at disroot.org>>
To: mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk>
Cc:
Bcc:
Date: Tue, 28 Jul 2020 11:44:52 +0100
Subject: [mkgmap-dev] Virtual paths
On Tue, Jul 28, 2020 at 10:58:30AM +0100, Ticker Berkin wrote:
> road/parking aisles within the car park and maybe there should be a
> policy to do this and then there is no problem.
>
> 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".

Not just mkgmap. It is a general problem. Maybe OSM should introduce
a new relation "connected"? That is one or more ways and/or points could
be members implying that it is possible to navigate (perhaps directly)
between any of them. That would solve many of the problems for all
routers. This idea needs expansion: a tag on the relation would specify
the mode of transport, although I guess this would be mainly foot.
Likewise, some sort of seasonal tag would be useful. But most of those
already exist for ways, so I suppose those could be just be applied to
the relation as well.

Just musing out loud. If it seems sensible, maybe a proposal on the
tagging list?

ael


_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk>
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


More information about the mkgmap-dev mailing list