Hi I have written a utility that can be used for demonstrating style bugs and requests. See the attached patch. It allows you to create a file containing ways with tags and a set of style rules. You can then run this file and see what elements would be produced. If this is wrong or you disagree with the results you can post the whole result along with what you wanted to happen. It also attempts to calculate what would happen if the rules were run in order from the top to the bottom on the way. If the result is different, then this is printed out as a failure after the actual results. Anything that depends on the order that actions are executed in is likely to fail on trunk, so any such example will just be collected and used to ensure that the style branch is working OK. Anyway, here is an example of it in use. Create a file called example1 with the following contents. WAY 1 highway=primary type=good aa=5 name=Main Street <<<lines>>> highway=* & type=good & aa=5 {set aa=6; } highway=primary & aa=6 [0x26 ] highway=* & aa=6 [0x27 ] Then run as (with the correct location of mkgmap.jar if different): java -cp dist/mkgmap.jar uk.me.parabola.mkgmap.main.StyleTester example1 This will print out the input file followed by a results section: <<<results>>> WAY 1: Line 0x27, name=<Main Street>, ref=<null>, res=24-24 (1/1),(2/2), FAIL. If rules were run strictly in order this would be: Line 0x26, name=<Main Street>, ref=<null>, res=24-24 (1/1),(2/2), This shows that the trunk code will select the last rule, but it should have selected the previous one. More notes * If more than one element is produced, as a result of using continue say, then they are all printed. * Ways are created with two points (1,1) and (2,2) so you can see reversals * You can have any number of WAY definitions, each of which must be ended with a blank line * You can put a number after the WAY so that you can tell them apart in the results. ..Steve
More notes
* If more than one element is produced, as a result of using continue say, then they are all printed. Okay up to here there is no advantage at all, over creating a test.osm file inside JOSM, or I failed to understand something. Indeed any action that is depending on continue is more likely to fail, as and even more are any actions involving !=* * Ways are created with two points (1,1) and (2,2) so you can see reversals I don't really understand what is ment here. In an ideal world we would have three results. 1. oneway!=*; 2. oneway=yes; 3. oneway=-1 * You can have any number of WAY definitions, each of which must be ended with a blank line * You can put a number after the WAY so that you can tell them apart in the results.
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). 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 in trunk is easy anyhow. The one where more tags match). BTW I think that you were partly right about me running into problems that are bugs in mkgmap with the undone changes (the crazy behaviour of needing to introduce "highway=* &" was a bug that got introduced and now luckily is working better again, though it is still strange of why "highway=* & " prefixing causes so big discrepancies). The thing is, that with those undone changes there was NO possibility to write your style so that it does work (because !=* is not working correctly). So before any such changes are done again, the handling of !=* has to be 100% correct, even if there are 100 different !=* to check against (because exactly this situation will come up if continue works endlessy) - this will however drop speed by easily 100%, and increase memory consumption tremendously. Maybe it would be better to introduce a continue1, which will match a second time the same key on the same line (and a continue2, continue3...). Also behaviour of when oneway=-1/oneway=reverse streets are turned around has to be clear (best by making it part of the style-file). Otherwise no rule can match/work with oneway key. A
..Steve
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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.
* Ways are created with two points (1,1) and (2,2) so you can see reversals I don't really understand what is ment here. In an ideal world we would have three results. 1. oneway!=*; 2. oneway=yes; 3. oneway=-1
WAY 1 highway=primary oneway=reverse WAY 2 highway=primary <<<lines>>> highway=primary [0x01 road_class=1] <<<results>>> WAY 1: Road 0x1, name=<null>, ref=<null>, res=24-24 oneway (2/2),(1/1), road class=1 speed=0 WAY 2: Road 0x1, name=<null>, ref=<null>, res=24-24 (1/1),(2/2), road class=1 speed=0 You can see that WAY1 has been reversed (and marked as oneway) whereas WAY2 is in its original direction. The correct behaviour. ..Steve
Maybe it would be better to introduce a continue1, which will match a second time the same key on the same line (and a continue2, continue3...). Also behaviour of when oneway=-1/oneway=reverse streets are turned around has to be clear (best by making it part of the style-file). Otherwise no rule can match/work with oneway key.
I would also like to see all the oneway and access tags made part of the style file. I think that these flags should be settable in the type. Eg. [0x01 ... oneway=yes ...] ..Steve
Moin Steve, Steve Ratcliffe schrieb am 24.01.2010 13:39:
I have written a utility that can be used for demonstrating style bugs and requests. See the attached patch.
I am not sure, whether your utility is reasonable, but I would like to give it a try. Unfortunately right now I don't have a build environment for mkgmap, so please can you provide also a ready to use version of your tool. (Or if this was already done with your patch, then i need a fool proof discription, how to apply your patch.) Gruss Torsten
participants (3)
-
Felix Hartmann -
Steve Ratcliffe -
Torsten Leistikow