- mkgmap-dev - The mkgmap lists

Re: [mkgmap-dev] Problem with visibility object in Garmin img
by d.kwapisz 31 May '17

31 May '17

Hi Gerd, Really, I can see nature_reserve from zoom 800m. ThankYou (Sorry my fault). Tomorrow I tray change style for tourism=attraction and natural=water. Darek W dniu 2017-05-30 15:01:20 użytkownik Gerd Petermann <GPetermann_muenchen(a)hotmail.com> napisał: > Hi Dariusz, > > you should see the two leisure=nature_reserve polygons as green areas if you zoom in to 800m . > The water polygon is also tagged as tourism=attraction and it seems that the default style > renders this as 0x1f which is also a kind of park and therefore also rendered as green. > > Does that help? > > Gerd > > ________________________________________ > Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk> im Auftrag von d.kwapisz <d.kwapisz(a)onet.eu> > Gesendet: Dienstag, 30. Mai 2017 14:24:08 > An: mkgmap-dev(a)lists.mkgmap.org.uk > Betreff: [mkgmap-dev] Problem with visibility object in Garmin img > > Hi, > > I've load from OSM rectangle > bbox=24.061,35.2895,24.2976,35.4638 > using Overpass API export. > > (this is part of Greece > Crete) > > There are among other things 2 polygons nature_reserve (140514809 and 140515050) and polygon natural water (356673828). > > I use the newest mkgmap 3909 (Windows 10). > > After using mkgmap with option file: > > family-name=fam-name-kreta > gmapsupp > output-dir=D:\Dokumenty\OSM\ttt\ > description=descr-kreta > unicode > index > route > precomp-sea=C:\Users\Darek\Downloads\sea.zip > generate-sea > order-by-decreasing-area > mapname: 63240001 > input-file: map.osm > > > After generating gmapsupp.img and transferring to Orgeon 650 unfortunately I don't see neither polygons (140514809 and 140515050) nor polygon (356673828). > > > What I do wrong? > > Best Regards > Dariusz Kwapisz > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev(a)lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >

2 1

Problem with visibility object in Garmin img
by d.kwapisz 30 May '17

30 May '17

Hi, I've load from OSM rectangle bbox=24.061,35.2895,24.2976,35.4638 using Overpass API export. (this is part of Greece > Crete) There are among other things 2 polygons nature_reserve (140514809 and 140515050) and polygon natural water (356673828). I use the newest mkgmap 3909 (Windows 10). After using mkgmap with option file: family-name=fam-name-kreta gmapsupp output-dir=D:\Dokumenty\OSM\ttt\ description=descr-kreta unicode index route precomp-sea=C:\Users\Darek\Downloads\sea.zip generate-sea order-by-decreasing-area mapname: 63240001 input-file: map.osm After generating gmapsupp.img and transferring to Orgeon 650 unfortunately I don't see neither polygons (140514809 and 140515050) nor polygon (356673828). What I do wrong? Best Regards Dariusz Kwapisz

2 1

mkgmap r3961 : new option --x-road-name-config
by Gerd Petermann 29 May '17

29 May '17

Hi all, see also http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2017q2/026649.html I've now implemented a first version of a user interface for the prefix / suffix filter in r3961. A sample configuration file is in examples\roadNameConfig.txt . Use it with --x-road-name-config=roadNameConfig.txt The option is not yet documented because I am not sure if we need more. I thought about adding the file to the default style but decided against it because the filter is used after all style processing and housenumber matching, so it is not really a style. Another reason is that the code for the style reader is quite complex ;-) This is the last new feature in the branch, I only plan to add documentation and fix errors during the next days and merge to trunk on friday. Reg. the problems with address search in --unicode maps: I've fixed a few more small issues but I no longer have a Nüvi for testing. I fear it still doesn't work with unicode maps. On my Oregon I still see the same problems, names with special characters are not found - Töpferweg is not found when typing "Tö" or "Töpf", but it is listed with "To" or "Topf" - Search for "A" gives incomplete result when list contains names starting with "Æ" . I assume this might be fixed with changes in the file cp65001.txt Please report if you see better results with your style / device. Gerd

1 0

style-manual.pdf
by Eugeny_B 28 May '17

28 May '17

Error in style-manual.pdf str.23 - 24 -- View this message in context: http://gis.19327.n8.nabble.com/style-manual-pdf-tp5897015.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

2 3

r3948 in the optimize-index branch
by Gerd Petermann 23 May '17

23 May '17

Hi all, I've decided to change the files cp-1252.txt and cp-1254.txt to fix the search problems with special characters. The nordish characters æ and Æ are now treated like ä and Ä. The french characters œ and Œ are now treated like ö and Ö. In cp-1252 the german character ß is sorted after s. This is only relevant when using the lower-case option, else the character is replaced by SS. I hope this works for other devices, too. Let me know if I should create another test map. I tried to use the same "tricks" for the --unicode option (cp-65001.txt), but that did not work on my Oregon, means, I still saw the same problems :-( I assume I should also change the other "normal" code pages like cp-1250 and cp-1257 ? Gerd

1 0

Is there a mkgmap option to replace Areas with Pois? using -add-pois-to-areas but duplicating NAME
by greg crago 18 May '17

18 May '17

I am trying to display Custom Symbols for Fast Food stores: example https://www.openstreetmap.org/edit#map=20/42.19977/-83.70034 Using -add-pois-to-areas and also using EXTENDED LABELS=NOLABEL, but I can still see a label on my GPS overtop of my Custom Symbol. Used GPSMapEdit and I can see Polygon 0x08 for the BUILDING and NAME=Burger King. Also see POINT 0x6016 (My Burger King icon) and NAME=Burger King. Since I am using EXTENDED LABELS=NOLABEL, I think I am blocking the NAME on the Point, but the Polygon 0x08 still has a NAME defined and I think I am seeing it on my GPS Would like to know if there is a different option to REPLACE AREA with POI and then I would not have the original polygon and Point.. Greg

2 1

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 18 May '17

18 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