Hi Felix
Still I don't see an advantage over creating a testfile for OSM, which has the additional advantage to see how Mapsource behaves (use 6.15.7 or 6.13.6, most other Mapsource versions are largely inferior). For crosschecking that it is not Mapsource that hides something, either use Qlandkarte GT, or use gpsmapedit (freeware version is enough).
Its not meant for testing if the style will work in mapsource, all it is meant to do is to shows you what the result of applying a style to a way with a given set of tags, and what the result should be.
What would be much more interesting as it takes up time to find out, is to see a list of results showing WHY a rule was not enacted and a line got dropped due to another rule matching. (which action rule is matching
Yes, it might be possible to show which rules are being matched in which order. On the trunk though the reason why things don't work is usually just random. To show just how unpredictable trunk is, here is a set of rules that work as I would expect: WAY 1 highway=primary aa=good <<<lines>>> highway=* & aa=good {set aa=6} highway=primary & aa=6 [0x1] highway=* & aa=6 [0x2] <<<results>>> WAY 1: Line 0x1, name=<null>, ref=<null>, res=24-24 (1/1),(2/2), Now here are the exact same rules except that I am using ag instead of aa. WAY 1 highway=primary ag=good <<<lines>>> highway=* & ag=good {set ag=6} highway=primary & ag=6 [0x1] highway=* & ag=6 [0x2] <<<results>>> WAY 1: Line 0x2, name=<null>, ref=<null>, res=24-24 (1/1),(2/2), FAIL. If rules were run strictly in order this would be: Line 0x1, name=<null>, ref=<null>, res=24-24 (1/1),(2/2), Now it doesn't work! And all I did was use a different name! This sort of nonsense will not happen when the strict order style branch is merged. No one should have to spend hours working out why the first one works and the second one doesn't because there is no good reason. [1] ..Steve [1] If anyone is interested the difference is down to the order in which the tags get saved in a hash map.