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