[mkgmap-dev] Commit: r1235: Fix hang on continue action.

Sun Sep 27 22:40:37 BST 2009

Steve Ratcliffe wrote:
> On 27/09/09 21:28, Felix Hartmann wrote:
>   
>> Thanks for your work, sadly though for me at the moment the style branch
>> is useless because continue on the strictly ordered style rules has no
>> effect. (I need to have the rules running not only in order, but also if
>> continue given, several rules on the same object. (actually I don't even
>>     
>
> Thanks for testing it.  I was trying out your style file and it didn't
> appear to be working for me either but I couldn't be sure, since I
> don't really know what it should be like.
>
> Obviously it is a bug if multiple lines are not being created.
>   
Multiple lines ARE created. but what does not work is rules like the 
following:

highway=primary                         { name '${name} pri' | 'primary' 
} continue
highway=*  { name '${name} (${ref})' | '${ref}' | '${name}' } continue

if a highway=primary has a reference set this case will result in the 
reference being dropped. I would need it to be run without the reference 
being dropped.

Actually this concept of continue is not ideal for such rules, best 
would be a command to start again from continue on all lines:
i.e.

I have a: highway=path; route=mtb; mtb:scale=0: mtb:scale:uphill=0

mtb:scale=0  & mtb:scale:uphill=0 & route=mtb { name 'mtbrt00 ${name}' | 
'mtbrt00' } continue
mtb:scale:uphill=0 & route=mtb { name 'mtbrt.0 ${name}' | 'mtbrt.0' } 
continue
mtb:scale=0 & route=mtb { name 'mtbrt0. ${name}' | 'mtbrt0.' } continue

highway=path                             { name '${name} pth' | 'pth' } 
continue

would make all three rules being enacted which I do not want, I only 
want to have further rules still run again on the same objects (if not 
yet written out to 0x* without continue).
best would be to have the continue tag working as a new pass, so on each 
continue tag, all objects (that are not yet written out to 0x* without 
continue) will be parsed again. so the resulting way would be named: 
name="mtbrt00mtbrt.0mtbrt0.{name}pth"
I wan't the result however to be "mtbrt00 {name} pth"

ideal would be to have inside the style-file the following:
mtb:scale=0  & mtb:scale:uphill=0 & route=mtb { name 'mtbrt00 ${name}' | 
'mtbrt00' } parseagain
mtb:scale:uphill=0 & route=mtb { name 'mtbrt.0 ${name}' | 'mtbrt.0' }
mtb:scale=0 & route=mtb { name 'mtbrt0. ${name}' | 'mtbrt0.' }

highway=path                             { name '${name} pth' | 'pth' } 
parseagain

to reach my above wanted result.

*Objects* should only be excluded after parsing through lines with 0x* 
but without continue. So I could start my style-file with boundaries 
with continue (before any rules are run)
then things I don't want to be considered for the main rules block like:

highway=motorway                 [0x1e resolution 16]
highway=motorway_link             [0x28 resolution 20]
highway=motorway_junction         [0x28 resolution 20]
highway=trunk                     [0x28 resolution 18]
highway=trunk_link                 [0x28 resolution 20]
highway=* & motorroad=yes         [0x28 resolution 18]
highway=* & motoroad=yes         [0x28 resolution 18]

Rules (run against everything that is still, in, but motorways are 
already out, the same for say railway=* & tunnel=* - objects which I 
don't need the main rules block to be run against so that it has speed 
improvements)

highway=* [0x* resolution * continue]

*Actually* it would be great if we could define a type, say 0x999999 
which drops items out from further processing because we don't want them 
to be displayed at all in our map. I.e. I don't want my maps to include 
waterway=* & tunnel=yes, but I want to display all tunnel=yes with type 
0x*. To speed up the processing any object which is on type 0x99999 is 
dropped from further processing and not put into the map. This would 
avoid a lot of != use and could speed up mkgmap because you can quickly 
exclude objects from the database that the rules and following lines 
have to be run against.

>> Plus, it runs about 10 times slower than the trunk branch (plus continue
>>     
>
> I've not really looked at the performance yet, but there is no reason
> why it should be any slower, so I'm sure that is fixable.
>
> ..Steve
> _______________________________________________
> 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://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20090927/72471d52/attachment.html 