January 2013 - mkgmap-dev - The mkgmap lists

Commit: r2443: Change mkgmap default map license text to ODbL
by svn commit 12 Apr '13

12 Apr '13

Version 2443 was committed by wanmil on Thu, 10 Jan 2013 Change mkgmap default map license text to ODbL

4 3

locator rules and transparent maps
by Thorsten Kukuk 01 Apr '13

01 Apr '13

Hi, I tried to create a transparent map (an additinal layer on top of my basemap) containing address informations, but this does not seem to work. If I include the locator rules (means only create mkgmap:* variables), the maps are no longer transparent, independent of what I use for options. If I remove all mkgmap:* assignements, the map is transparent again. Any idea about this? Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)

4 5

Address include in polygons style file superfluous?
by WanMil 12 Mar '13

12 Mar '13

Hi, I have started writing some pages for the new mkgmap documentation about address search. This made me thinking if the address include is required for the polygons style file. Is it possible to see the address information of a polygon in a Garmin map (or better a mkgmap created map)? If the answer is no we could remove the include from the polygons style file which saves some memory and some processing steps. Additionally we could remove the processing of polygons from the LocationHook. The only thing that need to be changed is the -add-pois-to-areas option. The POIs created by this option must be worked out by the LocationHook because the polygons do not contain the address info any more. But I think this would be easy. Any comments? WanMil

4 5

Polygons deformed
by --enrico 05 Mar '13

05 Mar '13

Hi, I see that the polygons are deformed in MapSource compared to the online openstreetmap view. When I draw a polygon, I make perfect line and angles but when I see it compiled in MapSource it is not the same form. I don’t understand why. Thanks

7 14

Re: [mkgmap-dev] Regression: Revision 2448 breaking routing in some cases
by Felix Hartmann 04 Feb '13

04 Feb '13

