- mkgmap-dev - The mkgmap lists

style options vs. command line options
by Gerd Petermann 23 Apr '13

23 Apr '13

Hi all, during the last days I tried to find a proper way to handle the options "levels", "name-tag-list", and "extra-used-tags" which can appear in the options file of a style. The current implementation in trunk (r2575) handles each of the three options in a completely different way: 1) If name-tag-list is given on the command-line, it overrides the setting in the style, if not, parts of the program use the style option, parts use a hard coded default. 2) If levels is given on the command line, it overrides the setting in the style, but not in the routines that evaluate the style rules. 3) extra-used-tags can't be overwritten because there is no such option, which is - in my eyes - correct . I plan to add further options for the configuration of the overview map, so I tried to find a common method to handle the way how argument overriding is done. To be honest, I found none. Some methods use the static method LocatorUtil.getNameTags() which doesn't know the style and evaluates only the command line args, and I also found no easy way to copy the option coded in the style to the list of command line args. So, my proposal is this: 1) the option name-tag-list in the style options is unusable and should be removed. A warning should be printed when the option is found in the style, but not on the command line and the style specifies a value different to the hard coded default which is just "name". 2) the option levels on the command line should completely override the setting in the style options file. I think that a test should be performed to make sure that the resulting style is usable. If someone has a better idea, please let me know. Gerd

1 1

Map display squeezed horizontally
by Michael Prinzing 22 Apr '13

22 Apr '13

Hello, while examining the wrong labels in Mapsource I found another strange problem with my map. Compared with other maps, my own map seems to be squeezed horizontally. I made a screenshot to illustrate this, please see http://www.mipri.de/dl/maps.png I've mounted two screenshots side by side. Both are made from exactly the same Mapsource window, I just switched the map. The left is my own map, the right a map created without own style and TYP file. While the height is absolutely identical in both maps, my own map is squeezed horizontally, showing areas that are not visible in the map on the righthand side, for example the parking below the Min Map. The scale in the lower right corner is identical in both maps, and not squeezed like the map. I've also tried other maps, they all look like the map at the right. So it's definitely my own map which is displayed wrong. My map was built as follows: - Created contour data with srtm2osm, renumbered ways and nodes so that their IDs do not collide with "real" OSM IDs, converted to PBF - Downloaded OSM data for Germany from Geofabric in PBF format - Merged both using the latest stable osmosis - Splitted the resulting PBF - Created the map with the latest mkgmap Does anybody have an idea how this deformation could have been caused? Thank you for your answers, Michael

6 12

[PATCH v1] Support relation destination_sign
by WanMil 22 Apr '13

22 Apr '13

For all those who like the --process-destination option I have added another feature. The patch analyses the relations with type=destination_sign and adds its destination and/or ref/destination_ref/destination:ref tag to the "to" members of the relations. This is performed in case the to member is a oneway way with highway=*_link. The destination tag is copied from the relation if the "to" member does not already have a destination tag. The same happens with the ref/destination_ref/destination:ref tags. They are set as destination:ref tag in case the "to" way does not already have a ref tag. Afterwards the ways are processed by the common --process-destination algorithm. Sounds great espacially because the number of destination_sign relations is growing quite well. But: the effect of the patch is quite small. I have compiled a map of germany. Destination_sign relations: 3677 Destination tags copied to _link ways: 121 Destination:ref tags copied to _link ways: 41 Examples: http://www.openstreetmap.org/browse/way/213248346 gets a destination:ref tag. http://www.openstreetmap.org/browse/way/194845924 gets a destination tag. Most of copied destination tags are the name of exits. (I didn't measure the values but a small sample showed this). Anyhow try yourself with your data and let me know if it should be commited. WanMil

2 7

Precompiled-sea
by Josef Latt 22 Apr '13

22 Apr '13

Hi, where can I download the precompiled-sea. Trying to connect to navmaps.eu I get an error: Database connection error (2): Could not connect to MySQL Regards Josef

3 4

Problem with bounds_*.zip
by Bernd Weigelt 22 Apr '13

