- mkgmap-dev - The mkgmap lists

Commit: r959: Make the sorting of cities repeatable.
by svn commit 01 Mar '09

01 Mar '09

Version 959 was commited by steve on 2009-03-01 22:37:37 +0000 (Sun, 01 Mar 2009) BRANCH: poi Make the sorting of cities repeatable. Previously I was getting a different order for the same input file each time I ran it. We need to investigate how names should be sorted as it depends on locale and not on character set. For example ?\195?\164 comes at the end of the alphabet in Norwegian but is sorted with a in some other languages. This code sorts cities in the same way as cgpsmapper produced maps of germany I've seen. The accented characters are sorted with the non-accented. Previously accented characters were at the end.

1 0

Display of overview map at large zoom values
by Clinton Gladstone 01 Mar '09

01 Mar '09

Hello, I have noticed that when I view a map in Mapsource, and I zoom out to a scale of 300 km or above, the entire map disappears. The problem is worse on Mac OS X using Garmin RoadTrip, as RoadTrip does not display tile boundaries. I found that adjusting the "topBits" attribute of OverviewMapDataSource.java changes this behaviour. If I set topBits = 11, the map can be displayed at scales of up to 1500 km. The comment in the code above this attribute, "// TODO need to change this.", seems to be a hint that this is not optimal. ;-) (Also, in my tests, if I lowered topBits to a value below 11, the entire map would not be displayed; with 11 the overview map is still not displayed at scale values of 2000 or 3000 km. Obviously a more comprehensive solution would be desirable.) - Is this a known issue? Is this restriction deliberate? I assume for this modification to be acceptable, the style files must be adjusted so as to not display excessive detail at these zoom levels. I have already done this in my custom style files: performance is reasonable. I am certainly not familiar with Java development in general, and definitely not with this project in particular, so I imagine that my modification will most likely not be suitable for general use. However, I have included the diff output below for your consideration anyway. Your comments would be appreciated. --- mkgmap-src/src/uk/me/parabola/mkgmap/reader/overview/ OverviewMapDataSource.java 2009-02-10 16:45:16.000000000 +0100 +++ mkgmap-trunk/src/uk/me/parabola/mkgmap/reader/overview/ OverviewMapDataSource.java 2009-02-21 18:04:15.000000000 +0100 @@ -45,7 +45,7 @@ // TODO need to change this. private final int topLevel = 5; - private final int topBits = 14; + private final int topBits = 11; /** * This is a fake source of data and is not read from a file, so always

2 1

Commit: r958: Farms and quarries
by svn commit 01 Mar '09

01 Mar '09

Version 958 was commited by steve on 2009-03-01 21:32:55 +0000 (Sun, 01 Mar 2009) Farms and quarries - Peter

1 0

Commit: r957: Ray casting code test.
by svn commit 01 Mar '09

01 Mar '09

Version 957 was commited by steve on 2009-03-01 20:51:44 +0000 (Sun, 01 Mar 2009) BRANCH: poi Ray casting code test. -Ben Konrath

1 0

OT - Access/Turn Restrictions
by Paul 01 Mar '09

01 Mar '09

I have the situation below where road C is pedestrianised except for buses between 0800 and 1800 and is accessible by everything at other times. I've currently got it covered by no_left_turn restrictions from A or E to C and no_straight_on from B or D to C but this doesn't fully describe the restrictions (these have hour_on/off parameters). My question is how would I fully describe this situation with turn or access restrictions? |A | | B------@-------C---------@---D--- | |E Cheers Paul

4 5

[PATCH] if no areaName given, take the map name instead of 'area name'
by Johann Gail 01 Mar '09

01 Mar '09

I just had some problems to distinguish different tiles on my etrex on card settings menu. So I changed the default area name to the mapnumber instead of 'area name'.

1 0

[PATCH] Access destination tag
by Bernhard Heibler 01 Mar '09

01 Mar '09

Hi, my garmin routed me again through a residential area on a road that is tagged as destination only. I think the "destination" check was lost during the last rework of the access code. Has anybody played with the RoadNetwork.DELIVERY field until know ? To me it looks like this might solve the problem. If the access is totally blocked to a area the routing gets very strange. If I want to go into this area I get routed via a unpaved road which is also blocked. If I set the RoadNetwork.DELIVERY field the routing gets more useful. My patch is attached ... Thanks Berni. Index: src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java =================================================================== --- src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java (revision 284) +++ src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java (working copy) @@ -502,6 +502,12 @@ noAccess[accessSelector[i]] = true; } log.info(vehicleClass[i] + " is not allowed in " + highwayType + " " + way.getName()); + + if(deliveryAllowed(access)) + { + log.info(vehicleClass[i] + " delivery allowed " + highwayType + " " + way.getName()); + noAccess[RoadNetwork.DELIVERY] = true; + } } else if(accessExplicitlyAllowed(access)) { if(accessSelector[i] == RoadNetwork.NO_MAX) { @@ -800,4 +806,11 @@ val.equalsIgnoreCase("private") || val.equalsIgnoreCase("destination")); } + + public boolean deliveryAllowed(String val) { + if (val == null) + return false; + + return (val.equalsIgnoreCase("destination")); + } }

4 5

Commit: r956: Improve a few help options.
by svn commit 01 Mar '09

01 Mar '09

Version 956 was commited by steve on 2009-03-01 18:34:03 +0000 (Sun, 01 Mar 2009) Improve a few help options. - Ben Konrath

1 0

Preservation of order not working
by Nop 01 Mar '09

01 Mar '09

Hello! My application makes heavy use of a layering concept that puts items in a particular order so they are drawn on top of each other on the garmin. This is used to draw bridges/tunnels in the proper order and to construct composite elements by overlaying multiple lines or icons in a particular order. Versions of mkgamp up to 590 did maintain the order of elements, in later versions the order was random due to use of a hash map, then maintaining the order was restored - theoretically. I now tried to migrate my application to work with current versions of mkgmap, but the drawing order still does not correspond to the order in the input osm file. In the particular use case I attempt to create markings for hiking trails by drawing a symbol (e.g. yellow cross) on top of a background (white rectangle). I double-checked the OSM input file, all the background nodes are in the file before any of the symbol nodes. In the output, the symbols are drawn correctly on top or hidden behind the white rectangles at random. The effect is the same in MapSource and on the device. The same symbol/background combinations are sometimes drawn properly and sometimes in reverse order. I have attached two images showing the good and broken case on two neighboring nodes. From the tooltips in Mapsource you can see the inverted order of foreground and background in the broken case. I have checked this with mkgmap r858 and r935, both with identical results. The last version this works completely is r590. Ways seem to be ok, at least I could see no problems there during my first tests. Is it possible that the fix only applies to ways but not tod nodes? bye Nop

4 12

Commit: r955: Remove duplicated files.
by svn commit 01 Mar '09

01 Mar '09

Version 955 was commited by steve on 2009-03-01 16:52:48 +0000 (Sun, 01 Mar 2009) BRANCH: poi Remove duplicated files.

1 0