Oh okay, well then let's put this on the list. I know the remove-short-arcs function is not touching it, but it's 2448 that breaks it. There must be something else touched on the routing side of it. And I would say it's very likely not only happening here, but probably happening in quite a few cases - it just popped up there. On 30.01.2013 22:19, Gerd Petermann wrote: > Hi Felix, > > sorry, I have no idea what goes wrong. With r2466, the > remove-short-arcs function doesn't touch the way 38693214 or 83196110. > I think this is something Steve must look at. > > Gerd > P.S. I don't know why my answer to your first mail did not go to the > list. This was not intended. > > > ------------------------------------------------------------------------ > Date: Wed, 30 Jan 2013 17:47:44 +0100 > From: extremecarver(a)gmail.com > To: gpetermann_muenchen(a)hotmail.com > Subject: Re: [mkgmap-dev] Regression: Revision 2448 breaking routing > in some cases > > okay great, well I think there is some routing information missing on > the road. Just see what happens when you try to click on it for a > route with Basecamp or Mapsource - it puts the routing node somewhere > completly else (a little bit, like what happens with merge-lines, just > much further away). > On 30.01.2013 17:39, Gerd Petermann wrote: > > Hi Felix, > > okay, I see if I can find anything special in this file. We > already know that the algorithm is not 100 % correct, and I hope > Steve will find a better solution,but > maybe I can improve the existing algo first. > > Gerd > > ------------------------------------------------------------------------ > Date: Wed, 30 Jan 2013 17:22:30 +0100 > From: extremecarver(a)gmail.com <mailto:extremecarver@gmail.com> > To: gpetermann_muenchen(a)hotmail.com > <mailto:gpetermann_muenchen@hotmail.com> > Subject: Re: [mkgmap-dev] Regression: Revision 2448 breaking > routing in some cases > > > On 30.01.2013 16:23, Gerd Petermann wrote: > > Hi Felix, > > I want to find the special case in this. Please provide the > osm data (66570017.osm.pbf ) > > it's here now: http://openmtbmap.org/65250017.osm.pbf > > Are you able to reproduce the problem with the default style? > > No, I'm really lost on the style issue. I can cut down the style > quite far, and it's still broken. But even if I change routable > lines, that are created after the breaking road (further down in > the lines file), it can suddenly work again. > On the other hand, there seems to be nothing special about the osm > data there at all. > > > Gerd > > > Date: Wed, 30 Jan 2013 11:46:24 +0100 > > From: extremecarver(a)gmail.com <mailto:extremecarver@gmail.com> > > To: mkgmap-dev(a)lists.mkgmap.org.uk > <mailto:mkgmap-dev@lists.mkgmap.org.uk> > > Subject: [mkgmap-dev] Regression: Revision 2448 breaking > routing in some cases > > > > Well, I got notified that there is a routing problem in one > of my maps, > > and after trying around a long time, I tracked it down to > release 2448 > > that breaks routing under certain occasions. Here is a > screenshot of the > > the routing failing: > > > > http://openmtbmap.org/broken_routing.jpg > > > > So for a very short distance, the routing will actually > route over the > > broken road (the section where the route is missing). > > However for longer sections on that road, or route that > actually has a > > routepoint manually set on it, Mapsource/Basecamp/GPS will > fail to > > calculate a route at all. (e.g. if you try to route from the > North point > > of the route in the picture, South to the Bergkirchen place > POI/node). > > > > > > It is dependant on the the style - but I played with > deleting lots of > > stuff from the style, and it seems to be quite random. > > So here are the downloads (all .exe are lzma packed, just > unpack them if > > not on windows): > > > > http://openmtbmap.org/velonordrhein-westfalen_working_2447.exe > > http://openmtbmap.org/velonordrhein-westfalen_broken_2448.exe > > > > Search for Bergkirchen, it is in the tile 66570017 > > > > > > Maps are compiled with: > > c:\OpenMTBMap\maps>start /low /b /wait java -jar -Xms4000M > -Xmx10400M > > c:\openmtbmap\mkgmap.jar --max-jobs=8 --generate-sea --latin1 > > --precomp-sea=c:\openmtbmap\maps\sea > > "--style-file=c:\openmtbmap\velomap_style" --nsis --index > --transparent > > --adjust-turn-headings --add-pois-to-areas --ignore-maxspeeds > > --reduce-point-density=3 --x-reduce-point-density-polygon=6 > > --link-pois-to-ways --ignore-turn-restrictions > --remove-short-arcs=5.4 > > --min-size-polygon=18 --description=velomap_dnw > --show-profiles=1 > > --location-autofill=bounds,is_in,nearest > > --bounds=c:\openmtbmap\maps\bounds --route --country-abbr=dnw > > --country-name=nordrhein-westfalen --mapname=66570000 > --family-id=6657 > > --product-id=1 > --series-name=velomap_nordrhein-westfalen_30.01.2013 > > --family-name=velomap_dnw_30.01.2013 --tdbfile > > --overview-mapname=mapsetc --keep-going > > --area-name="nordrhein-westfalen_30.01.2013_velomap.org" -c > > c:\openmtbmap\maps\template.nordrhein-westfalen 7*.img 1>NUL > > > > --remove-short-arcs == resulting road will be broken > > --remove-short-arcs=5.4 == resulting road will be broken > > without remove-short-arcs == resulting road will be broken > > > > So it doesn't directly have to do with the > --remove-short-arcs function. > > > > > > (also Compiled with --remove-short-arcs=5.4 ) > > http://openmtbmap.org/velonordrhein-westfalen_broken_2466.exe > > > > then Uncommented the following lines in my style-file, which > shouldn't > > affect routing at all, but it does as the mistake is gone: > > # power=line [0x29 resolution 22 continue] > > # power=minor_line | powerline=yes | power_line=yes | > powerline=true | > > power_line=true [0x29 resolution 24 continue] > > http://openmtbmap.org/velonordrhein-westfalen_nopower_2466.exe > > > > However I can also leave that line in the style-file, and > delete some > > other lines, and routing will work again. There seems to be > no clear > > pattern (except that the bug go introduced with rev 2448). I > use the > > same line in my openmtbmap, and there the routing error > doesn't happen. > > > > > > -- > > keep on biking and discovering new trails > > > > Felix > > openmtbmap.org & www.velomap.org <http://www.velomap.org> > > > > _______________________________________________ > > mkgmap-dev mailing list > > mkgmap-dev(a)lists.mkgmap.org.uk > <mailto:mkgmap-dev@lists.mkgmap.org.uk> > > http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > -- > keep on biking and discovering new trails > > Felix > openmtbmap.org &www.velomap.org <http://www.velomap.org> > > > -- > keep on biking and discovering new trails > > Felix > openmtbmap.org &www.velomap.org <http://www.velomap.org> -- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org

4 10

Commit: r2472: Enable coastline drawing when using precompiled sea
by svn commit 31 Jan '13

31 Jan '13

Version 2472 was committed by wanmil on Thu, 31 Jan 2013 Enable coastline drawing when using precompiled sea The coastline ways are not contained in the precompiled sea. But they can be taken from the OSM input tiles. So when the --precomp-sea option is set all costline ways are copied and additionally marked to be used only with the lines style file. This let the coastline reappear with precomp-sea.

