January 2013 - mkgmap-dev - The mkgmap lists

Question reg. precompiled bounds
by GerdP 17 Jan '13

17 Jan '13

Hi, the wiki says that I have two alternatives to extract boundary data from an OSM file, either osmfilter: "fast, resulting files contains some unused stuff that eats memory when precompiling bounds" or osmosis: "slow". What about a combination of both (first osmconvert, than use osmosis to filter the output of osmconvert) ? Ciao, Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Question-reg-precompiled-bounds-tp5744094.ht… Sent from the Mkgmap Development mailing list archive at Nabble.com.

3 3

Map size increase using osmupdate vs download
by Eric Fernandez 17 Jan '13

17 Jan '13

Hi, I am unsure this is the best place to post this, but have a question regarding creating maps with osm maps updated with osmupdate. I usually start from an .osm.pbf map downloaded from Geofabrik, and in order to avoid downloading it again, I use osmupdate to maintain it (or a converted .o5m version of it) up to date. I noticed that my maps were becoming bigger and bigger, days after days, but *bigger than a plain redownload* of the map on Geofabrik. 1. Is this normal? Does osmupdate just append the changelog to the original file? 2. mkgmap-produced maps become significantly bigger too: is it normal too? 3. If the changelog is just appended to the map, is there a way to rebuild it from scratch to get the same map than on Geofabrik? Thanks for your help. Eric

2 9

user tag deprected
by Thomas 17 Jan '13

17 Jan '13

Hi Today a got a strange message from mkgmap: WARNING: Style uses tag 'display_name' which is deprected and will be removed soon. Please use the new tag 'mkgmap:display_name' instead. I use a binary TYP file which is created by ati land (http://ati.land.cz/gps/typdecomp/editor.cgi) This editor nowhere shows a tag called 'display_name' as well as the decompiled text file. What do I have to change? Thanks. Thomas

2 2

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