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