- mkgmap-dev - The mkgmap lists

Commit: r3193: copy all tags with keys containing the string "name".
by svn commit 17 Apr '14

17 Apr '14

Version mkgmap-r3193 was committed by gerd on Thu, 17 Apr 2014 copy all tags with keys containing the string "name". Old code copied only "name" and keys ending with ":name", so tags like "name:en" got lost

2 1

Commit: r3192: performance improvement: use two-tier-structure in RuleIndex
by svn commit 17 Apr '14

17 Apr '14

Version mkgmap-r3192 was committed by gerd on Thu, 17 Apr 2014 performance improvement: use two-tier-structure in RuleIndex The advantages: - The lookup routine doesn't have to concatenate tag key and value to a key=value string for each tag of each element. This reduces the number of temp. StringBuilder instances drastically. - if no rule exists for the key, only one HashMap.get() is needed. - the index has a smaller memory footprint, because it keeps only references to already existing string objects Depending on the style and options, this reduces run time by up to 10% No change in output expected.

1 0

bug in SeaGenerator ?
by Gerd Petermann 16 Apr '14

16 Apr '14

Hi WanMil, please check: SeaGenerator contains to places with this loop: for(String tag : w) if(tag.equals("name") || tag.endsWith(":name")) w1.addTag(tag, w.getTag(tag)); This will not work, because tag will contain the complete tag, something like "name=XYZ" or "name:de=Rügen" Attached patch changes the code so that it works, but maybe it is better to remove the lines? I found no change in the output when using the patch. Gerd

3 2

Commit: r3191: Fix copying of island names in SeaGenerator
by svn commit 16 Apr '14

16 Apr '14

Version mkgmap-r3191 was committed by wanmil on Wed, 16 Apr 2014 Fix copying of island names in SeaGenerator The name tags of islands and land were not copied although it was intended. This happened when the SeaGenerator copied ways due to internal coastline error handling (anti-islands etc.).

1 0

SEVERE: restriction lies outside bbox
by Thorsten Kukuk 16 Apr '14

16 Apr '14

Hi, I have the following severe messag in my log files: 2014/04/15 02:27:31 SEVERE (StyledConverter): 71200209.osm.pbf: restriction http://www.openstreetmap.org/browse/relation/1713764 is ignored because referenced way http://www.openstreetmap.org/browse/way/134706782 lies outside of bbox I would like to understand what's the problem here is/how to change/fix this. Thanks, Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)

3 9

Commit: r3190: code spring clean: The static field DirectoryEntry.ENTRY_SIZE should
by svn commit 16 Apr '14

16 Apr '14

Version mkgmap-r3190 was committed by gerd on Wed, 16 Apr 2014 code spring clean: The static field DirectoryEntry.ENTRY_SIZE should be accessed directly No functional change

1 0

Unit tests for restrictions and other complex routines
by Gerd Petermann 16 Apr '14

16 Apr '14

Hi all, I think the last days showed that unit tests around routing are missing or to weak, else I should not have been able to build with so many stupid errors :-( I'd like to add some unit tests, but I have a problem: The existing input files don't contain (enough) restriction relations. I thought about two possibilities: 1) Use JOSM to create all kinds of restrictions and the special cases in an *.osm file, add it to mkgmap\test\resources\in\osm and process the file like in SimpleRouteTest to find out if the number of saved restrictions is okay. 2) Create single unit tests that produce small road networks to test edge cases like 'via' nodes on tile boundaries, 'to' ways with loops, wrong angles (right_turn describes left_turn) etc. The advantage of 1) is that it also allows to test the created img file in MapSource. The disadvantage is that it will only contain the special cases that we know now and that it is difficult to find out if every special case was treated correctly, we typically just count objects. The advantage of 2) is that we can always add new test cases and that the test is able to verify anything. The disadvantage is that it is quite difficult to create a small road network in java and that the result is not testable in MapSource. Unit tests should not be too complex, else they will make living harder when something is changed by intention. I see a similar need for other options like --process-exits, --process-destination, --make-opposite-cycleways, --adjust-turn-headings which all involve rather complex routines or are likely to have side effects on other complex routines. I think a good compromise would be a new small .osm (better .o5m or .pbf ) file containing real data with a good number of special cases and some new unit tests that use this data. I think the fie should contain a part of a (large) city with motorways, trunks etc. which is mapped by many different persons, so that we have different solutions /errors. Any suggestions? Or better ideas? Gerd

1 0

[Patch v4] route restrictions
by Gerd Petermann 15 Apr '14

15 Apr '14

Hi all, attached is version 4 of the patch. This solves the problem with spurious error messages like SEVERE (StyledConverter): pbf\europe-w\29468056.osm.pbf: restriction http://www.openstreetmap.org/browse/relation/2852823 is ignored because referenced way http://www.openstreetmap.org/browse/way/52119376 lies outside of bbox This happened when a via node lies exactly on the tile border, so that the way is truncated to a single point. This single point is not returned by the LineClipper. With version 3 I tried to change the code so that the restriction is written with two different routing nodes that have the same coordinates, but Garmin seems to be unable to understand that, so for now the restriction is not written and I've changed the message to a warning. The compiled binary is here: http://files.mkgmap.org.uk/download/203/mkgmap.jar Gerd

1 0

[Patch v2] route restrictions
by Gerd Petermann 15 Apr '14

15 Apr '14

Here is version 2 of the patch, it fixes a rare issue with via ways that are split by the LinkDestinationHook (used with option --process-destinations). For now, these ways are ignored by the hook so that the restriction works. A compiled binary is here: http://files.mkgmap.org.uk/download/200/mkgmap.jar Gerd

5 8

[patch v1] route restrictions
by Gerd Petermann 15 Apr '14

15 Apr '14

Hi all, attached is a patch that changes parts of the program logic regarding restriction relations to make it more stable and add further plausibility checks. The compiled binary is here: http://files.mkgmap.org.uk/download/198/mkgmap.jar Compared to r3189 it fixes some errors and adds new checks: 1) only these restrictions are evaluated: no_right_turn / no_left_turn / no_u_turn / no_straight_on / only_right_turn / only_left_turn / only_straight_on / no_entry / no_exit 2) to-ways that build a loop so that first and last point end at the via node are now supported if the restriction contains a direction info (left, right,...). 3) Further plausibility checks are performed to find restrictions where the angle of the from and to way don't match the direction info, for example when a no_right_turn looks more like a no_left_turn. 4) Restrictions with multiple via ways are now supported as well as via ways with additional nodes. The new limit is given by the img format: it allows to specify a "path" with up to 8 routing nodes. I've tested the patch with default style and all tiles for Germany, as well as Hennings and Minkos style. I found no more severe error message, and the remaining warnings seem to be correct. Please test this patch with your style and check the log regarding warnings for restrictions, if I hear no complains, ll commmit it on friday. Gerd

5 10