[mkgmap-dev] [patch v1] link-pois-to-ways and restrictions

Sat Dec 28 10:33:20 GMT 2013

Hi WanMil,

attached is a patch for r2914. It fixes the problem with --link-poi-to-ways that
was introduced with r2790 in the branch.
With this patch the option should again work like in trunk r2889.
If you think it is okay please commit it and 
I'll post a 2nd version of the link-pois-to-ways patch
later.

Gerd

> Date: Fri, 27 Dec 2013 21:42:59 +0100
> From: wmgcnfg at web.de
> To: mkgmap-dev at lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] [patch v1] link-pois-to-ways and restrictions
> 
> Hi Gerd,
> 
> r2790 is quite old. I have tested the link-pois-to-ways code at some 
> time after that but maybe I did check access restrictions only. The 
> change was intended to implement the calculation at one point only. The 
> main idea is, that there is a clear distinction between code before 
> postConvertRules() and after that. Code before postConvertRules() can 
> use (and has to implement) several more tags than after postConvertRules().
> 
> I get the feeling that it might be easier to move the handling of the 
> link-pois-to-ways to an earlier point in the processing. The current 
> code is quite complicated. Maybe it could be moved after processing the 
> points style file and just before processing the lines and polygons 
> style file. At this point modifications might be possible on the OSM way 
> data like we do before the style processing is started (e.g. 
> LinkDestinationHook).
> 
> If you want to leave the code where it is I would recommend to put the 
> mkgmap:road-speed calcs etc. to separate methods so that they can be 
> called from postConvertRules() and the pois handling. That also 
> encapsulates these tags.
> 
> WanMil
> 
> > Hi WanMil,
> >
> > it is probably better to change the POI code so that it creates modified
> > copies of the
> > corresponding GType instance instead of adding tags.
> > The code adds a tag like mkgmap:road-speed=-1
> > to the a part of the way, but that is not evaluated later.
> > Before r2790, the tag was evaluated, but the code did
> > not verify whether the way already contained the
> > same key with maybe mkgmap:road-speed=+2.
> > I'll try to fix it tomorrow.
> >
> > Gerd
> >
> >
> > GerdP wrote
> >> Hi WanMil,
> >>
> >> with r2790 you moved the code to evaluate mkgmap:road-speed from
> >> addRoadWithoutLoops() to postConvertRules().
> >>
> >> Gerd
> >> WanMil wrote
> >>>> Hi WanMil,
> >>>>
> >>>>   > > well, I think that means that part 1) is not yet working.
> >>>>   >
> >>>>   > No, I really only tested part 2), so I tested barriers only.
> >>>>   > Now I've tested part 1) also but it does not seem to work.
> >>>>   >
> >>>>   > I've changed the rule in the points file to
> >>>>   > barrier=bollard | barrier=cycle_barrier
> >>>>   > { set mkgmap:road-speed=0; }
> >>>>   >
> >>>>   > But the road speed of ways with barrier=bollard does not seem to be
> >>>> changed.
> >>>> yes, neither the patched version nor trunk do work.
> >>>>
> >>>>   >
> >>>>   > > I am not sure, but I think you moved the evaluation of the
> >>>>   > > tags mkgmap:road-speed and mkgmap:road-class
> >>>>   > > so that the interpretation of the POI has no effect.
> >>>>   > > Was that intended?
> >>>>   >
> >>>>   > I don't understand. Which commit do you mean? Your patch is for r2907
> >>>>   > and I don't think that there was any change after that?
> >>>>
> >>>> I meant the change in the branch. The tag is now only
> >>>> evaluated in postConvertRules(), and that is called before
> >>>> the POI evaluation.
> >>>
> >>> I checked all commits back to r2851 from Dec 1st but didn't find the
> >>> point you are addressing.
> >>>
> >>> Can you please also check which commit do you mean?
> >>>
> >>>>
> >>>>   >
> >>>>   > >
> >>>>   > > >
> >>>>   > > >
> >>>>   > > > >
> >>>>   > > > > The patch also changes the meaning of route restrictions.
> >>>>   > > > > In r2907 and before, route restrictions prohibit access for
> >>>>   > > > > pedestrians and emergency, the patched version
> >>>>   > > > > allows them by default.
> >>>>   > > >
> >>>>   > > > Does that mean a common turn restriction from a=>b also means
> >>>> that
> >>>>   > > > pedestrians never can route a=>b?
> >>>>   > >
> >>>>   > > yes, in trunk all turn restrictions are created without an
> >>>> exception
> >>>>   > > for pedestrians or emergency.
> >>>>   >
> >>>>   > Funny bug. I wonder why the exceptions for pedestrians and emergency
> >>>> is
> >>>>   > implemented different to the other exceptions?
> >>>> The bits are coded at a different place, see
> >>>> wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/NOD_Subfile_Format#Table_C
> >>>
> >>> Ah, that's a funny bit coding within the Garmin format....
> >>>
> >>>>
> >>>> Gerd
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> mkgmap-dev mailing list
> >>>>
> >
> >>> mkgmap-dev at .org
> >
> >>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> >>>>
> >>>
> >>> _______________________________________________
> >>> mkgmap-dev mailing list
> >
> >>> mkgmap-dev at .org
> >
> >>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> >
> >
> >
> >
> >
> > --
> > View this message in context: http://gis.19327.n5.nabble.com/patch-v1-link-pois-to-ways-and-restrictions-tp5790650p5790993.html
> > Sent from the Mkgmap Development mailing list archive at Nabble.com.
> > _______________________________________________
> > mkgmap-dev mailing list
> > mkgmap-dev at lists.mkgmap.org.uk
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> >
> 
> _______________________________________________
> 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/20131228/a82b6467/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: road-speed-poi-v1.patch
Type: application/octet-stream
Size: 11325 bytes
Desc: not available
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20131228/a82b6467/attachment-0001.obj>