- mkgmap-dev - The mkgmap lists

Search in Basecamp with r3912
by Gerd Petermann 23 Apr '17

23 Apr '17

Hi all, I've just learned that the branch (also current r3912) doesn't work well with Basecamp when you search a road using the search field in the upper right corner. It will not find a lot of road names while it shows them when you open the advanced dialog and enter the same name in the "Street" field. This is caused by a different sorting in the branch and I think that I now understand what I have to change... Gerd

1 0

mkgmap-r3906 (optimize-index)
by Gerd Petermann 21 Apr '17

21 Apr '17

Hi all, with the help of Steve I fixed some problems with the index, esp. sorting of road names with different speliing of Straße caused a lot of problems, like Ahornstraße (Germany) and Ahornstrasse (Switzerland). I think address / road search works very well now, at least with west european languages. I tried various combinations of options like --latin1 / --unicode, --lower-case, --x-split-name-index both in MapSource and on my Oregon 600 and always got what I expected. IMPORTANT: If you try this version, please make sure that you also compile the img files with this version so that the changes in the sort are used everywhere. The branch also reduces peak memory compared to trunk and because of that it is faster when creating large indexes, but speed is probably not so important here. The created index is a bit smaller although it now also contains roads with an empty string as first label. If memory is still an issue for you when compiling the index for large maps I can try to implement a merge sort which would only create the - heap consuming - sort keys for a rather small number (e.g. 100.000) roads and sort those and finally merge the parts. If you know special cases which don't work with r3890 trunk please try the branch and let me know if something might be improved. I think it is a big step forward, but there may still be special cases with other languages. I used a small set of only 4 tiles to test functionality and compiled index for Europe (compiled with default style) (>1600 tiles) with -Xmx6800m and --x-split-name-index Gerd

3 9

Commit r3909: default style: change handling of refs for road names so that ref and name are not concatenated
by svn commit 21 Apr '17

21 Apr '17

Version mkgmap-r3909 was committed by gerd on Fri, 21 Apr 2017 default style: change handling of refs for road names so that ref and name are not concatenated This change is visible in the search dialogs, the map looks more or less the same. modified refs_v2.patch by Carlos Davida http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3909

1 0

How can we use prefix/suffix feature in road names?
by Gerd Petermann 19 Apr '17

19 Apr '17

Hi all, recently I learned about this feature which is already partly implemented in mkgmap, but not easy to use with OSM data. See http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2017q2/026602.html There is at least one visible effect of these 0x1e and 0x1f characters: When you zoom out MapSource removes the prefix / suffix part(s) from the name. So "Rue de la Concorde" is displayed as "Concorde" which requires less space and probably allows to display more names. If I got that right the prefixes and suffixes are also excluded from the index by mkgmap, but that might not yet work. My understanding is that we need a way to change the a road label "Rue de la Concorde" to "Rue de la" + 0x1e +"Concorde" or "Fernrodder Strasse" to "Fernrodder" + 0x1f + "Strasse". Does anybody already use that feature in style rules? I can think of several ways to implement that. 1) A collection of style rules for well known prefixes and suffixes. I fear those would be quite complex. 2) A new option file listing prefixes and suffixes and some Java code to modify all road labels. Format of the file might be prefix=Rue de la prefix=Rue du prefix=Rue de prefix=Rue prefix=Rua prefix=Chemin de la prefix=Chemin du prefix=Chemin de prefix=Chemin ... suffix=Road suffix=Steet suffix=Strasse suffix=Weg ... I assume it is possible to compile a single regular expression from this, so performance should not be a problem. Gerd

5 17

Re: [mkgmap-dev] [Patch] Default Style change handling of road refs
by David 18 Apr '17

18 Apr '17

I did not test the suggested patch but here is a user feedback. I want to see on my GPS screen informations that I can check easily along my way. For example, if I want to follow the major road called Nationale 7 or "Route bleue" in France (because it goes from Paris to the Mediterranean Sea), I have to find "N7" on signs along my way. You will never see "Route bleue", except in the name of some restaurants near the road. All this to say that the most important information is what is displayed inside the shield or the rectangular shape on GPS map for a visual search. But "Route bleue" is still an information that should be searchable through the search menu. David > Le 15 avr. 2017 à 13:00, mkgmap-dev-request(a)lists.mkgmap.org.uk a écrit : > > Re: [Patch] Default Style change handling of road refs

