February 2017 - mkgmap-dev - The mkgmap lists

POI indexing, problem with label 0x2800
by Andrzej Popowski 02 May '17

02 May '17

Hi, POI types 0x28xx are usually treated as labels, there is no icon for these POIs, only label text. CGPSMapper doc describe these POI as "Region name". I'd like to use these POI for house numbers. Problem is, that mkgmap indexes labels! It results in big increment of img files and index file. I doubt these objects are searchable, probably all this indexing is only a waste of space. I have found code in MdrUtils.java, which adds labels to index. I think this can be removed. And maybe you can add POIs in range 0x64xx - 0x66xx, they probably are searchable. There is an increase in LBL subfile, I haven't found code responsible for this. There seems to be a section LBL5 called "POI index", maybe labels goes there too? -- Best regards, Andrzej

5 15

max-nodes in splitter
by Jakob Mühldorfer 01 Apr '17

01 Apr '17

Hi, I tried to read all the docs and forums about max-nodes, but I still have questions left: * Does the splitter print an error when max-nodes is too large, or is it unpredictable and will it only fail on the GPS device * Do tiles with more nodes mean higher or lower draw performance on devices, or not matter at all Thank you for your help Jakob

5 19

[Patch v1] differet Coord implementation
by Gerd Petermann 14 Mar '17

14 Mar '17

Hi programmers, After writing my findings here http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2017q1/026317.html I did some cycling and decided that I might still be better to use the attached patch. It works better with 32 bits and is probably a bit easier to understand. The major difference is that it calculates the Garmin position of a point from the already rounded 30 (or 32 bit) value. In some cases this means that points in the map move by one, e.g. one with 52.2452629, 21.0833536 appears on the right grid point instead of the left (it is very close to the middle). Gerd

3 3

roundabouts
by Gerd Petermann 06 Mar '17

06 Mar '17

Hi all, the default style contains these rules for roundabouts: # Roundabouts junction=roundabout & (highway=trunk | highway=trunk_link) [0x0c road_class=3 road_speed=2 resolution 18] junction=roundabout & (highway=primary | highway=primary_link) [0x0c road_class=3 road_speed=2 resolution 19] junction=roundabout & (highway=secondary | highway=secondary_link) [0x0c road_class=2 road_speed=2 resolution 20] junction=roundabout & (highway=tertiary | highway=tertiary_link) [0x0c road_class=1 road_speed=1 resolution 21] junction=roundabout & highway=unclassified [0x0c road_class=1 road_speed=1 resolution 21] junction=roundabout & highway=* [0x0c road_class=0 road_speed=1 resolution 22] The wanted effect is that the Garmin device/software produces hints like "enter roundabout" or "Take the 2nd right onto" ... The disadvantage is that the roundabout is not rendered. I replaced all the above rules by junction=roundabout & highway=* [0x0c road_class=0 road_speed=0 resolution 24 continue] I tried this with car + bicycle routing and it seems to give the expected results (routing hints and rendered roads). Also the --check-roundabouts option doesn't complain. Alternative might be to keep the distinction of road types for better time estimation, important point is that "resoltion 24 continue " is used. Comments? Gerd

7 23

Re: [mkgmap-dev] unpaved roads
by Gerd Petermann 05 Mar '17

05 Mar '17

