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
[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