logo separator

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

From John Thorn johnrthorn at gmail.com on Tue Jul 28 12:12:37 BST 2020

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

> Send mkgmap-dev mailing list submissions to
>         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
>
> You can reach the person managing the list at
>         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>
> To: mkgmap development <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>
> To: 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
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20200728/1b2f1aa9/attachment.html>


More information about the mkgmap-dev mailing list