- mkgmap-dev - The mkgmap lists

Commit r3833: remove useless code
by svn commit 07 Mar '17

07 Mar '17

Version mkgmap-r3833 was committed by gerd on Tue, 07 Mar 2017 remove useless code No need to store isIso flag because input data is filtered to make sure that ISO name is found. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3833

1 0

Commit r3832: residential-hook-v1.patch: set mkgmap:residential tag for elements which are in a landuse=residential area.
by svn commit 07 Mar '17

07 Mar '17

Version mkgmap-r3832 was committed by gerd on Tue, 07 Mar 2017 residential-hook-v1.patch: set mkgmap:residential tag for elements which are in a landuse=residential area. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3832

1 0

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 r3831: Correct Tags iterators
by svn commit 03 Mar '17

03 Mar '17

Version mkgmap-r3831 was committed by gerd on Fri, 03 Mar 2017 Correct Tags iterators The next() method did not return the correct value if not preceeded by a hasNext() call. This caused no problems in existing code. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3831

1 0

Buildings in residential areas (is_in_filter)
by Gerd Petermann 02 Mar '17

02 Mar '17

Hi all, picking up this thread: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2017q1/026079.html I've now done some experiments with this approach: - Collect all shapes after style processing - Collect those shapes added to the map with tag landuse=residential and build a fake BoundaryQuadTree by adding those ways as admin_level=10 boundary. - For each shape (or each with type 0x13) check if the BoundaryQuadTree returns a "location" with admin_level=10. If so, the shape is considered to lie inside a residential area and may be removed. The performance is no problem, these computations are performed in < 1s and the removal safes time later. I've tried with the default style with a map for Niedersachsen and got a size reduction of 154MB -> 133MB (I guess we have add some more MB when we draw the residential areas at res 24 instead). So, what we need now is a useful user interface for this function. Possible: - a new special tag mkgmap:remove-if-in-residential=true which tells mkgmap the objects to remove (do we need that for POI or lines as well? ) - a new special tag mkgmap:treat-as-residential=true for to tell mkgmap that a shape with that tag should be considered as a residential area , maybe not needed since you might add landuse=residential as well. I don't think that this simple function can be used to solve the routing problems, this would require a lot more logic. What do you think? Gerd

2 2

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