Hi Greg, as you said we have to live with the limitations of the Garmin img format and the routing algo. My understanding is that the default style should produce reasonable results for correct input data. If I got you right you'd like to have some user interface (maybe sliders in a GUI) to express your preferences of different road types or surface types and that should be used to "fine tune" the values for road_speed, road_class, and the unpaved flag so that one doesn't have to understand all the complex rules? Gerd ________________________________________ Von: Greg Troxel <gdt(a)lexort.com> Gesendet: Mittwoch, 22. Februar 2017 15:42 An: Gerd Petermann Cc: Greg Troxel Betreff: Re: AW: [mkgmap-dev] unpaved roads [you didn't copy the list. if you want me to post this I'm happy to.] Gerd Petermann <GPetermann_muenchen(a)hotmail.com> writes: > okay, a bit late. understood. I didn't mean to complain, just to offer a perspective that I thought might be helpful. > The default style was already changed to set the unpaved flag in the > same way as the surface wiki suggests. Arguably that is the most reasonable default. > I agree that this is just one of many ways to use the flag, but I have > no idea what you try to describe with the part following "try to map > some utility function ..." . What I meant is that a routing user will have an opinion about the usefulness/goodness of any route based on many things. Right now there is a strong bias towards "shortest distance" and "fastest time" in the routing world and "least fuel" is starting to show up. I probably should not have said "utility function". That's a concept from economics which assigns a numerical value to a situation, and there's an assumption that a rational actor seeks to maximize utility. https://en.wikipedia.org/wiki/Utility This concept acknowledges lots of complexity. A car that works but is not fancy might be worth 100 points and one that is just as useful but looks nicer 120, to one person. Or 200 to someone who sees it as jewelry/status, or 90 to someone who finds the niceness pointless and then worries about damage. What I was getting at is that for a route, one can think of each segment as having a cost (which is sort of inverse utility), where the cost is about how the route user feels about it. Here, the cost function encodes how one feels about surface types, speeds, distance, congestion, traffic lights, left turns, etc. Then, I was suggesting that optimal routing takes the OSM data and compute a route with min user-cost according to the user's cost function. In OSMand you can sort of do this, because most of the OSM data is or can be on the phone. In Garmin, you can't, because we have to use the Garmin intermediate representation and because we have to use the Garmin routing engine. So, one could think about defining these user-cost functions, and then trying to have a transformation of OSM data to Garmin data such that the shortest time computation on the Garmin leads to a route that has minimal user-cost. > Do you suggest a new mkgmap option which overrides or influences the > results of the style? Can you give an example that shows the > advantage compared to a "private" style ? I think I'm really suggesting private styles, in some sense, but perhaps something more than that, which is a language to express these user cost functions and have that change the style. This is arguably way too complicated. Certainly it's premature until there is a style that does something that people find more useful than the default. What I was really trying to do was to express the notion that correctly encoding paved should not necessarily be the goal, but instead to allow most people to be able to create good routes. All that said, I find that around me, most connecting roads are paved and it doesn't matter much. In Upstate NY, there are connecting roads that are unpaved. But there, you really want to ask the question "would I rather drive 10 miles unpaved or 50 miles paved" rather than just "avoid". This reminds me that max_speed isn't really the right thing either, but OSM doesn't yet have a culture of "typical_speed". To me, routing is all about "on this route, what will my total experience be, and will I prefer it to this other route's experience". And that's very hard. So thanks for listening, and hope it was worth your time!

2 1

Commit r3826: revert accidential change in build.xml
by svn commit 28 Feb '17

28 Feb '17

Version mkgmap-r3826 was committed by gerd on Tue, 28 Feb 2017 revert accidential change in build.xml http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3826

1 0

Commit r3825: revert accidently committed debug code in unit test
by svn commit 28 Feb '17

28 Feb '17

Version mkgmap-r3825 was committed by gerd on Tue, 28 Feb 2017 revert accidently committed debug code in unit test http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3825

1 0

Commit r3824: add empty style and use it when reading the precomp-sea data
by svn commit 28 Feb '17

28 Feb '17

Version mkgmap-r3824 was committed by gerd on Tue, 28 Feb 2017 add empty style and use it when reading the precomp-sea data The method SeaGenerator.loadPrecompTile() uses the complex class OsmMapDataSource to read the content of the precomp sea data. This reading needs no style rules but OsmMapDataSource loads the default style for each precomp-sea tile if no style option is given. Using an empty style improves run time a bit. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3824

1 0

if-then in style
by Gerd Petermann 27 Feb '17

27 Feb '17

Hi all, I try to make up my mind about what is needed and what is not. 1) I did not yet find a good reason to have an else clause, so I think we should start without implementing it unless one can give a good example. 2) The banch now implements the syntax if (EXPR) then ... end by adding the expression EXPR to each of the rules between 'then' and 'end' . Nested if-then are allowed. This might cause confusion in the following case: if (highway=proposed) proposed=footway {delete highway} surface=asphalt {echotags "test" } [... ] end What should happen for a way with highway=proposed, proposed=footway, surface=asphalt ? I'd expect that the 2nd rule with echotags is triggered, but it is not because after the interpretation of the if-then clause the rules look like this: proposed=footway & highway=proposed {delete highway} surface=asphalt & highway=proposed {echotags "test" } [... ] and since the first rule deletes the highway tag the 2nd isn't triggered. My suggested interpretation was like this: highway=proposed {set mkgmap:if:1000=true} proposed=footway & mkgmap:if:1000=true {delete highway} surface=asphalt & mkgmap:if:1000=true {echotags "test" } [... ] And I think that we should make sure that those generated special tags like mkgmap:if:1000 are not used directly by the style author . Another option might be to disallow the modification of any tag which appears in EXPR. No idea if that would be easier to implement but I fear that it would lead to very confusing error messages. Comments? ciao, Gerd

2 2

Commit r3822: Correct style evaluation index
by svn commit 27 Feb '17

27 Feb '17

Version mkgmap-r3822 was committed by gerd on Mon, 27 Feb 2017 Correct style evaluation index In special cases matching rules were not evaluated, e.g. for the following three rules boundary=administrative { set mkgmap:if:0001=1 } admin_level<3 & mkgmap:if:0001=1 [0x1e resolution 12] mkgmap:if:0001!=1 & admin_level<3 [0x1f resolution 14] a way with the tags boundary=xyz and admin_level=2 should trigger the last rule, but it did not. The problem was in the evaluation of so-called changable tags (mkgmap:if:0001 in this case). The effect of this correction is that the index returns more rules for evaluation and probably a small increase in the run time. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3822

1 0