2 1

[Patch] Default Style change handling of road refs
by Gerd Petermann 15 Apr '17

15 Apr '17

Hi all, got no feedback on this: http://gis.19327.n8.nabble.com/Possible-problem-with-global-search-index-si… The patch changes the default style so that road refs are no longer added to the road name, instead they are added as an additional label, So, a way like this http://www.openstreetmap.org/way/115469125 with name=Hamburger Straße, ref=B 105 will appear as "Hamburger Straße" in the map and will be found when searching for "B 105". Without the patch the road appears as "B 105 Hamburger Straße" (the B 105 in a highway shield) in the map and as "Hamburger Straße (B105) or "Hamburger Straße" or "B 105 Hamburger Straße" (without shield) when searching for Hamburger. I always found that very irritating. Please comment or propose improvements. Gerd

2 2

[Patch v1] improve mdr7 index
by Gerd Petermann 13 Apr '17

13 Apr '17

Hi all, attached is a patch which changes the meaning of --x-mdr7-excl and adds a 2nd option --x-mdr7-del. A binary is here: http://files.mkgmap.org.uk/download/345/mkgmap.jar The new option --x-mdr7-del can be used to delete strings from road names before they are written to any index. The option --x-mdr7-excl is now only used for the partial names created by the --x-split-name-index option. If you place them in an option file, you may use this: x-mdr7-excl=Weg,Straße,Street,Road x-mdr7-del=Service,Primary,Secondary,Tertiary,.... So, in x-mdr7-excl you list parts of real road names which should not be searchable. In x-mdr7-del you put words which were added by your style and should be removed from the name. The removement of those strings is done from the end, it stops when a word is found that should not be deleted. This is what I described as 1a) here: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2017q2/026584.html You may now add blanks to improve readabilty, so x-mdr7-excl=Weg, Straße, Street, Road works like above. I am not sure if there is a case where we want to be able to exclude multiple words. @Arndt: In your current config file you use "Via Ferrata" and some other combinations with blanks like "unpav CyW". This will no longer work with this patch. Maybe you can change your style to add "Via-Ferrata" instead the other combinations are simply no longer needed. Do we need some kind of reporting for these options? Maybe some stats like mdr7-excl option Weg matched 11231 times mdr7-excl option Straße matched 2321 times ... Gerd

3 16

Missing sea and coastline while using Splitter
by Dave Swarthout 12 Apr '17

12 Apr '17

Hi, I have been compiling my own maps of my local areas (<600 mB) for a couple of years now but the other day for the first time I had to use splitter to divide a large .osm file. It took several tries to get everything working to the point that a useful map emerged from the process. However, my directives are not being processed so the map I get is a plain vanilla version The sea and coastline are invisible in the finished product. In addition, some of my custom lines are missing, for example, the ones used for unpaved roads and waterway direction. Inexplicably, most of my custom styles for both highways and POIs are visible. Th simple splitter command line I'm using is here: [code]java -Xmx1000m -jar ..\splitter\splitter.jar "C:\Users\alask\Downloads\Maps\Alaska.osm" --output-dir=..\splitter > ..\splitter\splitter.log [/code] I've seen examples of a splitter command that uses the *--precomp-sea="C:\Users\alask\Downloads\Maps\sea.zip" *argument in its call but iI tried that and it made no difference in the result. Anyway, this generates three .osm files (63240001, 2, and 3) which I then process with mkgmap and the following command line. This exact comand line (but without the template.args parameter) runs perfectly and creates a map containing all my styles and shows the coastline and sea properly: java -Xmx1000m -jar mkgmap.jar *-c "C:\Users\Alask\Documents\splitter\template.args"* --latin1 --family-id=24983 --name-tag-list=name:en,int_name,name --gmapsupp --description="Alaska" --country-name=USA --country-abbr=USA --index --location-autofill="is_in,nearest" --copyright-message="ODbL by OSM contributors" --link-pois-to-ways --add-pois-to-areas --reduce-point-density=4 --reduce-point-density-polygon=8 --merge-lines --route --drive-on=right --net --housenumbers --x-split-name-index --check-roundabouts --check-roundabout-flares --process-destination --process-exits --poi-address *--generate-sea=land-tag=natural=background --style-file="C:\Users\alask\Dropbox\Mapping\DJS_styles" --precomp-sea="C:\Users\alask\Downloads\Maps\sea.zip" --bounds="C:\Users\alask\Downloads\Maps\bounds" "C:\Users\alask\Dropbox\Mapping\24983djs.TYP"* Is the placement or order of the arguments important? Any other ideas or suggestions much appreciated. Thanks for your help, Dave -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com

