On Sat, 2010-12-04 at 12:37 +0200, Marko Mäkelä wrote: <snip>
As Charlie Ferrero suggested, it should get the value from the name of the boundary relation. The question is if relations ignore the name-tag-list option.
# Names of administrative boundaries. # We could want to sort the relations in ascending order of admin_level # and alphabetically by name first. # Currently, the matching relations will be processed and the names # appended to the boundary lines in an arbitrary order. (type=boundary | type=multipolygon) & boundary=administrative & name=* { apply { set mkgmap:boundary_name='$(mkgmap:boundary_name)/${name}' | '${name}'; } }
As a workaround for the possible --name-tag-list bug, you could try replacing ${name} in the above rule with ${name:en}. If it does not help, check that relations actually carry a name:en.
Ideas for tweaking the style language so that the resulting name list will be sorted are welcome.
Best regards,
Marko
The relations are tagged consistently in my case (better than the tag in the ways), so your idea of using ${name:en} in the relations rule works perfectly. Thanks for your help. And it does look like there is a bug in handling the --name-tag-list. Apologies to those who group messages by thread in their email program, I just realized that I inserted my first post into an existing thread by mistake. Garvan