- mkgmap-dev - The mkgmap lists

Commit: r2453: Changes based on comments from Geoff Sherlock.
by svn commit 16 Jan '13

16 Jan '13

Version 2453 was committed by steve on Wed, 16 Jan 2013 Changes based on comments from Geoff Sherlock. Plus added a description of the 'single file' format of a style.

1 0

Commit: r2452: Various stylistic documentation changes.
by svn commit 16 Jan '13

16 Jan '13

Version 2452 was committed by steve on Wed, 16 Jan 2013 Various stylistic documentation changes. - Carlos Dávila

1 0

Commit: r2451: Tests fail on windows because files can not be deleted when
by svn commit 16 Jan '13

16 Jan '13

Version 2451 was committed by steve on Wed, 16 Jan 2013 Tests fail on windows because files can not be deleted when open. So add a mechanism to close files at the end of a test. There was also a genuine open file leak in the main code when reading the MPS file from the gmapsupp. Removed two section of unused exception catching code that gives warnings on compile with some JDKs.

1 0

short roads with two nodes
by GerdP 16 Jan '13

16 Jan '13

Hi, while looking at the removeShortArcs problem I noticed that short ways are completely removed by removeShortArcs: http://www.openstreetmap.org/browse/way/119517945 I think this is not correct. It happens because the way is shorter than 5 m and has only two points. In the first pass of removeShortArcsByMergingNodes() the last point is merged with the first one, in the 2nd pass the way is removed because it has only one point. My understanding of the code is that removeShortArcsByMergingNodes doesn't want to remove the first or last point of a way, but it does in this case. Should I try to change that? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/short-roads-with-two-nodes-tp5744911.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

1 0

revert (most of) removeShortArcs patch
by GerdP 16 Jan '13

16 Jan '13

Hi all, with r2448 I committed the removeShortArcs patch. It turned out that this change doesn't pass the unit tests. It is quite difficult to adapt the unit tests, and it is also quite different to move the removeShortArcsByMergingNodes() method down to the MapDetail or RoadNetWork class. So, finally, I thought again about the problem that I wanted to solve: Shapes were not smoothed properly by DouglasPeuckerFilter because removeShortArcsByMergingNodes() gives too many nodes the preserved attribute. So, finally, I think it is better to move the removeShortArcsByMergingNodes() method back to ElementSaver and fix the problem in MapBuilder by simply resetting the wrong preserved attributes for all coords of MapElements that are not roads. Attached is a patch for r2450 which implements this. removeShortArcs_v3.patch <http://gis.19327.n5.nabble.com/file/n5744907/removeShortArcs_v3.patch> Gerd -- View this message in context: http://gis.19327.n5.nabble.com/revert-most-of-removeShortArcs-patch-tp57449… Sent from the Mkgmap Development mailing list archive at Nabble.com.

1 0

Regression in splitter r277 compared to r270? Area too small ...
by Thorsten Kukuk 15 Jan '13

15 Jan '13

Hi, with splitter r270, all of my maps are free of SEVERE errors. But with splitter r277, I get a lot of: 2013/01/14 06:33:46 SEVERE (MapSplitter): 71200148.osm.pbf: Area too small to split at http://www.openstreetmap.org/?mlat=54.45305&mlon=13.44031&zoom=17 (reduce the density of points, length of lines, etc.) Where there any changes which let expect such a result? mkgmap, the planet file and the style are the same, I really only exchanged splitter from r270 to r277 and reverted it afterwards to verify it is really this update. Splitter version unknown compiled 2013-01-11T10:25:35+0000 cache= description=TK-DACH-Tile geonames-file=osmmaps/scripts/cities/DACH.txt keep-complete=true mapid=71200001 max-areas=1024 max-nodes=1000000 max-threads=8 (auto) mixed=false no-trim=false output=pbf output-dir=build/DACH/tiles overlap=0 polygon-file= precomp-sea= problem-file= problem-report= resolution=13 split-file= status-freq=120 stop-after=dist write-kml= 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)

3 12

only old version of mkgmap on download page
by GerdP 14 Jan '13

14 Jan '13

Hi Steve, please check: since a few hours http://www.mkgmap.org.uk/download/mkgmap.html shows r2370 as the latest trunk version. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/only-old-version-of-mkgmap-on-download-page-… Sent from the Mkgmap Development mailing list archive at Nabble.com.

5 7

address index broken on GPS (etrex 30) again - only when sent with Mapsource or Mapinstall. Working if gmapsupp.img created by mkgmap.
by Felix Hartmann 14 Jan '13

14 Jan '13

Well that's about it. Last time working was 9 November confirmed. Broken since at least around a month... That's what I tried: Create Gmapsupp of full map with mkgmap: address search works Create gmapsupp of partial map (4 tiles) with mkgmap: address search works Mapsource: export 4 tiles: " enter state/province"" Mapsource full map: " enter state/province" Basecmap: export 4 tiles: " enter state/province". Happening with all of my maps. I.e. openmtbmap austria: ftp://ftp5.gwdg.de/pub/misc/openstreetmap/openmtbmap/odbl/mtbaustria.exe (.exe is a lzma2 archive by 7zip 9.28 alpha - (NOT old lzma). -- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org

2 5

Commit: r2449: Reduce initial size of typically small ArrayLists to reduce peak memory needs
by svn commit 14 Jan '13

14 Jan '13

Version 2449 was committed by gerd on Sun, 13 Jan 2013 Reduce initial size of typically small ArrayLists to reduce peak memory needs

2 1

Possible memory reduction in mkgmap
by GerdP 13 Jan '13

13 Jan '13

Hi, it is easy to change the HashMap<Long,Coord> coordMap in ElementSaver to use the OSMId2ObjectMap that I've implemented for splitter. This could reduce peak memory usage in mkgmap. A few numbers according to VisualVM: 2.248.404 coord instances managed in the HashMap req. 186.447.135 bytes, with OSMId2ObjectMap it is 57.194.684. This doesn't include the memory that is needed to store the Coord instances itself, (which I think is 2.248.404 * 32 = 71.948.928 bytes) it is just the overhead for the map. The disadvantage: OSMId2ObjectMap uses fastutil.jar, which is not used in mkgmap until now. I could try to change OSMId2ObjectMap so that it runs without fastutil.jar, but that would mean to invent the wheel again. Comments? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Possible-memory-reduction-in-mkgmap-tp574356… Sent from the Mkgmap Development mailing list archive at Nabble.com.

4 10