[mkgmap-dev] option link-pois-to-ways information

Wed Feb 16 11:33:57 GMT 2022

Hi Gerd

I've been testing with all the routing-island options set to -1 and
the small road network has 2 connections to the wider network, so I
don't think it is related.

If the destination in the small network is only accessible by (joined,
I think, but not tested) roads with throughroute=no, then it uses them
rather than the footpath.

If there is no footpath, so the only access to the destination (on a
throughRoute) is via a throughRoute=no, it resorts to straigh-line
routine

All above is Basecamp. Mapsource overrides throughRoute=no instead of
car=no

Ticker

On Wed, 2022-02-16 at 09:25 +0000, Gerd Petermann wrote:
> Hi Ticker,
> 
> reg. routing problems in Basecamp:  Maybe you hit the problem
> described for --max-routing-island-len?
> 
> Gerd
> 
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> Gesendet: Dienstag, 15. Februar 2022 17:41
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] option link-pois-to-ways information
> 
> Hi Gerd
> 
> highway=street_lamp was just an example of a POI that can get linked
> to
> a WAY that can be ignored. There are others that are valid OSM
> tagging
> that are irrelevant to the highway behaviour.
> 
> Actually, regardless of --link-pois-to-ways, there is a problem in
> the
> scenario where there is typical road system linked to a small road
> system by just a road with mkgmap:throughroute=no and a footway.
> BaseCamp and the eTrex 30x really will route over the footway to get
> into the small road system. MapSource and, I think, the eTrex HCx
> will
> use the road.
> 
> I realise that this set-up seems unlikely, but can happen if there is
> an inconsistency in the tagging of roads in the small system that
> results in one not having mkgmap:throughroute=no that is joined to
> the
> footway. My example happened in a business park.
> 
> My style makes this problem more likely to happen, while also trying
> to
> fix it, by not setting mkgmap:throughroute=no unless there seems to
> be
> a good reason for it. Good reasons are when there is a barrier on a
> service road. This is the test I want to improve.
> 
> Ticker
> 
> On Tue, 2022-02-15 at 14:12 +0000, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > if you find highway=street_lamp nodes on highway=* ways those are
> > errors and should be fixed in OSM.
> > Street lamps are normally mapped along the road, not on the road.
> > 
> > Maybe you meant highway=traffic_signals?
> > 
> > Besides that Basecamp should never route a car over a footway. That
> > sounds like an error in the map data produced by mkgmap
> > or maybe you used wrong routing settings. Please let me know how to
> > reproduce.
> > 
> > No idea if your proposed change would improve routing, but feel
> > free
> > to experiment with that.
> > 
> > Gerd
> > 
> > ________________________________________
> > Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> > von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> > Gesendet: Dienstag, 15. Februar 2022 13:37
> > An: mkgmap development
> > Betreff: [mkgmap-dev] option link-pois-to-ways information
> > 
> > Hi all
> > 
> > To improve routing, I'd like to get information about the POIS that
> > are
> > being linked to a WAY that can be used as part of the style/lines
> > processing.
> > 
> > The problem I'm trying to solve is to restrict car routing through
> > some
> > types of very low level roads (eg service) when there is a barrier.
> > Setting mkgmap:throughroute=no on these works nicely with MapSource
> > and
> > older devices but BaseCamp and newer devices will happily route
> > over
> > a
> > footpath to avoid a throughroute=no section.
> > 
> > At the moment, with --link-pois-to-ways, if the POI has a barrier
> > or
> > highway tag, mkgmap:way-has-pois is set true. This can be tested by
> > lines, inc/access etc, but there is no way to find out if it is a
> > significant barrier or something like highway=street_lamp.
> > 
> > points processing can set mkgmap: access & road_speed/class
> > variables
> > that are handled by inbuild code after lines processing to imposes
> > more
> > restrictions on the way and/or reduces speed/class; this is no use
> > for
> > what I want to do.
> > 
> > Possibilities are:
> > 1/ have options to say which POI tag/value combinations cause
> >    link-pois-to-ways
> > 2/ set new variables on the way, eg
> > mkgmap:barrier_tags/highway_tags,
> >    which are a list of distinct POI highway/barrier tag values.
> > 
> > Ticker
> > 
> > 
> > 
> > _______________________________________________
> > mkgmap-dev mailing list
> > mkgmap-dev at lists.mkgmap.org.uk
> > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> > _______________________________________________
> > mkgmap-dev mailing list
> > mkgmap-dev at lists.mkgmap.org.uk
> > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> 
> 
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev