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

Tue Sep 29 17:51:36 BST 2009


Torsten Leistikow wrote:
> Moin,
>
> I am not sure, I understand plans completely.
>
> Felix Hartmann schrieb:
>   
>> 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).
>>     
>
> So in this case, you only want to have the first of your action rules
> beeing carried out, the next two action rules shall be left out, and
> than the conversion shall contiue with last rule and carrie on with all
> following rules?
>   
No, not the first. I want that it stops after the first matching. So if 
the first matches, 2 and 3 are dropped. if 2 matches 3 is dropped.
> I do not see any usefull syntax right now, to enable such complex
> style-rules control. But I think you can reach your goal quite easily,
> when you introduce some auxilliary flags:
>
> mkgmap_mtbrt_name_fixed!=yes & mtb:scale=0  & mtb:scale:uphill=0 &
> route=mtb { name 'mtbrt00 ${name}' | 'mtbrt00' ;
> mkgmap_mtbrt_name_fixed=yes } continue
>
> mkgmap_mtbrt_name_fixed!=yes &  mtb:scale:uphill=0 & route=mtb { name
> 'mtbrt.0 ${name}' | 'mtbrt.0' ; mkgmap_mtbrt_name_fixed=yes } continue
>
> mkgmap_mtbrt_name_fixed!=yes &  mtb:scale=0 & route=mtb { name 'mtbrt0.
> ${name}' | 'mtbrt0.' ; mkgmap_mtbrt_name_fixed=yes } continue
>   
okay, I see that point. makes it a bit more complicated.
>
>   
>> *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.
>>     
>
> I think the 0x999999 is quite a bad hack. But some kind of stop command
> might be really usefull, not only for performance gains but also for
> making the style files less complicated.
>   
I did not mean to actually put 0x999999 into the final map. I just used 
it because 0x999999 can never exist. Of course stop as command would 
work too.
> But what about a style rule without the continue? Wouldn't this stop the
> processing. I haven't look at the latest work from Steve yet, but in
> your above eyample, you use the continue statement on rules with an
> action part only. If you insert a rule like:
> waterway=* & tunnel=yes {set ignored=yes}
> without any continue, shouldn't this stop the processing of the item?
>   
Currently the continue as Steve implemented it does not work at all for 
action rules - they don't seem to have an effect. But yes to answer the 
question, a stop command should stop the processing of the item. So stop 
and continue together are impossible. Without stop command or 
ignored=yes in a simple action rule, they will be taken into account in 
0x* rules - that is what I don't want.
> Gruss
> Torsten
>   
Hope to have made clear what I think would be important. Actually the 
strict order is the least important for me.
> _______________________________________________
> 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/20090929/257008f3/attachment.html