May 2017 - mkgmap-dev - The mkgmap lists

test map
by Gerd Petermann 18 May '17

18 May '17

Hi all, I've uploaded a small test map that shows the problem on my Oregon 600 with firmware 5.00: http://files.mkgmap.org.uk/download/353/gmapsupp.img Please test what your device shows when you search for a) all roads in city "Albertslund Kommune". On my Oregon the list contains many entries, esp. these Abildgården Æblets Kvt Alberts Have Alberts Vænge ... more with letter A b) all roads in city "Albertslund Kommune" starting with A. My Oregon shows only Abildgården I think It should show the above entries. c) all roads in city "Albertslund Kommune" starting with Æ. My Oregon says "No result found" d)all roads in city "Albertslund Kommune" starting with Ae. My Oregon says "No result found" e) all roads in city "Albertslund Kommune" starting with Al. My Oregon shows Alberts Have Alberts Vænge ... more with letters Al (good) Maybe try also to search for all roads in country Denmark starting with Ae or Æ. My Oregon says "No result found". Let me know if you see the same results or not. Thanks, Gerd

5 5

please test r3942
by Gerd Petermann 17 May '17

17 May '17

Hi all, It seems that r3942 produces maps which work quite well with MapSource and Basecamp. I can find roads with names like Æblegården or "Außer Ort". I find POI in the expected category. Anyhow, I see different results on my devices. It seems that the Oregon 600 with firmware 5.00 doesn't "understand" the GARMIN SRT file. Road names containing characters which appear in the "expand" section cause trouble. For cp-1252 (--latin1) these are expand … to . . . expand ¼ to 1 / 4 expand ½ to 1 / 2 expand ¾ to 3 / 4 expand æ to a e expand Æ to A E expand œ to o e expand Œ to O E expand ß to s s expand ™ to T M I am pretty sure now that this is a bug in the Oregon firmware. It would be interesting to know if firmware 4.60 worked. According to this page http://www8.garmin.com/support/download_details.jsp?id=6157 there was a change described "Improved address search" with 4.80. Unfortunately I was not able to download any previous version. Any hints? The Nüvi2447 seems to work fine with maps created with --latin1 (also with --lower-case) but says that --unicode maps are broken. This also happens when I use MapSource to install the map on the device. The installed map "GARMIN CN Europe NTU 2018.1" is a unicode map and works fine. So, if you create maps which contain road names containing special characters, please try how maps created with r3942 work on your device(s). I've uploaded a copy of the version here: http://files.mkgmap.org.uk/download/351/mkgmap-optimize-index-r3942.zip These are the test cases that don't work on my Oregon: Map around Copenhagen: - Search for all roads in Denmark starting with Æ (switch to Danish keyboard to be able to type that character) or Ae doesn't find any road, it should find many. - Search for other special characters like Ø works fine. - Search for all roads in city "Albertslund Kommune" lists ... Abildgården Æblets Kvt Alberts Have Alberts Vænge ... When I search for roads starting with A in Albertslund Kommune it lists only Abildgården Similar results with other searches, the device seems to stop reading the data when the first name with Æ is hit. When I search for AL (so that it doesn't read the Æ name) it lists the above roads. Don't know if I should contact Garmin ? Gerd

4 19

tags containing special character 0x7f
by Gerd Petermann 13 May '17

13 May '17

Hi all, from time to time the code in mkgmap stumbles over labels starting with 0x7f. I have no idea how mappers are able to put that into the tag value, but it happens. See for example this changeset: https://www.openstreetmap.org/changeset/45726495 I think we should remove this character from all tag values when reading the input file, like we do with repeated spaces. OK? Gerd

1 0

Search for names with special characters
by Gerd Petermann 12 May '17

12 May '17

Hi all, I am still trying to understand how the content of the SRT sub file is used by Garmin software and how it should be used by mkgmap. After two days of experimenting with a map of Denmark I finally found a way to make the characters Æ and æ findable in the device. Again, I had to remove the expand statements in cp-1252.txt and add the two characters after the line with z like below: < z,Z ; ž,Ž < æ,Æ I did not work when I added those two characters before or after or at the end of the sequence of the A variants < a,ª,A ; á,Á ; à,À ; â,Â ; å,Å ; ä,Ä ; ã,Ã Does anybody understand that and is able to explain it to me? Gerd

1 0

What should be in the global index by default?
by Gerd Petermann 10 May '17

10 May '17

Hi all, I tried to find out what must be in the index and what might help but is not strictly needed. I've tested with maps created by r3931, the maps contain 4 tiles which are ~600 km away from my location. The Oregon 600 has only its "Worldwide Autoroute DEM Basemap" in a gmapbmap.img with ~ 51Mb and my test gmapsupp.img which is about ~35 MB. My findings so far: 1) Address search (or the search for roads/crossings) doesn't work without the global index 2) In MapSource , the search function is completely disabled without the global index, but POI search works without the index in MapSource on my Oregon, and both do not seem to use the index, I see no change in speed with or without the index. 3) MapSource seems to use the gobal index to build the search dialog, POI types which are not indexed are not searchable and they also don't appear when you search for "all POI". I played with options like --x-poi-excl-index=0x2800,0x2f00-0x6700 to verify this. 4) Basecamp and Oregon show the shops Planet and Netto when I search for "net" in all shops. Mapsource shows a list box which starts with names beginning with Net (Netto,Netzwerk) followed by other entries in alphabetical order (Neubad Apotheke, Neue Apotheke). I think this means that MapSource results depend on the global index while Oregon and Basecamp work as well without it. 5) I did not see any effect when using option --make-poi-index besides the increase in size. 6) Search for POI on the device is slow with and without the index, but fast when I use the option to search near a previously found place. I assume that other devices may use the index in a different way, I can only test with the Oregon. Maybe it depends on Hardware, maybe on Firmware. Does anybody know a device which shows a different behaviour than my Oregon? Gerd

2 5

POI indexing, problem with label 0x2800
by Andrzej Popowski 02 May '17

02 May '17

Hi, POI types 0x28xx are usually treated as labels, there is no icon for these POIs, only label text. CGPSMapper doc describe these POI as "Region name". I'd like to use these POI for house numbers. Problem is, that mkgmap indexes labels! It results in big increment of img files and index file. I doubt these objects are searchable, probably all this indexing is only a waste of space. I have found code in MdrUtils.java, which adds labels to index. I think this can be removed. And maybe you can add POIs in range 0x64xx - 0x66xx, they probably are searchable. There is an increase in LBL subfile, I haven't found code responsible for this. There seems to be a section LBL5 called "POI index", maybe labels goes there too? -- Best regards, Andrzej

5 15