1 0

Commit: r2470: Merge the 'functions' branch.
by svn commit 30 Jan '13

30 Jan '13

Version 2470 was committed by steve on Wed, 30 Jan 2013 Merge the 'functions' branch. It integrates the style functions more deeply into the style system code.

1 0

Regression: Revision 2448 breaking routing in some cases
by Felix Hartmann 30 Jan '13

30 Jan '13

Well, I got notified that there is a routing problem in one of my maps, and after trying around a long time, I tracked it down to release 2448 that breaks routing under certain occasions. Here is a screenshot of the the routing failing: http://openmtbmap.org/broken_routing.jpg So for a very short distance, the routing will actually route over the broken road (the section where the route is missing). However for longer sections on that road, or route that actually has a routepoint manually set on it, Mapsource/Basecamp/GPS will fail to calculate a route at all. (e.g. if you try to route from the North point of the route in the picture, South to the Bergkirchen place POI/node). It is dependant on the the style - but I played with deleting lots of stuff from the style, and it seems to be quite random. So here are the downloads (all .exe are lzma packed, just unpack them if not on windows): http://openmtbmap.org/velonordrhein-westfalen_working_2447.exe http://openmtbmap.org/velonordrhein-westfalen_broken_2448.exe Search for Bergkirchen, it is in the tile 66570017 Maps are compiled with: c:\OpenMTBMap\maps>start /low /b /wait java -jar -Xms4000M -Xmx10400M c:\openmtbmap\mkgmap.jar --max-jobs=8 --generate-sea --latin1 --precomp-sea=c:\openmtbmap\maps\sea "--style-file=c:\openmtbmap\velomap_style" --nsis --index --transparent --adjust-turn-headings --add-pois-to-areas --ignore-maxspeeds --reduce-point-density=3 --x-reduce-point-density-polygon=6 --link-pois-to-ways --ignore-turn-restrictions --remove-short-arcs=5.4 --min-size-polygon=18 --description=velomap_dnw --show-profiles=1 --location-autofill=bounds,is_in,nearest --bounds=c:\openmtbmap\maps\bounds --route --country-abbr=dnw --country-name=nordrhein-westfalen --mapname=66570000 --family-id=6657 --product-id=1 --series-name=velomap_nordrhein-westfalen_30.01.2013 --family-name=velomap_dnw_30.01.2013 --tdbfile --overview-mapname=mapsetc --keep-going --area-name="nordrhein-westfalen_30.01.2013_velomap.org" -c c:\openmtbmap\maps\template.nordrhein-westfalen 7*.img 1>NUL --remove-short-arcs == resulting road will be broken --remove-short-arcs=5.4 == resulting road will be broken without remove-short-arcs == resulting road will be broken So it doesn't directly have to do with the --remove-short-arcs function. (also Compiled with --remove-short-arcs=5.4 ) http://openmtbmap.org/velonordrhein-westfalen_broken_2466.exe then Uncommented the following lines in my style-file, which shouldn't affect routing at all, but it does as the mistake is gone: # power=line [0x29 resolution 22 continue] # power=minor_line | powerline=yes | power_line=yes | powerline=true | power_line=true [0x29 resolution 24 continue] http://openmtbmap.org/velonordrhein-westfalen_nopower_2466.exe However I can also leave that line in the style-file, and delete some other lines, and routing will work again. There seems to be no clear pattern (except that the bug go introduced with rev 2448). I use the same line in my openmtbmap, and there the routing error doesn't happen. -- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org

1 0

coastline
by RheinSkipper 30 Jan '13

30 Jan '13

I am using precompiled <http://www.navmaps.eu/wanmil/sea_20121212.zip> sea_20121212.zip and ran into this problem: The coastline looks like this: http://files.mkgmap.org.uk/download/85/precompiled.jpg But it should look like this: http://files.mkgmap.org.uk/download/84/coastline.JPG Thanks in advance for your help with this issue.

7 22

how to convert Coord.distanceInDegreesSquared() to MapUnits?
by GerdP 30 Jan '13

30 Jan '13

Hi, what is the correct way to convert the value returned by Coord.distanceInDegreesSquared() into map units? A simple code like this seems not to work: double distSq = co1.distanceInDegreesSquared(co2); int mapUnits = Utils.toMapUnit(Math.sqrt(distSq)); Gerd -- View this message in context: http://gis.19327.n5.nabble.com/how-to-convert-Coord-distanceInDegreesSquare… Sent from the Mkgmap Development mailing list archive at Nabble.com.

1 1