
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@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/patch-v1-link-pois-to-ways-and-restrictions-t... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev