- mkgmap-dev - The mkgmap lists

Question for French members of the list
by Carlos Dávila 09 May '13

09 May '13

A user of my map of France reported that he could not find any address in Paris in his nuvi. Tracking it down I found that we use the following lines in the address file: mkgmap:country=FRA & mkgmap:city!=* & mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' } mkgmap:country=FRA & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } but according with OSM wiki [1], admin_level=9 is used in France only for some "Arrondissement" in Paris, Lyon and Marseille. I have extracted admin_level=9 ways and relations in France and those "Arrondissement" are named "1re, 2e, 3e,... arrondissement", which I don't know if is really used/useful when looking for an address in these cities or if different arrondissements can have streets with the same name. Looking at the admin_level=9 data in France, there are 93 (for a total of 156) relations tagged as type=boundary, boundary=religious_administration, admin_level=9 which have nothing to do with admin boundaries, but are caught by the fist rule above, avoiding the use of the admin_level=8 information for those areas. So, the question is, do you think we must keep the admin_level9 line in the address file or remove it? I vote for the second, but would like to know the opinion of someone who knows better the administrative organization of France. [1]http://wiki.openstreetmap.org/wiki/Key:admin_level#admin_level

2 1

order of lines / roads
by Gerd Petermann 09 May '13

09 May '13

Hi all, beginning with r2448 I've committed changes which had an influence on the order of lines and and roads. This was not intended, just a side effect. I was not aware that this has an effect on overlaid objects, see e.g. http://gis.19327.n5.nabble.com/Commit-r2567-roads-first-v1-patch-Make-sure-… The problems occurs because we have to colllect all roads first and separate them from other lines. Up to r2448 the option --preserve-element-order probably worked as expected: all objects were processed by the style in the order of appearance and they were also written in this order. Since r2448 the roads were either all written after the other lines or before. The "mkgmap:set_unconnected_type" feature is also likely to mix the order. Polygons were never effected by any of these changes. It looks quite complicated to implement the behaviour of r2448 again (also because the housenumber code needs the separation), so I wonder if it is acceptable to implement --preserve-element-order like this: we keep the order of roads and we keep the order of other ways, and we make sure that roads are added after the other ways. It would also be possible to add an option so that we add roads first if that is needed. Is this limitation a problem for anybody? Gerd

4 8

[Patch v1] overlaid lines shifted
by Gerd Petermann 09 May '13

09 May '13

Hi, see first http://gis.19327.n5.nabble.com/merge-lines-and-routing-tp5758913p5759595.ht… I think the reason is the remove-short-arcs processing. This can move a road, esp. if you use a rather large value like --remove-short-arcs=5.4. In the example case, way http://www.openstreetmap.org/browse/way/27904971 is moved towards http://www.openstreetmap.org/browse/way/217767494 Now, the overlaid line with type 0x10650 (really this invalid extended type?) is not a road and stays where it belongs. Another possible effect would be that the road is deleted while the copy is not. I think the solution is to make sure that 1) all lines created from the same OSM way have the same points after short-arc-removal was done with roads only 2) if short-arc-removal deletes a road (e.g. because it only has one short arc),the other lines for the same OSM way are deleted as well. Attached is a patch that implements this, a compiled binary is here: http://files.mkgmap.org.uk/download/120/mkgmap.jar Gerd

3 3

easy download of latest/stable version of mkgmap and splitter
by Henning Scholland 08 May '13

08 May '13

Hi there, would it be possible to create also a mkgmap-latest.zip and mkgmap-stable.zip? Actual you have to know the latest/stable version number of splitter and mkgmap to download latest version. So it's pretty hard to create an easy setup for a map-creator-tool or script. Henning

2 1

options for overview map
by Gerd Petermann 08 May '13

08 May '13

Hi, the code in the overview2 branch is nearly ready for trunk now, but the configuration and documentaion is not yet ready. The current implementation in the overview2 branch adds these new options: --overview-levels like levels, specifies additional levels that are to be written to the overview map. --remove-ovm-work-files If overview-levels is used, mkgmap creates one additional file with the prefix ovm_ for each map (*.img) file. These files are used to create the overview map. With option --remove-ovm-work-files=true the files are removed after the overview map was created. The default is to keep the files. The overview map is created by default (like the *.tdb file) if any input file is processed. It is empty if you don't use overview-levels (like in the trunk version) I noticed a rather confusing behaviour (also in the trunk): the option --tdbfile is not needed to create the *.tdb file, but it has an influence on the creation of the index files: if (indexOpt && (tdbOpt || !gmapOpt)) { addCombiner(new MdrBuilder()); addCombiner(new MdxBuilder()); } This also means that even with --no-tdbfile the tdb file and the overview map is produced. I think we should completely remove the tdbfile option and assume it to be true in the above code snippet. Gerd

1 0

Overview2 branch - options file typo?
by Felix Hartmann 07 May '13

07 May '13

Is there a typo in the options file? "overview-levels = 5:16 6:18 " shouldn't that be 5:16 6:14 ??? I think that if the numbering continues, further levels should be decreasing resolution. So if 18 and 16 should be used in the overview map (but why have 17 then as normal map resolution??): it should read "5:18 6:16" -- However I thought overlapping resolutions is not good form (actually dunno what happens). IMHO 5:16 6:14 is quite good as conservative value. (continent maps). Maybe we should even move to 4:17 5:16 6:14 in the overview map (and 0-3 in the normal map)... As for the routable basemap on newer garmin GPS. Maybe we could create a non routable mkgmap created basemap and recommend people to use it instead?

4 21

straight lines are deformed
by Minko 06 May '13

06 May '13

Hi, I see that the latest merge lines changes are deforming long straight lines (like railways) into zig zagged lines at lower zoomlevels (resolution <22). For instance this straight railroad http://www.openstreetmap.org/browse/way/89630797 See the differences between the image left (mkgmap-overview2-r2564.jar) and right (mkgmap-overview2-r2590.jar). If I zoom in the jagged zigzag lines disappear at resolution 22 and become straight as it should be. In the older mkgmap versions they remain straight. I always have used --merge-lines in my settings.

2 4

Commit: r2567: roads_first_v1.patch: Make sure that roads are placed before other lines
by svn commit 06 May '13

06 May '13

Version 2567 was committed by gerd on Thu, 11 Apr 2013 roads_first_v1.patch: Make sure that roads are placed before other lines in each sub division.

4 10

Commit: r2589: Don't print routing warnings in LineSplitterFilter if --route option is not active
by svn commit 06 May '13

06 May '13

Version 2589 was committed by gerd on Mon, 06 May 2013 Don't print routing warnings in LineSplitterFilter if --route option is not active

1 0

Commit: r2588: revert roads_first_v1.patch: did not solve any problem
by svn commit 06 May '13

06 May '13

Version 2588 was committed by gerd on Mon, 06 May 2013 revert roads_first_v1.patch: did not solve any problem

1 0