- mkgmap-dev - The mkgmap lists

Commit: r3363: Change severity to warning for removed way that is part of valid restriction relation.
by svn commit 05 Dec '14

05 Dec '14

Version mkgmap-r3363 was committed by gerd on Fri, 05 Dec 2014 Change severity to warning for removed way that is part of valid restriction relation. The way might be very short and leading to nowhere, in this case it is okay to remove the way and later ignore the restriction.

1 0

Occasional header corruption in gmapsupp.img
by franco_bez 04 Dec '14

04 Dec '14

Hi all, once again I stumbled over a really weird problem: In rare cases mkgmap produces a gmasupp.img that shows up as "Map data (c) OpenSt" in the list of maps on my Oregon 550. Screenshots: <http://gis.19327.n5.nabble.com/file/n5825759/bad_01.png> <http://gis.19327.n5.nabble.com/file/n5825759/bad03.png> <http://gis.19327.n5.nabble.com/file/n5825759/bad04.png> <http://gis.19327.n5.nabble.com/file/n5825759/good_01.png> <http://gis.19327.n5.nabble.com/file/n5825759/good03.png> <http://gis.19327.n5.nabble.com/file/n5825759/good04.png> There is no error message or warning when building the gmapsupp.img, I observe this problem for some 4 month now and I can 100% reproduce the bug. It seems to be triggered by the OSM-inputdata although the OSM-data itself is OK. The problem occurred on a DACH-extract with my bikeroute-highlights-overlay style a few months ago, now I have it with a ITALY-extract and my housenumbers-overlay style. Usually I build 6 different gamapsupp.img files for 6 different styles from the same tiles. Only one of them, if any, has the buggy header. The problem usually disappears after an update of the OSM-data, just to reappear a few days or weeks later. I kept 2 versions of the ITALY-extract for reference and with those I can 100% reproduce a faulty gmapsupp.img. I often update the versions of splitter and mkgmap I use for building the maps. mkgmap-r3356 and splitter-r414 still produce the same bug. The problem assembling a test-case is that the ITALY-extract has a size of 1.2 GB . When I remove just one tile from the split extract the gmapsupp.img is OK. I cannot produce a small testcase. I uploaded a sample of a gmapsupp.img with the bug, and one that is error free. http://files.mkgmap.org.uk/download/233/maps.tgz Ciao, Franco -- View this message in context: http://gis.19327.n5.nabble.com/Occasional-header-corruption-in-gmapsupp-img… Sent from the Mkgmap Development mailing list archive at Nabble.com.

2 6

Commit: r3362: Fix size calculation for gmapsupp.
by svn commit 04 Dec '14

04 Dec '14

Version mkgmap-r3362 was committed by steve on Thu, 04 Dec 2014 Fix size calculation for gmapsupp. This would lead to the MPS file appearing not to be present and so the names would show differently. TODO: It will still be incorrect for unicode files.

1 0

Commit: r3361: fix typo GERMAYN -> GERMANY
by svn commit 04 Dec '14

04 Dec '14

Version mkgmap-r3361 was committed by gerd on Thu, 04 Dec 2014 fix typo GERMAYN -> GERMANY

1 0

Commit: r3360: revert unintended change of build.xml
by svn commit 04 Dec '14

04 Dec '14

Version mkgmap-r3360 was committed by gerd on Thu, 04 Dec 2014 revert unintended change of build.xml

1 0

Commit: r3359: evaluate-associatedStreet-rel-v2.patch: improve house number evaluation
by svn commit 04 Dec '14

04 Dec '14

Version mkgmap-r3359 was committed by gerd on Thu, 04 Dec 2014 evaluate-associatedStreet-rel-v2.patch: improve house number evaluation The data in type=associatedStreet and type=street relations is used to fill missing street name info.

1 0

[Patch v4] drive-on-left/drive-on-right handling
by Gerd Petermann 03 Dec '14

03 Dec '14

Hi all, attached is v4 of the patch. The drive-on parameter now accepts the following values: left|right|detect|detect,left|detect,right - detect is equal to detect,right - with detect all roads are counted to find out whether the map is a drive-on-left or drive-on-right map - if the detection doesn't return a clear result, the 2nd option is used - the polish reader only checks the "LeftSideTraffic" string, it doesn't count anything (for now) @Steve, WanMil: I've added methods getDriveOnLeft() to MapperBasedMapDataSource and use it in MapBuilder before a TREFile or NODFile is written to configure the corresponding flags. Classes that are able to detect the dr I think this is a bit cleaner compared to v3 and to trunk.

2 1

[Patch v3] drive-on-left/drive-on-right handling
by Gerd Petermann 02 Dec '14

02 Dec '14

Hi all, attached is v3 of the patch. I think we should finish this before we start with the coding for the non-rectangular tiles support. 1) I've tried to make sure that the flags in TRE and NOD are set to equal values. 2) The options --drive-on-left and --drive-on-right are deprecated but still evaluated, for now a warning is printed when they are used. The new option --drive-on=detect|right|left should be used instead. The value detect enables a rather complex (but not CPU-intensive) algo: 1) For each roundabout it checks if the country is known and -- if so -- if the country is a drive-on-left country. 2) If the number of "dol" roundabouts is larger than the rest, the internal drive-on switch is set to "left", similar the internal drive-on switch is set to "right" if the number of "dor" roundabouts is larger than the rest. This works only if either a complete bounds file is used or the default country is set with --country-abbr or --country-name. 3) If option --check-roundabouts is used and the internal drive-on switch is still "detect", than the first found roundabout is used to set the internal drive--on switch. 4) Finally, If the internal drive-on switch is "left", the flags in the headers are set to 1. 5) The polish fomat reader now recognizes the line LeftSideTraffic=Y in the mp file. 6) If the user specifies --drive-on=left, both header flags are set to 1, no matter what roundabouts are found. @Steve, WanMil: I've added a ThreadLocal<boolean> to TREHeader similar to that in NODHeader, but I think it would be better to store that info only once for each thread, I just don't know where, maybe MapMaker? Besides that I am not sure how this works when we write two different TREHeader files in one thread (one for the overview map data ovm_*.img) (well, the flag in these files is ignored anyway) Please suggest a better solution. Gerd

5 11

housenumbers and addr:interpolation
by GerdP 02 Dec '14

02 Dec '14

Hi all, while looking at the relation type=associatedStreet I noticed another kind of information that is still ignored: See e.g. http://www.openstreetmap.org/relation/1518163 It contains members tagged with role=house which are not buildings but lines with a tag addr:interpolation=all and two nodes giving the range of housenumbers, nothing else. I am not yet sure how to use that info, working on it... Gerd -- View this message in context: http://gis.19327.n5.nabble.com/housenumbers-and-addr-interpolation-tp582598… Sent from the Mkgmap Development mailing list archive at Nabble.com.

5 10

Commit: r3358: ISO-filter-v2.patch : new style filter country-ISO
by svn commit 02 Dec '14

02 Dec '14

Version mkgmap-r3358 was committed by gerd on Tue, 02 Dec 2014 ISO-filter-v2.patch : new style filter country-ISO

1 0