22 Apr '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello I've got a mail from an user in Sri Lanka, who use a map on a Nüvi | The last OSM Sri Lanka only map that you sent me has a Region | Error.Garmin nuvi device shows the country | name of the map as *Sh??rii Lnkaa.* It spells Sri Lanka deadly wrong. | | You can see this map error in a nuvi device just touch *Where To? | *then *Junction. *There you can see it shows *Sri Lanka* as *Sh??rii | Lnkaa.* | Can you re correct this error and show me the up dated map file? I can see this on my Oregon too. I use latin1 in my conf, but i had to remove '--bounds=bounds_20130803.zip' from the mkgmap-options to show *Sri Lanka* Any hints? cu Bernd -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFEsRQACgkQwCMdlf933K/TogCghJjePuINCe4EQqifNqsX6k2U mdQAoJlyQ80FfgbQ2EUNj1OZrMRVoFvt =uZfN -----END PGP SIGNATURE-----

8 16

overview2 branch
by GerdP 21 Apr '13

21 Apr '13

Hi all, I like to merge the branch to the trunk, but I first want to change the configuration. I like to change the settings like this: When mkgmap creates an overview map, it adds by default all elements that are contained in the lowest resolution of the *.img files. If parameter --overview-cfg is given, mkgmap uses the filters specified in this file. In other words, the options --x-overview-add-points, --x-overview-add-lines, and --x-overview-add-polygons will be removed, and the default overcview-cfg file is like point:* line:* polygon:* Is that ok? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/overview2-branch-tp5756308.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

7 17

Commit: r2575: Document the list of special mkgmap tags used by address search
by svn commit 20 Apr '13

20 Apr '13

Version 2575 was committed by wanmil on Sat, 20 Apr 2013 Document the list of special mkgmap tags used by address search

1 0

Re: [mkgmap-dev] "No roads near target" bug in Schwabmünchen
by Bernd Weigelt 19 Apr '13

19 Apr '13

11 110

Wrong "Object Class" displayed in Mapsource
by Michael Prinzing 19 Apr '13

19 Apr '13

Hello, I am creating my own map with mkgmap and am using it on an eTrex Vista HCx and with Mapsource. In Mapsource, when the mouse pointer is moved over an object (like a road, a building or another POI) and the right mouse button is pressed, a context menu appears listing anything under the pointer. If there is no other polygon (like forest, residential, ...) than the "empty" background under the mouse pointer, Mapsource lists the background as "Hospital". Please see http://www.mipri.de/dl/background.png for an example. "Kartenmerkmal - Straße" is correct, but "Krankenhaus - Unbekanntes Gebiet" ("Hospital - Unknown area") is not. In my TYP file I am using 0x4b for the background, while my style (like the default style) is assigning 0x0b to hospitals. I don't know if there is any relation, but some days ago Gerd wrote: > the code changed the background type 0x4b to 0x0b. I find this > also in the trunk version and in the current code of the display > tool, so I am not sure why this happens. Could it have to do with this? There are other cases where the labels in Mapsource are wrong: If I am putting the mouse over a "real" hospital, the building gets listed as "Marine", see http://www.mipri.de/dl/hospital.png. In this case "Krankenhaus - Chirurgische Klinik" is correct, "Marine - Chrirurgische Klinik" is not. Something similar happens with forests, but only if there is no "wood" key defined. In this case, they are listed as "Autoservices - Wald" ("Car repair - Forest") as in http://www.mipri.de/dl/wood.png. The examples were taken near the University of Ulm, Germany, but it could be elsewhere. The mouse pointer did not get captured in my screenshots, it was at the position in the upper left corner of the popup menu. These wrong labels seem to appear only in Mapsource, I did not see them on my GPS yet. Any ideas what could be going wrong here? Thanks, Michael

3 4

Commit: r2573: routable_types_v6.patch :
by svn commit 19 Apr '13

19 Apr '13

Version 2573 was committed by gerd on Fri, 19 Apr 2013 routable_types_v6.patch : - add option --check-styles which works like --list-styles but performs additional checks to flag potential routing problems - replace "check-connected" feature with "mkgmap:set_unconnected_type" feature to allow adding unconnected roads as normal lines with an alternative type or to ignore them - issue a warning when a routable map contains lines with routable types that are not roads (= have neither road_class not road_speed set in the style)

1 0