- mkgmap-dev - The mkgmap lists

Commit r3970: another try to improve formatting in online help
by svn commit 02 Jun '17

02 Jun '17

Version mkgmap-r3970 was committed by gerd on Fri, 02 Jun 2017 another try to improve formatting in online help http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3970

1 0

Commit r3969: try to fix formatting issues in optopns.txt
by svn commit 02 Jun '17

02 Jun '17

Version mkgmap-r3969 was committed by gerd on Fri, 02 Jun 2017 try to fix formatting issues in optopns.txt http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3969

1 0

Commit r3968: merge the optimize-index branch. This fixes some problems with address search
by svn commit 02 Jun '17

02 Jun '17

Version mkgmap-r3968 was committed by gerd on Fri, 02 Jun 2017 merge the optimize-index branch. This fixes some problems with address search and adds new options which give control the content of the index. Also, option split-name-index is no longer temporary. New options: --road-name-config=file This option handles the problem that some countries have road names which often start or end with very similar words, e.g. in France the first word is very often 'Rue', often followed by a preposition like 'de la' or 'des'. This leads to rather long road names like 'Rue de la Concorde' where only the word 'Concorde' is really interesting. In the USA, you often have names like 'West Main Street' where only the word 'Main' is important. Garmin software has some tricks to handle this problem. It allows to use special characters in the road labels which mark the beginning and end of the important part. In combinarion with option split-name-index only the words in the important part are indexed. There are two different visiual effects of this option: - On the PC, when zooming out, the name 'Rue de la Concorde' is only rendered as 'Concorde'. - The index for road names only contains the important part of the name. You can search for road name Conc to find road names like 'Rue de la Concorde'. One problem: Search for 'Rue' will not list 'Rue de la Concorde' or 'Rue du Moulin'. It may list 'Rueben Brookins Road' if that is in the map. Only MapSource shows a corresponding hint. Another effect is that the index is smaller. The option specifies the path to a file which gives the details. See comments in the sample roadNameConfig.txt for further details. --mdr7-excl This option allows to specify words which should not be in the road index. It was added before option road-name-config and is probably no longer needed. Example usage: --x-mdr7-excl="Road, Street, Straße, Weg" --mdr7-del Use this option if your style adds strings to the labels of roads which you want to see in the map but which should not appear in the result list of a road name / address search. The list is used like this: For each road label mkgmap searches the last blank. If one is found, it checks if the word after it appears in the given list. If so, the word is removed and the search is repeated. The remaining string is used to create the index. Example: Assume your style adds surface attributes like 'pav.' or 'unp.' to a road label. You can use --mdr7-del="pav.,unp." to remove these apendixes from the index. --poi-excl-index By default, mkgmap indexes the following POI types with a non-empty label: - 0x00 .. 0x0f (cities, sub type 0, type <= 0xf) - 0x2axx..0x30xx (Food & Drink, Lodging, ...) - 0x28xx (no category ?) - 0x64xx .. 0x66xx (attractions) This option allows to exclude POI types from the index. The exclueded types are not indexed, but may still be searchable on a device as some devices seem to ignore most of the index, e.g. an Oregon 600 with firmware 5.00 only seems to use it for city search. If you device finds a POI name like 'Planet' when you search for 'Net' it doesn't use the index because the index created by mkgmap cannot help for that search. So, this option may help when you care about the size of the index or the memory that is needed to calculate it. The option expects a comma separated list of types or type ranges. A range is given with from-type-to-type, e.g. 0x6400-0x6405. First and last type are both excluded.A range can span multiple types, e.g. 0x6400-0x661f. Examples for usage: - Assume your style adds a POI with type 0x2800 for each addr:housenumber. It is not useful to index those numbers, so you can use --poi-excl-index=0x2800 to exclude this. - For the mentioned Oregon you may use --poi-excl-index=0x2a00-0x661f to reduce the index size. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3968

1 0

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

01 Jun '17

