[PATCH] stop/continue scheme extended to style-rules without conversion
Moin, I have extended the stop/continue scheme to style-rules without conversions, i.e. a style rule might now look as follows: highway=* & surface=sand {set surface=unpaved} [continue] With this extension the incomplete rules should get an own priority, so that the processing order of such rules should be defined by their order in the style file. A compiled mkgmap based on the multiple_garmin_elements-mb.patch provided by Mark Burton on 20.09.2009 can be downloaded at: http://demuur.gmxhome.de/mkgmap_no_conversion_rules.jar So please try it out, until now I have tested the modification only on a rather simple example. And please let me know, whether the attached patch is usable, since this is my first generated patch. I simply asked svn for the differences between my local copy and the head version. Gruss Torsten
Hi Torsten,
And please let me know, whether the attached patch is usable, since this is my first generated patch. I simply asked svn for the differences between my local copy and the head version.
I haven't tried the patch but a quick look shows that it attempts to add some stuff that is already in the trunk so that patch will not apply without grumbling. Are you sure your patch is generated against the current trunk? Cheers, Mark
Spotted the problem, some of the patch is relative to 1143 and some of it relative to 1148. Don't know how you managed that. Perhaps an svn wizard can help.
Mark Burton schrieb:
Spotted the problem, some of the patch is relative to 1143 and some of it relative to 1148. Don't know how you managed that. Perhaps an svn wizard can help.
Ok, I tried a different button in svn and now got a patch relative 1143 only. Is this one better usable? Gruss Torsten
Moin, I have to admit, that I have didn't quite understand the processing of the action part of the style rules, when I made the first verwion of the patch. And I also have to admit, that I still do not really understand it. But nevertheless the new version of the patch seems to work for me under certain conditions. The style syntax ist still the same as in the first version, e.g.: highway=* & surface=concrete {set surface=deleted; set mkgmap_surface=paved} [continue] My patch now works in such a way, that this line will create a normal rule (with priority), but will not create an element in the output during the conversion. The stop/continue extension will loop through the conversion, until no more output types are found (including the empty outputs). During each iteration of the loop the pre and postprocessing is done. The problem now is, that I do not understand, how this processing works, i.e. how the single actions are choosen. This does not seem to matter, if the following condition is obeserved in the preprocessing rules: Each action rule must modify the tags of the element in such a way, that the condition is not fullfilled any more, when the rule is checked again. In the above example the action "set surface=deleted" takes care of this, afterwards the condition "surface=concrete" will not be true any more. So with the patch I was able to preprocess the osm-data with the following rules, to generate a road map, which only differs between paved and unpaved surface and is limited to roads, where motor cars ar e allowed (see preproccessing rules below). Gruss Torsten # Set highway names to include the reference if there is one highway=* & mkmap_name_fixed!=* {name '${name} (${ref})' | '${ref}' | '${name}' ; set mkmap_name_fixed=yes} [continue] #set mkgmap_surface values to either paved or unpaved highway=* & surface=paved {set surface=deleted; set mkgmap_surface=paved} [continue] highway=* & surface=unpaved {set surface=deleted; set mkgmap_surface=unpaved} [continue] highway=* & surface=asphalt {set surface=deleted; set mkgmap_surface=paved} [continue] highway=* & surface=cobblestone {set surface=deleted; set mkgmap_surface=paved} [continue] highway=* & surface=concrete {set surface=deleted; set mkgmap_surface=paved} [continue] highway=* & surface=paving_stones {set surface=deleted; set mkgmap_surface=paved} [continue] highway=* & surface=metal {set surface=deleted; set mkgmap_surface=paved} [continue] highway=* & surface=wood {set surface=deleted; set mkgmap_surface=paved} [continue] highway=* & surface=grass_paver {set surface=deleted; set mkgmap_surface=unpaved} [continue] highway=* & surface=gravel {set surface=deleted; set mkgmap_surface=unpaved} [continue] highway=* & surface=pebblestone {set surface=deleted; set mkgmap_surface=unpaved} [continue] highway=* & surface=grass {set surface=deleted; set mkgmap_surface=unpaved} [continue] highway=* & surface=ground {set surface=deleted; set mkgmap_surface=unpaved} [continue] highway=* & surface=earth {set surface=deleted; set mkgmap_surface=unpaved} [continue] highway=* & surface=dirt {set surface=deleted; set mkgmap_surface=unpaved} [continue] highway=* & surface=mud {set surface=deleted; set mkgmap_surface=unpaved} [continue] highway=* & surface=sand {set surface=deleted; set mkgmap_surface=unpaved} [continue] highway=* & surface=ice_road {set surface=deleted; set mkgmap_surface=unpaved} [continue] #set access values highway=* & mkgmap_routing!=* & motorcar=yes {set mkgmap_routing=allowed; set access=deleted; set bicycle=deleted; set motorcar=deleted; set motor_vehicle=deleted; set vehicle=deleted} [continue] highway=* & mkgmap_routing!=* & motorcar=designated {set mkgmap_routing=allowed; set access=deleted; set bicycle=deleted; set motorcar=deleted; set motor_vehicle=deleted; set vehicle=deleted} [continue] highway=* & mkgmap_routing!=* & motor_vehicle=yes & motorcar!=* {set mkgmap_routing=allowed; set access=deleted; set bicycle=deleted; set motorcar=deleted; set motor_vehicle=deleted; set vehicle=deleted} [continue] highway=* & mkgmap_routing!=* & vehicle=yes & motor_vehicle!=* & motorcar!=* {set mkgmap_routing=allowed; set access=deleted; set bicycle=deleted; set motorcar=deleted; set motor_vehicle=deleted; set vehicle=deleted} [continue] highway=* & mkgmap_routing!=* & access=yes & vehicle!=* & motor_vehicle!=* & motorcar!=* {set mkgmap_routing=allowed; set access=deleted; set bicycle=deleted; set motorcar=deleted; set motor_vehicle=deleted; set vehicle=deleted} [continue] highway=* & mkgmap_routing!=* & (access=* | vehicle=* | motor_vehicle=* | motorcar=*) {set mkgmap_routing=forbidden; set access=deleted; set bicycle=deleted; set motorcar=deleted; set motor_vehicle=deleted; set vehicle=deleted} [continue] highway=* & mkgmap_routing!=* {set mkgmap_routing=allowed; set access=deleted; set bicycle=deleted; set motorcar=deleted; set motor_vehicle=deleted; set vehicle=deleted} [continue] route=* & mkgmap_routing!=* {set mkgmap_routing=allowed; set access=deleted; set bicycle=deleted; set motorcar=deleted; set motor_vehicle=deleted; set vehicle=deleted} [continue] # if the routing is not allowed we need not to continue highway=* & mkgmap_routing=forbidden {set highway=ignore} [stop] route=* & mkgmap_routing=forbidden {set route=ignore} [stop] highway=unclassified & mkgmap_surface=unpaved [0x16 road_class=1 road_speed=1 resolution 22] highway=unclassified & mkgmap_surface!=unpaved [0x06 road_class=1 road_speed=4 resolution 22] ...
Hi As an aside, I always planned to have lists of values which might be useful in this case. Eg. the following
#set mkgmap_surface values to either paved or unpaved highway=*& surface=asphalt {set mkgmap_surface=paved ... highway=*& surface=cobblestone {set mkgmap_surface=paved ... highway=*& surface=concrete {set mkgmap_surface=paved ...
could be represented by highway=* & surface=(asphalt, cobblestone, concrete, ...) {set mkgmap_surface=paved (or with the keyword 'in' instead of = perhaps) does that sound useful? ..Steve
On Tue, Sep 01, 2009 at 08:14:43PM +0100, Steve Ratcliffe wrote:
Hi
As an aside, I always planned to have lists of values which might be useful in this case. Eg. the following
#set mkgmap_surface values to either paved or unpaved highway=*& surface=asphalt {set mkgmap_surface=paved ... highway=*& surface=cobblestone {set mkgmap_surface=paved ... highway=*& surface=concrete {set mkgmap_surface=paved ...
could be represented by
highway=* & surface=(asphalt, cobblestone, concrete, ...) {set mkgmap_surface=paved
(or with the keyword 'in' instead of = perhaps)
does that sound useful?
It would shorten some rules, such as this rule from my patch for bus/railway/tram stop names: (highway=bus_stop | railway=tram_stop | railway=halt | railway=station) & (shelter=yes | covered=yes) { name '${name|def:} ${ref|def:}+${operator|def:}'; } If you allowed the same syntax for keys, this rule would shorten to (highway=bus_stop | railway={tram_stop,halt,station}) & {shelter,covered}=yes Above, I used the {,} syntax that is familiar from tcsh and bash. The (,) or (|) syntax could be easier to implement in the grammar. Marko
On 01/09/09 17:36, Torsten Leistikow wrote:
Moin,
I have to admit, that I have didn't quite understand the processing of the action part of the style rules, when I made the first verwion of the patch. And I also have to admit, that I still do not really understand it. But nevertheless the new version of the patch seems to work for me under certain conditions.
They are run during matching which is why they are run in an arbitary order. This is a problem, but on the other hand if they are not run first, then it is not possible to use an action to change what is matched later on. Everyone relies on this quite heavily it seems. I think what we will have to do is create separate lists of actions and rules. Create a list of all matched actions and run them in the correct order first and then do the type rules. ..Steve
Steve Ratcliffe wrote:
On 01/09/09 17:36, Torsten Leistikow wrote:
Moin,
I have to admit, that I have didn't quite understand the processing of the action part of the style rules, when I made the first verwion of the patch. And I also have to admit, that I still do not really understand it. But nevertheless the new version of the patch seems to work for me under certain conditions.
They are run during matching which is why they are run in an arbitary order.
This is a problem, but on the other hand if they are not run first, then it is not possible to use an action to change what is matched later on. Everyone relies on this quite heavily it seems.
I think what we will have to do is create separate lists of actions and rules. Create a list of all matched actions and run them in the correct order first and then do the type rules.
Yeah that would sound better. I have not looked yet at the new patch, the thing needed desperately is to run the rules in several runs so that one can build up on previous rules, i.e have several rules that affect the name setting of the same street run one after another) However we should be able to use different names for the global index once it's implemented. So if searching for an address the streetname ist just the streetname and not attributes added to it. However I know of course that the address index is still a long way to go... Felix
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (5)
-
Felix Hartmann -
Mark Burton -
Marko Mäkelä -
Steve Ratcliffe -
Torsten Leistikow