[mkgmap-dev] option link-pois-to-ways information
From Ticker Berkin rwb-mkgmap at jagit.co.uk on 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
- Previous message: [mkgmap-dev] option link-pois-to-ways information
- Next message: [mkgmap-dev] option link-pois-to-ways information
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the mkgmap-dev mailing list