OK, when I good understand there are 2 groups of options. First - there are option which must be repeat before each option input-file even if the are the same (each mapname option resets option (and styles) to defaults) Second - there are options which can (or must) be use only one time. (only question: as first or last options?) Darek W dniu 2017-06-01 20:38:36 użytkownik Gerd Petermann <GPetermann_muenchen(a)hotmail.com> napisał: > Hi Darek, > > the docu is obviously misleading, you are not the first who thinks that the options should be sorted > as listed in the docu. This is simply not the case, the docu groups the options by meaning. > The order is impportant because you can repeat options with different values. > For example, splitter generates a file template.args with repeated options like > mapname: 63240001 > # description: OSM Map > input-file: 63240001.osm.pbf > mapname: 63240002 > # description: OSM Map > input-file: 63240002.osm.pbf > ... > All options given before the input-file= 63240001.osm.pbf line are used for that file. > Next, mapname is changed, other options keep their value when > input-file= 63240002.osm.pbf is processed. > > if you start mkgmap with > java -jar mkgmap.jar -c template.args --style-file=xyz other.osm > mkgmap uses the default style for the first input-files and the style in directory xyz for the last. > This might be intended, so mkgmap doesn't complain. > There are also special cases with options like --gmapsupp or --index. > I'll try to improve docu to make that clearer. > > Reg. osmconvert: I think you can feed it with 3 osm files and the polygon file to get the merged data. Use this as input for splitter. > > Gerd > ________________________________________ > Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk> im Auftrag von d.kwapisz <d.kwapisz(a)onet.eu> > Gesendet: Donnerstag, 1. Juni 2017 20:11:42 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Problem with visibility object in Garmin img > > Hi Gerd, > Moving style-file as first line has resolved problem with use styles !!!! > > Where I can find description of property order of options? (I thought that this is order from site http://www.mkgmap.org.uk/doc/options :( /and there --input-file is before --style-file/) > > > When I've moved line: > include 'inc/water_polygons'; > include 'inc/landuse_polygons'; > > instantly after the block > > historic=museum | historic=memorial [0x1e resolution 21] > historic=archaeological_site | historic=ruins [0x1e resolution 21] > > I can see blue lake!!! > > Remain small problem with leisure = natural_rserve area, because even though change resolution form 20 to 19,18 or less the polygon is visible not until 800m zoom (maybe it is feature of 0x16 type in device) > > Thank You very very much. > > And still one question about use mkgmap. > > For example I've 3 pbf file from geofabrik.de (France, Germany and Schweiz) and one polygon wich owerlap 3 country (nearly Basel). I will make one routable map from this region (inner polygon) with possibility make route between 2 or 3 country. > > What is better metod: > 1. > > 1. using osmconvert to cut from each country tail which intersects with polygon > 2. using osmconvert to make one file from those 3 files > 3. use splitter > 4. use mkgmap > > or > 2. > > 1. using splitter split map with polygon-file option for each file > 2. using mkgmap with all files after splitting > > or maybe another method > > Best Regard > Darek > > > W dniu 2017-06-01 09:59:32 użytkownik Gerd Petermann <GPetermann_muenchen(a)hotmail.com> napisał: > > Hi Dariusz, > > > > maybe you have specified the style-file option too late. It should appear before the input-file option. > > Order of options matters! > > A simple method to verfiy that the style file is used is too make it invalid, e.g. add nonsense like > > bla bla > > as a first line in lines. This should result in a message like this: > > Error in style: Error: (lines:12): Stack size is 3 (missing or incomplete expression) > > Could not open style > > You can also add option check-style. > > The echo and echotags options write to stderr, not stdout, just in case that you redirect that file. > > > > Gerd > > > > ________________________________________ > > Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk> im Auftrag von d.kwapisz <d.kwapisz(a)onet.eu> > > Gesendet: Donnerstag, 1. Juni 2017 09:51:42 > > An: Development list for mkgmap > > Betreff: Re: [mkgmap-dev] Problem with visibility object in Garmin img > > > > Hi Gerd. > > > > > > I've copy of \examples\styles\default directory with new name (\examples\styles\greece) and I use --style-file with this new name (with . > > > > I've: > > > > 1. batch file (with absolute path to java.exe, absolute path to mkgmap.jar and absolute path to options file) > > 2. options file in which I've all options (input-file=, gmapsupp, style-file=, index,route, ...) > > 3. copy of directory. This is directory with files (not zip file) - in file ..\styles\greece\inc\water_polygons I've changed line: natural=water [0x3c resolution 18] to: natural=water {echotags "water"} [0x3c resolution 18] and in file: ..\styles\greece\polygons in line leisure=nature_reserve [0x16 resolution 20] I've changed resolution from 20 to 18. > > > > I run cmd.exe and in command window I run batch file. > > When batch file is run I don't see any line in cmd window with data from echotags (this is normal?). > > After executing batch file I have new gmapsupp.img file, but after transering him to Oregon, I don't see difference with displaying natur reserve - also is displaying from 800m. > > > > And now questions: > > How I can verify, whether mkgmap uses styles form ..\styles\Greece directory? > > > > Darek > > > > > > > > > > > > > > W dniu 2017-05-31 16:29:24 użytkownik Gerd Petermann <GPetermann_muenchen(a)hotmail.com> napisał: > > > Hi Dariusz, > > > > > > if you change the style, you should create a copy of directory default and give it a different name, e.g. c:\mystyle. > > > Next, you use option --style-file=c:\mystyle to tell mkgmap the position of the style. > > > > > > If you change the files in \examples\styles\default you still have to tell mkgmap to read that directory, else it will > > > use the files which are in the jar file. > > > > > > Gerd > > > ________________________________________ > > > Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk> im Auftrag von d.kwapisz <d.kwapisz(a)onet.eu> > > > Gesendet: Mittwoch, 31. Mai 2017 16:23:08 > > > An: Development list for mkgmap > > > Betreff: Re: [mkgmap-dev] Problem with visibility object in Garmin img > > > > > > Hi Gerd, > > > > > > unfortunately I cant verify Your suggestions, because it appears that change in style files don't influences gmapsupp.img (also I don't see in cmd window results off {echo "..."} command. > > > > > > I must more time to try. > > > > > > Best Regards > > > Darek > > > > > > > > > > > > > > > > > > W dniu 2017-05-31 08:33:37 użytkownik Gerd Petermann <GPetermann_muenchen(a)hotmail.com> napisał: > > > > Hi Dariusz, > > > > > > > > thanks for the feedback. You may also try to use a lower resolution for > > > > leisure=nature_reserve [0x16 resolution 19] > > > > if you are interested in them. > > > > > > > > To be honest, I don't understand why the default style processes water polygons > > > > so late. I think the lines > > > > > > > > include 'inc/water_polygons'; > > > > include 'inc/landuse_polygons'; > > > > > > > > should be moved instantly after the block > > > > > > > > historic=museum | historic=memorial [0x1e resolution 21] > > > > historic=archaeological_site | historic=ruins [0x1e resolution 21] > > > > > > > > Does anybody see a reason for the current order ? > > > > > > > > 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 22:49:38 > > > > An: Development list for mkgmap > > > > Betreff: Re: [mkgmap-dev] Problem with visibility object in Garmin img > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > mkgmap-dev mailing list > > > > mkgmap-dev(a)lists.mkgmap.org.uk > > > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > > > > > > > > > > > _______________________________________________ > > > mkgmap-dev mailing list > > > mkgmap-dev(a)lists.mkgmap.org.uk > > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > > > > > > _______________________________________________ > > mkgmap-dev mailing list > > mkgmap-dev(a)lists.mkgmap.org.uk > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev(a)lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >

2 1

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

01 Jun '17

Hi Gerd, Moving style-file as first line has resolved problem with use styles !!!! Where I can find description of property order of options? (I thought that this is order from site http://www.mkgmap.org.uk/doc/options :( /and there --input-file is before --style-file/) When I've moved line: include 'inc/water_polygons'; include 'inc/landuse_polygons'; instantly after the block historic=museum | historic=memorial [0x1e resolution 21] historic=archaeological_site | historic=ruins [0x1e resolution 21] I can see blue lake!!! Remain small problem with leisure = natural_rserve area, because even though change resolution form 20 to 19,18 or less the polygon is visible not until 800m zoom (maybe it is feature of 0x16 type in device) Thank You very very much. And still one question about use mkgmap. For example I've 3 pbf file from geofabrik.de (France, Germany and Schweiz) and one polygon wich owerlap 3 country (nearly Basel). I will make one routable map from this region (inner polygon) with possibility make route between 2 or 3 country. What is better metod: 1. using osmconvert to cut from each country tail which intersects with polygon using osmconvert to make one file from those 3 files use splitter use mkgmap or 2. using splitter split map with polygon-file option for each file using mkgmap with all files after splitting or maybe another method Best Regard Darek W dniu 2017-06-01 09:59:32 użytkownik Gerd Petermann <GPetermann_muenchen(a)hotmail.com> napisał: > Hi Dariusz, > > maybe you have specified the style-file option too late. It should appear before the input-file option. > Order of options matters! > A simple method to verfiy that the style file is used is too make it invalid, e.g. add nonsense like > bla bla > as a first line in lines. This should result in a message like this: > Error in style: Error: (lines:12): Stack size is 3 (missing or incomplete expression) > Could not open style > You can also add option check-style. > The echo and echotags options write to stderr, not stdout, just in case that you redirect that file. > > Gerd > > ________________________________________ > Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk> im Auftrag von d.kwapisz <d.kwapisz(a)onet.eu> > Gesendet: Donnerstag, 1. Juni 2017 09:51:42 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Problem with visibility object in Garmin img > > Hi Gerd. > > > I've copy of \examples\styles\default directory with new name (\examples\styles\greece) and I use --style-file with this new name (with . > > I've: > > 1. batch file (with absolute path to java.exe, absolute path to mkgmap.jar and absolute path to options file) > 2. options file in which I've all options (input-file=, gmapsupp, style-file=, index,route, ...) > 3. copy of directory. This is directory with files (not zip file) - in file ..\styles\greece\inc\water_polygons I've changed line: natural=water [0x3c resolution 18] to: natural=water {echotags "water"} [0x3c resolution 18] and in file: ..\styles\greece\polygons in line leisure=nature_reserve [0x16 resolution 20] I've changed resolution from 20 to 18. > > I run cmd.exe and in command window I run batch file. > When batch file is run I don't see any line in cmd window with data from echotags (this is normal?). > After executing batch file I have new gmapsupp.img file, but after transering him to Oregon, I don't see difference with displaying natur reserve - also is displaying from 800m. > > And now questions: > How I can verify, whether mkgmap uses styles form ..\styles\Greece directory? > > Darek > > > > > > > W dniu 2017-05-31 16:29:24 użytkownik Gerd Petermann <GPetermann_muenchen(a)hotmail.com> napisał: > > Hi Dariusz, > > > > if you change the style, you should create a copy of directory default and give it a different name, e.g. c:\mystyle. > > Next, you use option --style-file=c:\mystyle to tell mkgmap the position of the style. > > > > If you change the files in \examples\styles\default you still have to tell mkgmap to read that directory, else it will > > use the files which are in the jar file. > > > > Gerd > > ________________________________________ > > Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk> im Auftrag von d.kwapisz <d.kwapisz(a)onet.eu> > > Gesendet: Mittwoch, 31. Mai 2017 16:23:08 > > An: Development list for mkgmap > > Betreff: Re: [mkgmap-dev] Problem with visibility object in Garmin img > > > > Hi Gerd, > > > > unfortunately I cant verify Your suggestions, because it appears that change in style files don't influences gmapsupp.img (also I don't see in cmd window results off {echo "..."} command. > > > > I must more time to try. > > > > Best Regards > > Darek > > > > > > > > > > > > W dniu 2017-05-31 08:33:37 użytkownik Gerd Petermann <GPetermann_muenchen(a)hotmail.com> napisał: > > > Hi Dariusz, > > > > > > thanks for the feedback. You may also try to use a lower resolution for > > > leisure=nature_reserve [0x16 resolution 19] > > > if you are interested in them. > > > > > > To be honest, I don't understand why the default style processes water polygons > > > so late. I think the lines > > > > > > include 'inc/water_polygons'; > > > include 'inc/landuse_polygons'; > > > > > > should be moved instantly after the block > > > > > > historic=museum | historic=memorial [0x1e resolution 21] > > > historic=archaeological_site | historic=ruins [0x1e resolution 21] > > > > > > Does anybody see a reason for the current order ? > > > > > > 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 22:49:38 > > > An: Development list for mkgmap > > > Betreff: Re: [mkgmap-dev] Problem with visibility object in Garmin img > > > > > > 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 > > > > > > > > > > > > > > > > _______________________________________________ > > > mkgmap-dev mailing list > > > mkgmap-dev(a)lists.mkgmap.org.uk > > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > > > > > > _______________________________________________ > > mkgmap-dev mailing list > > mkgmap-dev(a)lists.mkgmap.org.uk > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev(a)lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >

2 1

WG: Please check if help is okay
by Gerd Petermann 01 Jun '17

01 Jun '17

Sorry, did not reply to list... ________________________________________ Von: Gerd Petermann Gesendet: Donnerstag, 1. Juni 2017 17:37 An: Alexandre Folle de Menezes Betreff: AW: [mkgmap-dev] Please check if help is okay Hi Alexandre, thanks, fixed the ofter typo 3 times. New text for mdr7-del in r3966: --mdr7-del Use this option if your style adds strings to the labels of roads which you want to see in the map but which should not appear in the result list of a road name / address search. The list is used like this: For each road label mkgmap searches the last blank. If one is found, it checks if the word after it appears in the given list. If so, the word is removed and the search is repeated. The remaining string is used to create the index. Example: Assume your style adds surface attributes like 'pav.' or 'unp.' to a road label. You can use --mdr7-del="pav.,unp." to remove these apendixes from the index. ciao, Gerd ________________________________________ Von: Alexandre Folle de Menezes <afmlistas(a)terra.com.br> Gesendet: Donnerstag, 1. Juni 2017 15:15:40 An: Gerd Petermann Betreff: Re: [mkgmap-dev] Please check if help is okay Hi, Great! A few suggestions: * - mispelled word "often" (marked below); * - there's an example on --mdr7-excl, which is said to be a candidate for removal, but not on --mdr7-del; Keep up with the great work! Best regards, Alexandre Em 01/06/2017 03:38, Gerd Petermann escreveu: Hi all, okay, I've now also added options --mdr7-del, --mdr7-excl, and --poi-excl-index. Option --split-name-index is no longer temporay. The corresponding part of the help now looks like this: --split-name-index An option to enable indexing each part of a street name separately. So for example if the street is "Aleksandra Gryglewskiego" then you will be able to search for it as both "Aleksandra" and "Gryglewskiego". It will also increase the size of the index. Useful in countries where searching for the first word in name is not the right thing to do. Words following an opening bracket '(' are ignored. See also option road-name-config. --road-name-config=file This option handles the problem that some countries have road names which ofter start or end with very similar words, e.g. in France the first word is very often 'Rue', ofter followed by a preposition like 'de la' or 'des'. This leads to rather long road names like 'Rue de la Concorde' where only the word 'Concorde' is really interesting. In the USA, you ofter have names like 'West Main Street' where only the word 'Main' is important. Garmin software has some tricks to handle this problem. It allows to use special characters in the road labels which mark the beginning and end of the important part. In combinarion with option split-name-index only the words in the important part are indexed. There are two different visiual effects of this option: - On the PC, when zooming out, the name 'Rue de la Concorde' is only rendered as 'Concorde'. - The index for road names only contains the important part of the name. You can search for road name Conc to find road names like 'Rue de la Concorde'. One problem: Search for 'Rue' will not list 'Rue de la Concorde' or 'Rue du Moulin'. It may list 'Rueben Brookins Road' if that is in the map. Only MapSource shows a corresponding hint. Another effect is that the index is smaller. The option specifies the path to a file which gives the details. See comments in the sample roadNameConfig.txt for further details. --mdr7-excl This option allows to specify words which should not be in the road index. It was added before option road-name-config and is probably no longer needed. Example usage: --x-mdr7-excl="Road, Street, Straße, Weg" --mdr7-del Use this option if your style adds strings to the labels of roads which you want to see in the map but which should not appear in the result list of a road name / address search. The list is used like this: For each road label mkgmap searches the last blank. If one is found, it checks if the word after it appears in the given list. If so, the word is removed and the search is repeated. The remaining string is used to create the index. --poi-excl-index By default, mkgmap indexes the following POI types with a non-empty label: - 0x00 .. 0x0f (cities, sub type 0, type <= 0xf) - 0x2axx..0x30xx (Food & Drink, Lodging, ...) - 0x28xx (no category ?) - 0x64xx .. 0x66xx (attractions) This option allows to exclude POI types from the index. The exclueded types are not indexed, but may still be searchable on a device as some devices seem to ignore most of the index, e.g. an Oregon 600 with firmware 5.00 only seems to use it for city search. If you device finds a POI name like 'Planet' when you search for 'Net' it doesn't use the index because the index created by mkgmap cannot help for that search. So, this option may help when you care about the size of the index or the memory that is needed to calculate it. The option expects a comma separated list of types or type ranges. A range is given with from-type-to-type, e.g. 0x6400-0x6405. First and last type are both excluded.A range can span multiple types, e.g. 0x6400-0x661f. Examples for usage: - Assume your style adds a POI with type 0x2800 for each addr:housenumber. It is not useful to index those numbers, so you can use --poi-excl-index=0x2800 to exclude this. - For the mentioned Oregon you may use --poi-excl-index=0x2a00-0x661f to reduce the index size. Please suggest improvements. ciao, Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen(a)hotmail.com><mailto:GPetermann_muenchen@hotmail.com> Gesendet: Mittwoch, 31. Mai 2017 18:35:36 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Please check if help is okay Hi Alexandre, thanks for the hint. The options work fine together. I'll try to make that clearer. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Alexandre Loss <alexandre.loss(a)gmail.com><mailto:alexandre.loss@gmail.com> Gesendet: Mittwoch, 31. Mai 2017 18:06:24 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Please check if help is okay Hi Gerd, it is clear your documentation for the new --road-name-config parameter. However, what is the relation or impact using this new parameter concomitantly with --x-split-name-index? Are they mutually exclusive? I suggest to clarify this in the documentation. Thanks. Regards, Alexandre 2017-05-31 4:39 GMT-03:00 Gerd Petermann <GPetermann_muenchen(a)hotmail.com<mailto:GPetermann_muenchen@hotmail.com><mailto:GPetermann_muenchen@hotmail.com><mailto:GPetermann_muenchen@hotmail.com>>: Hi all, in r3963 I tried to document the new prefix / suffix stuff: --road-name-config=file This option handles the problem that some countries have road names which ofter start or end with very similar words, e.g. in France the first word is very often 'Rue', ofter followed by a preposition like 'de la' or 'des'. This leads to rather long road names like 'Rue de la Concorde' where only the word 'Concorde' is really interesting. In the USA, you ofter have names like 'West Main Street' where only the word 'Main' is important. Garmin software has some tricks to handle this problem. It allows to use special characters in the road labels which mark the beginning and end of the important part. There are two different visiual effects of this option: - On the PC, when zooming out, the name 'Rue de la Concorde' is only rendered as 'Concorde'. - The index for road names only contains the important part of the name. You can search for road name Conc to find road names like 'Rue de la Concorde'. One problem: Search for 'Rue' will not list 'Rue de la Concorde' or 'Rue du Moulin'. It may list 'Rueben Brookins Road' if that is in the map. Another effect is that the index is smaller. The option specifies the path to a file which gives the details. See comments in the sample roadNameConfig.txt for further details. Is that clear enough? Please check also the comments in the sample file. Please suggest improvements, else I'll use the same text for the style documentation before merging to trunk. Gerd _______________________________________________ mkgmap-dev mailing list mkgmap-dev(a)lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev(a)lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev(a)lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

1 0

Please check if help is okay
by Gerd Petermann 01 Jun '17

01 Jun '17

Hi all, in r3963 I tried to document the new prefix / suffix stuff: --road-name-config=file This option handles the problem that some countries have road names which ofter start or end with very similar words, e.g. in France the first word is very often 'Rue', ofter followed by a preposition like 'de la' or 'des'. This leads to rather long road names like 'Rue de la Concorde' where only the word 'Concorde' is really interesting. In the USA, you ofter have names like 'West Main Street' where only the word 'Main' is important. Garmin software has some tricks to handle this problem. It allows to use special characters in the road labels which mark the beginning and end of the important part. There are two different visiual effects of this option: - On the PC, when zooming out, the name 'Rue de la Concorde' is only rendered as 'Concorde'. - The index for road names only contains the important part of the name. You can search for road name Conc to find road names like 'Rue de la Concorde'. One problem: Search for 'Rue' will not list 'Rue de la Concorde' or 'Rue du Moulin'. It may list 'Rueben Brookins Road' if that is in the map. Another effect is that the index is smaller. The option specifies the path to a file which gives the details. See comments in the sample roadNameConfig.txt for further details. Is that clear enough? Please check also the comments in the sample file. Please suggest improvements, else I'll use the same text for the style documentation before merging to trunk. Gerd

2 4

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

01 Jun '17

Hi Gerd. I've copy of \examples\styles\default directory with new name (\examples\styles\greece) and I use --style-file with this new name (with . I've: batch file (with absolute path to java.exe, absolute path to mkgmap.jar and absolute path to options file) options file in which I've all options (input-file=, gmapsupp, style-file=, index,route, ...) copy of directory. This is directory with files (not zip file) - in file ..\styles\greece\inc\water_polygons I've changed line: natural=water [0x3c resolution 18] to: natural=water {echotags "water"} [0x3c resolution 18] and in file: ..\styles\greece\polygons in line leisure=nature_reserve [0x16 resolution 20] I've changed resolution from 20 to 18. I run cmd.exe and in command window I run batch file. When batch file is run I don't see any line in cmd window with data from echotags (this is normal?). After executing batch file I have new gmapsupp.img file, but after transering him to Oregon, I don't see difference with displaying natur reserve - also is displaying from 800m. And now questions: How I can verify, whether mkgmap uses styles form ..\styles\Greece directory? Darek W dniu 2017-05-31 16:29:24 użytkownik Gerd Petermann <GPetermann_muenchen(a)hotmail.com> napisał: > Hi Dariusz, > > if you change the style, you should create a copy of directory default and give it a different name, e.g. c:\mystyle. > Next, you use option --style-file=c:\mystyle to tell mkgmap the position of the style. > > If you change the files in \examples\styles\default you still have to tell mkgmap to read that directory, else it will > use the files which are in the jar file. > > Gerd > ________________________________________ > Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk> im Auftrag von d.kwapisz <d.kwapisz(a)onet.eu> > Gesendet: Mittwoch, 31. Mai 2017 16:23:08 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Problem with visibility object in Garmin img > > Hi Gerd, > > unfortunately I cant verify Your suggestions, because it appears that change in style files don't influences gmapsupp.img (also I don't see in cmd window results off {echo "..."} command. > > I must more time to try. > > Best Regards > Darek > > > > > > W dniu 2017-05-31 08:33:37 użytkownik Gerd Petermann <GPetermann_muenchen(a)hotmail.com> napisał: > > Hi Dariusz, > > > > thanks for the feedback. You may also try to use a lower resolution for > > leisure=nature_reserve [0x16 resolution 19] > > if you are interested in them. > > > > To be honest, I don't understand why the default style processes water polygons > > so late. I think the lines > > > > include 'inc/water_polygons'; > > include 'inc/landuse_polygons'; > > > > should be moved instantly after the block > > > > historic=museum | historic=memorial [0x1e resolution 21] > > historic=archaeological_site | historic=ruins [0x1e resolution 21] > > > > Does anybody see a reason for the current order ? > > > > 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 22:49:38 > > An: Development list for mkgmap > > Betreff: Re: [mkgmap-dev] Problem with visibility object in Garmin img > > > > 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 > > > > > > > > > > > _______________________________________________ > > mkgmap-dev mailing list > > mkgmap-dev(a)lists.mkgmap.org.uk > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev(a)lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >

2 1

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

31 May '17

Hi Gerd, unfortunately I cant verify Your suggestions, because it appears that change in style files don't influences gmapsupp.img (also I don't see in cmd window results off {echo "..."} command. I must more time to try. Best Regards Darek W dniu 2017-05-31 08:33:37 użytkownik Gerd Petermann <GPetermann_muenchen(a)hotmail.com> napisał: > Hi Dariusz, > > thanks for the feedback. You may also try to use a lower resolution for > leisure=nature_reserve [0x16 resolution 19] > if you are interested in them. > > To be honest, I don't understand why the default style processes water polygons > so late. I think the lines > > include 'inc/water_polygons'; > include 'inc/landuse_polygons'; > > should be moved instantly after the block > > historic=museum | historic=memorial [0x1e resolution 21] > historic=archaeological_site | historic=ruins [0x1e resolution 21] > > Does anybody see a reason for the current order ? > > 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 22:49:38 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Problem with visibility object in Garmin img > > 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 > > > > > > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev(a)lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >

2 1

Re: [mkgmap-dev] Please check if help is okay
by d.kwapisz 31 May '17

31 May '17

Hi Gerd. With my very poor English, a understand this option description, except one place (I 've remarked below with rec colour) Best Regards Darek W dniu 2017-05-31 09:39:04 użytkownik Gerd Petermann <GPetermann_muenchen(a)hotmail.com> napisał: > Hi all, > > in r3963 I tried to document the new prefix / suffix stuff: > --road-name-config=file > This option handles the problem that some countries have road names which > ofter start or end with very similar words, e.g. in France the first word > is very often 'Rue', ofter followed by a preposition like 'de la' or 'des'. > This leads to rather long road names like 'Rue de la Concorde' where only > the word 'Concorde' is really interesting. In the USA, you ofter have names > like 'West Main Street' where only the word 'Main' is important. > Garmin software has some tricks to handle this problem. It allows to use > special characters in the road labels which mark the beginning and end of > the important part. > There are two different visiual effects of this option: > - On the PC, when zooming out, the name 'Rue de la Concorde' is only > rendered as 'Concorde'. > - The index for road names only contains the important part of the name. > You can search for road name Conc to find road names like 'Rue de la Concorde'. > One problem: Search for 'Rue' will not list 'Rue de la Concorde' > or 'Rue du Moulin'. It may list 'Rueben Brookins Road' if that is in the map.(first point concern display on PC, this point (second) also or with index problem is on Garmin unit?) > > Another effect is that the index is smaller. > > The option specifies the path to a file which gives the details. See > comments in the sample roadNameConfig.txt for further details. > > Is that clear enough? Please check also the comments in the sample file. > Please suggest improvements, else I'll use the same text for the style documentation before > merging to trunk. > > Gerd > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev(a)lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >

2 1