February 2018 - mkgmap-dev - The mkgmap lists

Commit r4129: correction: some rules with style functions were ignored
by svn commit 25 Feb '18

25 Feb '18

Version mkgmap-r4129 was committed by gerd on Sun, 25 Feb 2018 correction: some rules with style functions were ignored rules like a=* & is_closed()=true {...} were ignored because ExpressionArranger changed them to is_closed()=true & a=* {...} Style functions are not indexable and therefore must not come first. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4129

1 0

routing problems when style creates multiple routable ways for one OSM way
by Gerd Petermann 24 Feb '18

24 Feb '18

Hi all, in [1] Felix suggested to add a filter so that a style would not add too many routable ways for one OSM way. For those who are not familiar with that idea: Felix' style adds e.g. additional routable ways with other routing attributes when a way is very steep, e.g. one saying something like "nice to cycle" and the other with oneway=-1 and "not nice to cycle". The effect on NOD is that at some "RouteNodes" we find a lot more so called "RouteArcs", many of them with equal angles and lengths. Reg. the filter I see no problem to change mkgmap so that it detects the number of routable ways N which were added for one OSM way and if N > max_N (I think Felix says max_N is 4) ignore the last N - max_N ways. It might also be possible to add a style function which gives access to the number of previously added routable ways, if that is needed, but I see no need for that. I think the style rules could just add routable ways in order of importance. Right? Anyway, the question is if this will always help, as I think that the problem is probably the number of RouteArcs with equal angles in one RouteNode. Maybe we just have to make sure that we don't have exactly equal RouteArcs, maybe the overall number is the problem. The angles are stored with a rather poor resolution (max. 8 bits), but maybe we can manipulate the other attributes like length or curviness of an arc to avoid the crash. Maybe the problem is not the number of arcs in one RouteNode but the overall number of arcs that have to be checked when a route is calculated. @Felix: Maybe you have already found out more details? You wrote about "bsod", I know the meaning for Windows (Blue screen of Death), but what exactly happens with a device? Is it dangerous the play with this on my Oregon? What exactly do I have to do to to reproduce such a crash? Gerd [1] http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2018q1/028256.html

1 0

Maps aspect ratio
by Carlos Dávila 23 Feb '18

23 Feb '18

One user of my maps has commented that in my maps longitude looks much shorter than latitude. Comparing the same area in three maps (CityNavigator, OpenFiestMap and my maps) they all show different aspect ratio [1]. Do you know reason for that? Any way to control it? [1] |http://files.mkgmap.org.uk/download/423/Screenshots.zip|

2 1

Rep: DEM & Artifacts
by David 22 Feb '18

22 Feb '18

Hello Gerd, About the tile N56W008, I made a mistake. This tile is a part of my own test. I took a look on your rectangular polygon. It includes some parts of Scotland and Wales whereas with my polygon I generate shadows only for Ireland. The result is now online at : http://emerald-island.eu/wikka/GpsMap Kind regards, David

1 0

Rép :⁨ DEM test & artifacts
by David 22 Feb '18

22 Feb '18

Hello Gerd, I was not able to download your polygon file but it is not a problem. My own polygon works like a charm and it is absolutely not a rectangular shape. It is contained in the area where there is no shadow applied on water surface. Is there a difference between a tile full of nan values like N56W008 and when the tile does not exist mkgmap writes a message about using 0m for elevation by default ? Ireland -9.0 55.5 -6.0 55.5 -5.25 54.6 -5.25 54.0 -5.75 54.0 -5.75 51.5 -8.0 51.5 -8.0 51.25 -10.75 51.25 -10.75 54.6 -9.0 54.6 -9.0 55.5 END END All the best, David

2 1

bug into the style file: default\inc\compat_lines
by Ataro 22 Feb '18

22 Feb '18

the default style file:? default\inc\compat_lines have a bug into the line 124:? { setaccess=no; have to be changed as follows: { setaccess no; --- Questa e-mail ? stata controllata per individuare virus con Avast antivirus. https://www.avast.com/antivirus

4 4

Re: [mkgmap-dev] DEM test & artifacts
by David 22 Feb '18

22 Feb '18

Hello Gerd, I compiled my map without my custom dem-poly option and the result is as I tried to explained in my first message. You can see the result at : http://emerald-island.eu/wikka/ShadowArtifacts Artifacts are also still present along shorelines. But it seems to be normal : I checked SRTM1 tiles and the problem is in source data. In fact, mkgmap works nicely ! Thank you for your work and also many thanks to Andzej Popowski and Frank Stinner. David

2 1

Line TYP Collision between two different maps
by scott taggart 21 Feb '18

21 Feb '18

Hello, I am seeing a collision between custom line TYPs when I generate two different .img files (different Map IDs (--mapname= parameter to mkgmap)). Here is what I am seeing and was wondering if anyone could offer ideas: Map 1 : TYP file : Type=0x100001 (solid red), contains a single line Map 2 : TYP file : Type=0x100001 (solid green), contains a single line Both .img files get loaded into my gps (montana) and are enabled and both lines show, however, map 2's lines shows as red, not green, as expected. If I disable map 1, map 2's line still shows *incorrectly*. If I delete map 1 form the gps, then map 2's line shows correctly. I thought that each map had its own TYPs and the GPS would sort out which TYP to display for each map's line. It seems that the gps unit is getting confused or caching the line TYPs from the "first loaded" map and using those for subsequent maps. If it were true that an earlier loaded map's custom TYPs override later loaded maps, how would it be possible to sort out custom types across different maps? Another thought I had is that since both my maps share the same family id and product id, could this be causing the collision? I cannot find any decent documentation on what family id and product ID are supposed to be. Thanks for your help, Scott

4 3

Commit r4127: setaccess=no -> setaccess no
by svn commit 21 Feb '18

21 Feb '18

Version mkgmap-r4127 was committed by steve on Wed, 21 Feb 2018 setaccess=no -> setaccess no - Fix submitted by Ataro http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4127

1 0

DEM test & artifacts
by David 20 Feb '18

20 Feb '18

Hello, I tested the new DEM option with my map. It works with Basecamp. I can display shadow mountain relief and at the same time my contour lines layer and my OSM layer. Both are transparent and without background polygon. I am also able to display the profile of a route as the option showprofile is activated in my mkgmap configuration (I think it works with my contour lines as it worked before I introduced DEM). I discovered two problems with DEM rendering. For areas not covered by a SRTM tile, mkgmap produces a uniform shadowed surface (pure ocean surface) whereas for SRTM tile with both ocean and ground, there is a totally blank surface for ocean. To avoid this effect, I had to define my own polygon for Ireland (the one from geofabrik is too large : it includes a large part of ocean surface). I also reduced the size of my map by 30Mb :-) Along the coast, the DEM border is roughly cut in square shapes and it does not follow the shoreline. It is a minor problem but it look strange for coastal areas and isles. Would it be possible to automatically use the shoreline to clip nicely the DEM data ? David

2 2