3 2

(no subject)
by Dave Swarthout 12 Apr '17

12 Apr '17

Hi, I have been compiling my own maps of my local areas (<600 mB) for a couple of years now but the other day for the first time I had to use splitter to divide a large .osm file. It took several tries to get everything working to the point that a useful map emerged from the process. However, my directives are not being processed so the map I get is a plain vanilla version The sea and coastline are invisible in the finished product. In addition, some of my custom lines are missing, for example, the ones used for unpaved roads and waterway direction. Inexplicably, most of my custom styles for both highways and POIs are visible. Th simple splitter command line I'm using is here: [code]java -Xmx1000m -jar ..\splitter\splitter.jar "C:\Users\alask\Downloads\Maps\Alaska.osm" --output-dir=..\splitter > ..\splitter\splitter.log [/code] I've seen examples of a splitter command that uses the *--precomp-sea="C:\Users\alask\Downloads\Maps\sea.zip" *argument in its call but iI tried that and it made no difference in the result. Anyway, this generates three .osm files (63240001, 2, and 3) which I then process with mkgmap and the following command line. This exact comand line (but without the template.args parameter) runs perfectly and creates a map containing all my styles and shows the coastline and sea properly: java -Xmx1000m -jar mkgmap.jar *-c "C:\Users\Alask\Documents\splitter\template.args"* --latin1 --family-id=24983 --name-tag-list=name:en,int_name,name --gmapsupp --description="Alaska" --country-name=USA --country-abbr=USA --index --location-autofill="is_in,nearest" --copyright-message="ODbL by OSM contributors" --link-pois-to-ways --add-pois-to-areas --reduce-point-density=4 --reduce-point-density-polygon=8 --merge-lines --route --drive-on=right --net --housenumbers --x-split-name-index --check-roundabouts --check-roundabout-flares --process-destination --process-exits --poi-address *--generate-sea=land-tag=natural=background --style-file="C:\Users\alask\Dropbox\Mapping\DJS_styles" --precomp-sea="C:\Users\alask\Downloads\Maps\sea.zip" --bounds="C:\Users\alask\Downloads\Maps\bounds" "C:\Users\alask\Dropbox\Mapping\24983djs.TYP"* Is the placement or order of the arguments important? Any other ideas or suggestions much appreciated. Thanks for your help, Dave -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com

1 0

Address search on device with --x-split-name-index option
by Gerd Petermann 11 Apr '17

11 Apr '17

Hi all, not sure how this works on other devices. I have a map containing a part of the alps with parts of Germany, Switzerland and France. On my Oregon 600 when I search for an address I have some dialogs 1) select a country (I select Switzerland) 2) select city or select "search all" 3) Enter Street name. I can type a few characters and press enter. The device presents a list of road names matching the selected characters. 4) Last is to enter the house number. I can leave it empty to search for streets. If I select a city (Feuerthalen)in step 2) everything seems to work fine. It lists "Obere Rheingasse" as well as "Rheingasse" when I enter "Rheinga". If I select "search all" the results are weird. Sometimes I get "no result, change search parameters", sometimes results look ok. When I change the code in mdr20 to ignore the additional entries produced with the "--x-split-name-index" option the problem seems to be solved, I just don't find "Obere Rheingasse" when I search for "Rheingasse". Does anybody see better results in this case with a map produced with trunk? Gerd

3 13