March 2009 - mkgmap-dev - The mkgmap lists

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

Commit: r954: Merged from trunk.
by svn commit 01 Mar '09

01 Mar '09

Version 954 was commited by steve on 2009-03-01 16:30:45 +0000 (Sun, 01 Mar 2009) BRANCH: poi Merged from trunk. Test values changed to match different lable section size. Please test this well.

2 1

Commit: r953: Create POIs inside areas if they do not already have one.
by svn commit 01 Mar '09

01 Mar '09

Version 953 was commited by steve on 2009-03-01 00:18:42 +0000 (Sun, 01 Mar 2009) BRANCH: poi Create POIs inside areas if they do not already have one. Bernhard Heibler: I have integrated Ben Konrath's Area POI patch into my code. I did the following changes to Ben's code: - Replaced the hard coded area to poi type mapping with the build in rule sets. Shapes are checked against the point rules to add missing pois. - Replaced the linear search (to avoid duplicated pois) with tile based search - Add buildings to polygons style - Moved my helper classes to general directory You have to add the --add-pois-to-areas to enable the Area POIs generation. I'm not sure if we should generate a new rule set in the style folder for this purpose. It works pretty good using the point rules but it might be confusing. - Original patch by Ben Konrath, itegrated by Bernhard Heibler

3 2