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
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
