Sample basic mkgmap config file
Hi all, here is my proposal for a file which should be good for every new user. I plan to add it to the examples directory in the distributed zip. Please suggest improvements if you miss something really important. I started to write a HOWTO but got stuck because it is so difficult to handle the differences between Windows/Linux/Mac and the usage of relative or absolute paths. I've recently learned that new users might not even know how to copy a file into a hidden directory like C:\ProgramData. I know that some of you distribute packages containing styles and scripts but I think they all work either only on Windows or on Linux or they require further packages like pearl. Correct me if I'm wrong. No idea how to continue here :( Gerd
Hi Gerd, maybe treat it like default style, which is kind of build in? For example, when invoking mkgmap with an option --recommended, mkgmap could include all options from default config. -- Best regards, Andrzej
Hi I have a few suggestions / comments: I don't agree with --recommended because this file will often required some tweaking and eventually become the basis of the new users building environment. I think forward slash (/) works as a directory seperator on DOS/Windows so can always use this. It should be written to assume various items are in the current directory, including the .cfg file itself, the outputs from splitter, bounds.zip, sea.zip and mkgmap release subdirectory It should be aimed at generating a GMAPSUPP.IMG file to put on a Garmin device. All the PC bits for basecamp/mapsource are a distraction and a great deal of time can be wasted trying to get these installed on a PC and then trying to use them install the map image on a device; so shouldn't have 'gmapi' and should have 'no-tdbfile' Should specify: code-page=1252 I'm not convinced of the general benefits of 'split-name-index' and 'road-name-config'. They don't give good behaviour for the UK The 'bounds' option to location-autofill doesn't do anything No need to specify the style - it will use 'default' name-tag-list=name:XX,int_name,name,place_name,loc_name is a useful option where XX is the map user's language code Should specify: route I don't think 'check-roundabouts' is of any benefit for a new user Option 'add-pois-to-lines' generates a lot of 'not very useful' POIs and I think it is better turned off. This is a topic that could be re -visited in 'default style improvements' 'make-opposite-cycleways' is wrong for a lot of countries I'd specify: 'order-by-decreasing-area' as the way to get a map that shows polygon features overlayed in the best order, without having to make fixed arbitrary decisions about all the [_drawOrder] levels in a typ-file. Following, inline, is a version with some changes - feel free to take/ignore whatever you think is best. It should probably be more heavily commented. Regards Ticker # # Set options to create a routable map for a Garmin GPS # Assumes that the files bounds.zip and sea.zip exist # gmapsupp code-page=1252 no-tdbfile nsis index #split-name-index #road-name-config=mkgmap/examples/roadNameConfig.txt bounds=bounds.zip location-autofill=is_in,nearest housenumbers #name-tag-list=name:en,int_name,name,place_name,loc_name max-jobs route drive-on=detect no-add-pois-to-lines add-pois-to-areas precomp-sea=sea.zip #make-opposite-cycleways link-pois-to-ways process-destination process-exits order-by-decreasing-area #that's it On Thu, 2019-02-14 at 14:29 +0100, Andrzej Popowski wrote:
Hi Gerd,
maybe treat it like default style, which is kind of build in? For example, when invoking mkgmap with an option --recommended, mkgmap could include all options from default config.
Hi Ticker, thanks for the comments. - I forgot route, that was not intended. - no-tdbfile and nsis are a bad combination, and I see no problem when we generate all possible formats unless one starts to create really large maps. - I am not aware of problems with --split-name-index or --road-name-config, please give examples in a new thread. Besides that I see no problems to remove those. - I agree that --add-pois-to-lines is a rather problematic option, but I see no need to add no-add-pois-to-lines - My understanding is that we don't need order-by-decreasing-area once we have a default typ? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 14. Februar 2019 18:19 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Sample basic mkgmap config file Hi I have a few suggestions / comments: I don't agree with --recommended because this file will often required some tweaking and eventually become the basis of the new users building environment. I think forward slash (/) works as a directory seperator on DOS/Windows so can always use this. It should be written to assume various items are in the current directory, including the .cfg file itself, the outputs from splitter, bounds.zip, sea.zip and mkgmap release subdirectory It should be aimed at generating a GMAPSUPP.IMG file to put on a Garmin device. All the PC bits for basecamp/mapsource are a distraction and a great deal of time can be wasted trying to get these installed on a PC and then trying to use them install the map image on a device; so shouldn't have 'gmapi' and should have 'no-tdbfile' Should specify: code-page=1252 I'm not convinced of the general benefits of 'split-name-index' and 'road-name-config'. They don't give good behaviour for the UK The 'bounds' option to location-autofill doesn't do anything No need to specify the style - it will use 'default' name-tag-list=name:XX,int_name,name,place_name,loc_name is a useful option where XX is the map user's language code Should specify: route I don't think 'check-roundabouts' is of any benefit for a new user Option 'add-pois-to-lines' generates a lot of 'not very useful' POIs and I think it is better turned off. This is a topic that could be re -visited in 'default style improvements' 'make-opposite-cycleways' is wrong for a lot of countries I'd specify: 'order-by-decreasing-area' as the way to get a map that shows polygon features overlayed in the best order, without having to make fixed arbitrary decisions about all the [_drawOrder] levels in a typ-file. Following, inline, is a version with some changes - feel free to take/ignore whatever you think is best. It should probably be more heavily commented. Regards Ticker # # Set options to create a routable map for a Garmin GPS # Assumes that the files bounds.zip and sea.zip exist # gmapsupp code-page=1252 no-tdbfile nsis index #split-name-index #road-name-config=mkgmap/examples/roadNameConfig.txt bounds=bounds.zip location-autofill=is_in,nearest housenumbers #name-tag-list=name:en,int_name,name,place_name,loc_name max-jobs route drive-on=detect no-add-pois-to-lines add-pois-to-areas precomp-sea=sea.zip #make-opposite-cycleways link-pois-to-ways process-destination process-exits order-by-decreasing-area #that's it On Thu, 2019-02-14 at 14:29 +0100, Andrzej Popowski wrote:
Hi Gerd,
maybe treat it like default style, which is kind of build in? For example, when invoking mkgmap with an option --recommended, mkgmap could include all options from default config.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd --split-name-index and --road-name-config behave as expected, but: UK roads are always indexed by their first word, even when the word is 'The'. Removing all the common suffixes (road/street/etc) to the second stage of address searching just makes finding an address awkward and unnatural. It is normal to select the full street in 1 stage then the locations within the street in the next stage. My opinion is that using --order-by-decreasing-area and then, if you have a typ-file, setting all [_drawOrder] to the same value, gives a good map, whereas attempting to pre-define which polygons overwrite others using [_drawOrder] will be wrong in some cases. Ticker On Thu, 2019-02-14 at 17:35 +0000, Gerd Petermann wrote:
Hi Ticker,
thanks for the comments. - I forgot route, that was not intended. - no-tdbfile and nsis are a bad combination, and I see no problem when we generate all possible formats unless one starts to create really large maps. - I am not aware of problems with --split-name-index or --road-name -config, please give examples in a new thread. Besides that I see no problems to remove those. - I agree that --add-pois-to-lines is a rather problematic option, but I see no need to add no-add-pois-to-lines - My understanding is that we don't need order-by-decreasing-area once we have a default typ?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 14. Februar 2019 18:19 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Sample basic mkgmap config file
Hi
I have a few suggestions / comments:
I don't agree with --recommended because this file will often required some tweaking and eventually become the basis of the new users building environment.
I think forward slash (/) works as a directory seperator on DOS/Windows so can always use this.
It should be written to assume various items are in the current directory, including the .cfg file itself, the outputs from splitter, bounds.zip, sea.zip and mkgmap release subdirectory
It should be aimed at generating a GMAPSUPP.IMG file to put on a Garmin device. All the PC bits for basecamp/mapsource are a distraction and a great deal of time can be wasted trying to get these installed on a PC and then trying to use them install the map image on a device; so shouldn't have 'gmapi' and should have 'no-tdbfile'
Should specify: code-page=1252
I'm not convinced of the general benefits of 'split-name-index' and 'road-name-config'. They don't give good behaviour for the UK
The 'bounds' option to location-autofill doesn't do anything
No need to specify the style - it will use 'default'
name-tag-list=name:XX,int_name,name,place_name,loc_name is a useful option where XX is the map user's language code
Should specify: route
I don't think 'check-roundabouts' is of any benefit for a new user
Option 'add-pois-to-lines' generates a lot of 'not very useful' POIs and I think it is better turned off. This is a topic that could be re -visited in 'default style improvements'
'make-opposite-cycleways' is wrong for a lot of countries
I'd specify: 'order-by-decreasing-area' as the way to get a map that shows polygon features overlayed in the best order, without having to make fixed arbitrary decisions about all the [_drawOrder] levels in a typ-file.
Following, inline, is a version with some changes - feel free to take/ignore whatever you think is best. It should probably be more heavily commented.
Regards Ticker
# # Set options to create a routable map for a Garmin GPS # Assumes that the files bounds.zip and sea.zip exist # gmapsupp code-page=1252 no-tdbfile nsis index #split-name-index #road-name-config=mkgmap/examples/roadNameConfig.txt bounds=bounds.zip location-autofill=is_in,nearest housenumbers #name-tag-list=name:en,int_name,name,place_name,loc_name max-jobs route drive-on=detect no-add-pois-to-lines add-pois-to-areas precomp-sea=sea.zip #make-opposite-cycleways link-pois-to-ways process-destination process-exits order-by-decreasing-area
#that's it
On Thu, 2019-02-14 at 14:29 +0100, Andrzej Popowski wrote:
Hi Gerd,
maybe treat it like default style, which is kind of build in? For example, when invoking mkgmap with an option --recommended, mkgmap could include all options from default config.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Ticker, I don't understand what you mean with "Removing all the common suffixes (road/street/etc) to the second stage of address searching just makes finding an address awkward and unnatural. It is normal to select the full street in 1 stage then the locations within the street in the next stage." Is that something that you do in your style? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 19. Februar 2019 12:32 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Sample basic mkgmap config file Hi Gerd --split-name-index and --road-name-config behave as expected, but: UK roads are always indexed by their first word, even when the word is 'The'. Removing all the common suffixes (road/street/etc) to the second stage of address searching just makes finding an address awkward and unnatural. It is normal to select the full street in 1 stage then the locations within the street in the next stage. My opinion is that using --order-by-decreasing-area and then, if you have a typ-file, setting all [_drawOrder] to the same value, gives a good map, whereas attempting to pre-define which polygons overwrite others using [_drawOrder] will be wrong in some cases. Ticker On Thu, 2019-02-14 at 17:35 +0000, Gerd Petermann wrote:
Hi Ticker,
thanks for the comments. - I forgot route, that was not intended. - no-tdbfile and nsis are a bad combination, and I see no problem when we generate all possible formats unless one starts to create really large maps. - I am not aware of problems with --split-name-index or --road-name -config, please give examples in a new thread. Besides that I see no problems to remove those. - I agree that --add-pois-to-lines is a rather problematic option, but I see no need to add no-add-pois-to-lines - My understanding is that we don't need order-by-decreasing-area once we have a default typ?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 14. Februar 2019 18:19 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Sample basic mkgmap config file
Hi
I have a few suggestions / comments:
I don't agree with --recommended because this file will often required some tweaking and eventually become the basis of the new users building environment.
I think forward slash (/) works as a directory seperator on DOS/Windows so can always use this.
It should be written to assume various items are in the current directory, including the .cfg file itself, the outputs from splitter, bounds.zip, sea.zip and mkgmap release subdirectory
It should be aimed at generating a GMAPSUPP.IMG file to put on a Garmin device. All the PC bits for basecamp/mapsource are a distraction and a great deal of time can be wasted trying to get these installed on a PC and then trying to use them install the map image on a device; so shouldn't have 'gmapi' and should have 'no-tdbfile'
Should specify: code-page=1252
I'm not convinced of the general benefits of 'split-name-index' and 'road-name-config'. They don't give good behaviour for the UK
The 'bounds' option to location-autofill doesn't do anything
No need to specify the style - it will use 'default'
name-tag-list=name:XX,int_name,name,place_name,loc_name is a useful option where XX is the map user's language code
Should specify: route
I don't think 'check-roundabouts' is of any benefit for a new user
Option 'add-pois-to-lines' generates a lot of 'not very useful' POIs and I think it is better turned off. This is a topic that could be re -visited in 'default style improvements'
'make-opposite-cycleways' is wrong for a lot of countries
I'd specify: 'order-by-decreasing-area' as the way to get a map that shows polygon features overlayed in the best order, without having to make fixed arbitrary decisions about all the [_drawOrder] levels in a typ-file.
Following, inline, is a version with some changes - feel free to take/ignore whatever you think is best. It should probably be more heavily commented.
Regards Ticker
# # Set options to create a routable map for a Garmin GPS # Assumes that the files bounds.zip and sea.zip exist # gmapsupp code-page=1252 no-tdbfile nsis index #split-name-index #road-name-config=mkgmap/examples/roadNameConfig.txt bounds=bounds.zip location-autofill=is_in,nearest housenumbers #name-tag-list=name:en,int_name,name,place_name,loc_name max-jobs route drive-on=detect no-add-pois-to-lines add-pois-to-areas precomp-sea=sea.zip #make-opposite-cycleways link-pois-to-ways process-destination process-exits order-by-decreasing-area
#that's it
On Thu, 2019-02-14 at 14:29 +0100, Andrzej Popowski wrote:
Hi Gerd,
maybe treat it like default style, which is kind of build in? For example, when invoking mkgmap with an option --recommended, mkgmap could include all options from default config.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd I experimented with --road-name-config=../roadNameConfig.txt just after it was committed to trunk a few months ago, using my old eTrex Legend HCx. Nothing strange in my style. roadNameConfig.txt included: # english #no prefix1:en = "East ", "North ", "South ", "West " suffix:en = " Avenue", " Close", " Court", " Crescent", " Drive", "Gardens", " Gate", " Grove", " Lane", " Mews", " Parade", " Park", "Passage", " Place", " Rise", " Road", " Square", " Street", "Terrace", " View", " Walk", " Way", " Yard" ... lang:GBR = en Around where I live there are "Xx Road", "Xx Avenue", "Xx Close", "Xx Mews" and "Xx Way" Doing Find > Address, I select the "Region" (=country), enter the "City" and, into the "Street" field, enter "X" and it shows the list of matching streets, just "Xx". Then entering a "Number" (or clearing the Number field to show all addresses in the street) it shows, in a single list, all the matching addresses in Xx Road, Avenue, Close, Mews and Way. It is much quicker and I consider it more natural, to select the particular Street in the "Street" stage (from the small, presented list of 5 in this case) and then be shown the matching addresses in just this street. Does this make sense? Ticker On Tue, 2019-02-19 at 17:26 +0000, Gerd Petermann wrote:
Hi Ticker,
I don't understand what you mean with "Removing all the common suffixes (road/street/etc) to the second stage of address searching just makes finding an address awkward and unnatural. It is normal to select the full street in 1 stage then the locations within the street in the next stage." Is that something that you do in your style?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 19. Februar 2019 12:32 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Sample basic mkgmap config file
Hi Gerd
--split-name-index and --road-name-config behave as expected, but:
UK roads are always indexed by their first word, even when the word is 'The'.
Removing all the common suffixes (road/street/etc) to the second stage of address searching just makes finding an address awkward and unnatural. It is normal to select the full street in 1 stage then the locations within the street in the next stage.
My opinion is that using --order-by-decreasing-area and then, if you have a typ-file, setting all [_drawOrder] to the same value, gives a good map, whereas attempting to pre-define which polygons overwrite others using [_drawOrder] will be wrong in some cases.
Ticker
On Thu, 2019-02-14 at 17:35 +0000, Gerd Petermann wrote:
Hi Ticker,
thanks for the comments. - I forgot route, that was not intended. - no-tdbfile and nsis are a bad combination, and I see no problem when we generate all possible formats unless one starts to create really large maps. - I am not aware of problems with --split-name-index or --road-name -config, please give examples in a new thread. Besides that I see no problems to remove those. - I agree that --add-pois-to-lines is a rather problematic option, but I see no need to add no-add-pois-to-lines - My understanding is that we don't need order-by-decreasing-area once we have a default typ?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 14. Februar 2019 18:19 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Sample basic mkgmap config file
Hi
I have a few suggestions / comments:
I don't agree with --recommended because this file will often required some tweaking and eventually become the basis of the new users building environment.
I think forward slash (/) works as a directory seperator on DOS/Windows so can always use this.
It should be written to assume various items are in the current directory, including the .cfg file itself, the outputs from splitter, bounds.zip, sea.zip and mkgmap release subdirectory
It should be aimed at generating a GMAPSUPP.IMG file to put on a Garmin device. All the PC bits for basecamp/mapsource are a distraction and a great deal of time can be wasted trying to get these installed on a PC and then trying to use them install the map image on a device; so shouldn't have 'gmapi' and should have 'no-tdbfile'
Should specify: code-page=1252
I'm not convinced of the general benefits of 'split-name-index' and 'road-name-config'. They don't give good behaviour for the UK
The 'bounds' option to location-autofill doesn't do anything
No need to specify the style - it will use 'default'
name-tag-list=name:XX,int_name,name,place_name,loc_name is a useful option where XX is the map user's language code
Should specify: route
I don't think 'check-roundabouts' is of any benefit for a new user
Option 'add-pois-to-lines' generates a lot of 'not very useful' POIs and I think it is better turned off. This is a topic that could be re -visited in 'default style improvements'
'make-opposite-cycleways' is wrong for a lot of countries
I'd specify: 'order-by-decreasing-area' as the way to get a map that shows polygon features overlayed in the best order, without having to make fixed arbitrary decisions about all the [_drawOrder] levels in a typ-file.
Following, inline, is a version with some changes - feel free to take/ignore whatever you think is best. It should probably be more heavily commented.
Regards Ticker
# # Set options to create a routable map for a Garmin GPS # Assumes that the files bounds.zip and sea.zip exist # gmapsupp code-page=1252 no-tdbfile nsis index #split-name-index #road-name-config=mkgmap/examples/roadNameConfig.txt bounds=bounds.zip location-autofill=is_in,nearest housenumbers #name-tag-list=name:en,int_name,name,place_name,loc_name max-jobs route drive-on=detect no-add-pois-to-lines add-pois-to-areas precomp-sea=sea.zip #make-opposite-cycleways link-pois-to-ways process-destination process-exits order-by-decreasing-area
#that's it
On Thu, 2019-02-14 at 14:29 +0100, Andrzej Popowski wrote:
Hi Gerd,
maybe treat it like default style, which is kind of build in? For example, when invoking mkgmap with an option --recommended, mkgmap could include all options from default config.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
What you describe would be an error in my understanding. Can you still reproduce it? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 19. Februar 2019 19:06 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Sample basic mkgmap config file Hi Gerd I experimented with --road-name-config=../roadNameConfig.txt just after it was committed to trunk a few months ago, using my old eTrex Legend HCx. Nothing strange in my style. roadNameConfig.txt included: # english #no prefix1:en = "East ", "North ", "South ", "West " suffix:en = " Avenue", " Close", " Court", " Crescent", " Drive", "Gardens", " Gate", " Grove", " Lane", " Mews", " Parade", " Park", "Passage", " Place", " Rise", " Road", " Square", " Street", "Terrace", " View", " Walk", " Way", " Yard" ... lang:GBR = en Around where I live there are "Xx Road", "Xx Avenue", "Xx Close", "Xx Mews" and "Xx Way" Doing Find > Address, I select the "Region" (=country), enter the "City" and, into the "Street" field, enter "X" and it shows the list of matching streets, just "Xx". Then entering a "Number" (or clearing the Number field to show all addresses in the street) it shows, in a single list, all the matching addresses in Xx Road, Avenue, Close, Mews and Way. It is much quicker and I consider it more natural, to select the particular Street in the "Street" stage (from the small, presented list of 5 in this case) and then be shown the matching addresses in just this street. Does this make sense? Ticker On Tue, 2019-02-19 at 17:26 +0000, Gerd Petermann wrote:
Hi Ticker,
I don't understand what you mean with "Removing all the common suffixes (road/street/etc) to the second stage of address searching just makes finding an address awkward and unnatural. It is normal to select the full street in 1 stage then the locations within the street in the next stage." Is that something that you do in your style?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 19. Februar 2019 12:32 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Sample basic mkgmap config file
Hi Gerd
--split-name-index and --road-name-config behave as expected, but:
UK roads are always indexed by their first word, even when the word is 'The'.
Removing all the common suffixes (road/street/etc) to the second stage of address searching just makes finding an address awkward and unnatural. It is normal to select the full street in 1 stage then the locations within the street in the next stage.
My opinion is that using --order-by-decreasing-area and then, if you have a typ-file, setting all [_drawOrder] to the same value, gives a good map, whereas attempting to pre-define which polygons overwrite others using [_drawOrder] will be wrong in some cases.
Ticker
On Thu, 2019-02-14 at 17:35 +0000, Gerd Petermann wrote:
Hi Ticker,
thanks for the comments. - I forgot route, that was not intended. - no-tdbfile and nsis are a bad combination, and I see no problem when we generate all possible formats unless one starts to create really large maps. - I am not aware of problems with --split-name-index or --road-name -config, please give examples in a new thread. Besides that I see no problems to remove those. - I agree that --add-pois-to-lines is a rather problematic option, but I see no need to add no-add-pois-to-lines - My understanding is that we don't need order-by-decreasing-area once we have a default typ?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 14. Februar 2019 18:19 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Sample basic mkgmap config file
Hi
I have a few suggestions / comments:
I don't agree with --recommended because this file will often required some tweaking and eventually become the basis of the new users building environment.
I think forward slash (/) works as a directory seperator on DOS/Windows so can always use this.
It should be written to assume various items are in the current directory, including the .cfg file itself, the outputs from splitter, bounds.zip, sea.zip and mkgmap release subdirectory
It should be aimed at generating a GMAPSUPP.IMG file to put on a Garmin device. All the PC bits for basecamp/mapsource are a distraction and a great deal of time can be wasted trying to get these installed on a PC and then trying to use them install the map image on a device; so shouldn't have 'gmapi' and should have 'no-tdbfile'
Should specify: code-page=1252
I'm not convinced of the general benefits of 'split-name-index' and 'road-name-config'. They don't give good behaviour for the UK
The 'bounds' option to location-autofill doesn't do anything
No need to specify the style - it will use 'default'
name-tag-list=name:XX,int_name,name,place_name,loc_name is a useful option where XX is the map user's language code
Should specify: route
I don't think 'check-roundabouts' is of any benefit for a new user
Option 'add-pois-to-lines' generates a lot of 'not very useful' POIs and I think it is better turned off. This is a topic that could be re -visited in 'default style improvements'
'make-opposite-cycleways' is wrong for a lot of countries
I'd specify: 'order-by-decreasing-area' as the way to get a map that shows polygon features overlayed in the best order, without having to make fixed arbitrary decisions about all the [_drawOrder] levels in a typ-file.
Following, inline, is a version with some changes - feel free to take/ignore whatever you think is best. It should probably be more heavily commented.
Regards Ticker
# # Set options to create a routable map for a Garmin GPS # Assumes that the files bounds.zip and sea.zip exist # gmapsupp code-page=1252 no-tdbfile nsis index #split-name-index #road-name-config=mkgmap/examples/roadNameConfig.txt bounds=bounds.zip location-autofill=is_in,nearest housenumbers #name-tag-list=name:en,int_name,name,place_name,loc_name max-jobs route drive-on=detect no-add-pois-to-lines add-pois-to-areas precomp-sea=sea.zip #make-opposite-cycleways link-pois-to-ways process-destination process-exits order-by-decreasing-area
#that's it
On Thu, 2019-02-14 at 14:29 +0100, Andrzej Popowski wrote:
Hi Gerd,
maybe treat it like default style, which is kind of build in? For example, when invoking mkgmap with an option --recommended, mkgmap could include all options from default config.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd I've just built a map with --split-name-index and --road-name-config as below, using latest trunk. On my old eTrex Legend, I still get the behaviour as described earlier. I didn't use --split-name-index before, but it seems to behave as expected - all words except the suffix words are in the street list and can be found quickly and the result list then shows the full name. On my new eTrex 30x the behaviour is slightly different and worse. In the example from before, if I enter 'Xx' into the Street part of the address search, the selection list shows just "Xx Avenue". If I select this, the result list shows all addresses in Xx Avenue/Close/Way... I don't think this is relevant, but none of these streets have house number information and I've used option --no-housenumbers. The result list has 1 entry per street. Regards Ticker On Tue, 2019-02-19 at 18:21 +0000, Gerd Petermann wrote:
What you describe would be an error in my understanding. Can you still reproduce it?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 19. Februar 2019 19:06 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Sample basic mkgmap config file
Hi Gerd
I experimented with --road-name-config=../roadNameConfig.txt just after it was committed to trunk a few months ago, using my old eTrex Legend HCx. Nothing strange in my style.
roadNameConfig.txt included:
# english #no prefix1:en = "East ", "North ", "South ", "West " suffix:en = " Avenue", " Close", " Court", " Crescent", " Drive", "Gardens", " Gate", " Grove", " Lane", " Mews", " Parade", " Park", "Passage", " Place", " Rise", " Road", " Square", " Street", "Terrace", " View", " Walk", " Way", " Yard" ... lang:GBR = en
Around where I live there are "Xx Road", "Xx Avenue", "Xx Close", "Xx Mews" and "Xx Way"
Doing Find > Address, I select the "Region" (=country), enter the "City" and, into the "Street" field, enter "X" and it shows the list of matching streets, just "Xx". Then entering a "Number" (or clearing the Number field to show all addresses in the street) it shows, in a single list, all the matching addresses in Xx Road, Avenue, Close, Mews and Way.
It is much quicker and I consider it more natural, to select the particular Street in the "Street" stage (from the small, presented list of 5 in this case) and then be shown the matching addresses in just this street.
Does this make sense?
Ticker
On Tue, 2019-02-19 at 17:26 +0000, Gerd Petermann wrote:
Hi Ticker,
I don't understand what you mean with "Removing all the common suffixes (road/street/etc) to the second stage of address searching just makes finding an address awkward and unnatural. It is normal to select the full street in 1 stage then the locations within the street in the next stage." Is that something that you do in your style?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 19. Februar 2019 12:32 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Sample basic mkgmap config file
Hi Gerd
--split-name-index and --road-name-config behave as expected, but:
UK roads are always indexed by their first word, even when the word is 'The'.
Removing all the common suffixes (road/street/etc) to the second stage of address searching just makes finding an address awkward and unnatural. It is normal to select the full street in 1 stage then the locations within the street in the next stage.
My opinion is that using --order-by-decreasing-area and then, if you have a typ-file, setting all [_drawOrder] to the same value, gives a good map, whereas attempting to pre-define which polygons overwrite others using [_drawOrder] will be wrong in some cases.
Ticker
On Thu, 2019-02-14 at 17:35 +0000, Gerd Petermann wrote:
Hi Ticker,
thanks for the comments. - I forgot route, that was not intended. - no-tdbfile and nsis are a bad combination, and I see no problem when we generate all possible formats unless one starts to create really large maps. - I am not aware of problems with --split-name-index or --road -name -config, please give examples in a new thread. Besides that I see no problems to remove those. - I agree that --add-pois-to-lines is a rather problematic option, but I see no need to add no-add-pois-to-lines - My understanding is that we don't need order-by-decreasing-area once we have a default typ?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 14. Februar 2019 18:19 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Sample basic mkgmap config file
Hi
I have a few suggestions / comments:
I don't agree with --recommended because this file will often required some tweaking and eventually become the basis of the new users building environment.
I think forward slash (/) works as a directory seperator on DOS/Windows so can always use this.
It should be written to assume various items are in the current directory, including the .cfg file itself, the outputs from splitter, bounds.zip, sea.zip and mkgmap release subdirectory
It should be aimed at generating a GMAPSUPP.IMG file to put on a Garmin device. All the PC bits for basecamp/mapsource are a distraction and a great deal of time can be wasted trying to get these installed on a PC and then trying to use them install the map image on a device; so shouldn't have 'gmapi' and should have 'no-tdbfile'
Should specify: code-page=1252
I'm not convinced of the general benefits of 'split-name-index' and 'road-name-config'. They don't give good behaviour for the UK
The 'bounds' option to location-autofill doesn't do anything
No need to specify the style - it will use 'default'
name-tag-list=name:XX,int_name,name,place_name,loc_name is a useful option where XX is the map user's language code
Should specify: route
I don't think 'check-roundabouts' is of any benefit for a new user
Option 'add-pois-to-lines' generates a lot of 'not very useful' POIs and I think it is better turned off. This is a topic that could be re -visited in 'default style improvements'
'make-opposite-cycleways' is wrong for a lot of countries
I'd specify: 'order-by-decreasing-area' as the way to get a map that shows polygon features overlayed in the best order, without having to make fixed arbitrary decisions about all the [_drawOrder] levels in a typ-file.
Following, inline, is a version with some changes - feel free to take/ignore whatever you think is best. It should probably be more heavily commented.
Regards Ticker
# # Set options to create a routable map for a Garmin GPS # Assumes that the files bounds.zip and sea.zip exist # gmapsupp code-page=1252 no-tdbfile nsis index #split-name-index #road-name-config=mkgmap/examples/roadNameConfig.txt bounds=bounds.zip location-autofill=is_in,nearest housenumbers #name-tag-list=name:en,int_name,name,place_name,loc_name max-jobs route drive-on=detect no-add-pois-to-lines add-pois-to-areas precomp-sea=sea.zip #make-opposite-cycleways link-pois-to-ways process-destination process-exits order-by-decreasing-area
#that's it
On Thu, 2019-02-14 at 14:29 +0100, Andrzej Popowski wrote:
Hi Gerd,
maybe treat it like default style, which is kind of build in? For example, when invoking mkgmap with an option --recommended, mkgmap could include all options from default config.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Ticker, I am currently sick again (influenca), so I will not do anything complex during the next days. Please provide more details so that I can try to reproduce this. Maybe the results depend on the device, maybe it's the firmware, or maybe there is a bug. I guess you see this problem also with other (longer) street names? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Mittwoch, 20. Februar 2019 11:38 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Sample basic mkgmap config file Hi Gerd I've just built a map with --split-name-index and --road-name-config as below, using latest trunk. On my old eTrex Legend, I still get the behaviour as described earlier. I didn't use --split-name-index before, but it seems to behave as expected - all words except the suffix words are in the street list and can be found quickly and the result list then shows the full name. On my new eTrex 30x the behaviour is slightly different and worse. In the example from before, if I enter 'Xx' into the Street part of the address search, the selection list shows just "Xx Avenue". If I select this, the result list shows all addresses in Xx Avenue/Close/Way... I don't think this is relevant, but none of these streets have house number information and I've used option --no-housenumbers. The result list has 1 entry per street. Regards Ticker On Tue, 2019-02-19 at 18:21 +0000, Gerd Petermann wrote:
What you describe would be an error in my understanding. Can you still reproduce it?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 19. Februar 2019 19:06 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Sample basic mkgmap config file
Hi Gerd
I experimented with --road-name-config=../roadNameConfig.txt just after it was committed to trunk a few months ago, using my old eTrex Legend HCx. Nothing strange in my style.
roadNameConfig.txt included:
# english #no prefix1:en = "East ", "North ", "South ", "West " suffix:en = " Avenue", " Close", " Court", " Crescent", " Drive", "Gardens", " Gate", " Grove", " Lane", " Mews", " Parade", " Park", "Passage", " Place", " Rise", " Road", " Square", " Street", "Terrace", " View", " Walk", " Way", " Yard" ... lang:GBR = en
Around where I live there are "Xx Road", "Xx Avenue", "Xx Close", "Xx Mews" and "Xx Way"
Doing Find > Address, I select the "Region" (=country), enter the "City" and, into the "Street" field, enter "X" and it shows the list of matching streets, just "Xx". Then entering a "Number" (or clearing the Number field to show all addresses in the street) it shows, in a single list, all the matching addresses in Xx Road, Avenue, Close, Mews and Way.
It is much quicker and I consider it more natural, to select the particular Street in the "Street" stage (from the small, presented list of 5 in this case) and then be shown the matching addresses in just this street.
Does this make sense?
Ticker
On Tue, 2019-02-19 at 17:26 +0000, Gerd Petermann wrote:
Hi Ticker,
I don't understand what you mean with "Removing all the common suffixes (road/street/etc) to the second stage of address searching just makes finding an address awkward and unnatural. It is normal to select the full street in 1 stage then the locations within the street in the next stage." Is that something that you do in your style?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 19. Februar 2019 12:32 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Sample basic mkgmap config file
Hi Gerd
--split-name-index and --road-name-config behave as expected, but:
UK roads are always indexed by their first word, even when the word is 'The'.
Removing all the common suffixes (road/street/etc) to the second stage of address searching just makes finding an address awkward and unnatural. It is normal to select the full street in 1 stage then the locations within the street in the next stage.
My opinion is that using --order-by-decreasing-area and then, if you have a typ-file, setting all [_drawOrder] to the same value, gives a good map, whereas attempting to pre-define which polygons overwrite others using [_drawOrder] will be wrong in some cases.
Ticker
On Thu, 2019-02-14 at 17:35 +0000, Gerd Petermann wrote:
Hi Ticker,
thanks for the comments. - I forgot route, that was not intended. - no-tdbfile and nsis are a bad combination, and I see no problem when we generate all possible formats unless one starts to create really large maps. - I am not aware of problems with --split-name-index or --road -name -config, please give examples in a new thread. Besides that I see no problems to remove those. - I agree that --add-pois-to-lines is a rather problematic option, but I see no need to add no-add-pois-to-lines - My understanding is that we don't need order-by-decreasing-area once we have a default typ?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 14. Februar 2019 18:19 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Sample basic mkgmap config file
Hi
I have a few suggestions / comments:
I don't agree with --recommended because this file will often required some tweaking and eventually become the basis of the new users building environment.
I think forward slash (/) works as a directory seperator on DOS/Windows so can always use this.
It should be written to assume various items are in the current directory, including the .cfg file itself, the outputs from splitter, bounds.zip, sea.zip and mkgmap release subdirectory
It should be aimed at generating a GMAPSUPP.IMG file to put on a Garmin device. All the PC bits for basecamp/mapsource are a distraction and a great deal of time can be wasted trying to get these installed on a PC and then trying to use them install the map image on a device; so shouldn't have 'gmapi' and should have 'no-tdbfile'
Should specify: code-page=1252
I'm not convinced of the general benefits of 'split-name-index' and 'road-name-config'. They don't give good behaviour for the UK
The 'bounds' option to location-autofill doesn't do anything
No need to specify the style - it will use 'default'
name-tag-list=name:XX,int_name,name,place_name,loc_name is a useful option where XX is the map user's language code
Should specify: route
I don't think 'check-roundabouts' is of any benefit for a new user
Option 'add-pois-to-lines' generates a lot of 'not very useful' POIs and I think it is better turned off. This is a topic that could be re -visited in 'default style improvements'
'make-opposite-cycleways' is wrong for a lot of countries
I'd specify: 'order-by-decreasing-area' as the way to get a map that shows polygon features overlayed in the best order, without having to make fixed arbitrary decisions about all the [_drawOrder] levels in a typ-file.
Following, inline, is a version with some changes - feel free to take/ignore whatever you think is best. It should probably be more heavily commented.
Regards Ticker
# # Set options to create a routable map for a Garmin GPS # Assumes that the files bounds.zip and sea.zip exist # gmapsupp code-page=1252 no-tdbfile nsis index #split-name-index #road-name-config=mkgmap/examples/roadNameConfig.txt bounds=bounds.zip location-autofill=is_in,nearest housenumbers #name-tag-list=name:en,int_name,name,place_name,loc_name max-jobs route drive-on=detect no-add-pois-to-lines add-pois-to-areas precomp-sea=sea.zip #make-opposite-cycleways link-pois-to-ways process-destination process-exits order-by-decreasing-area
#that's it
On Thu, 2019-02-14 at 14:29 +0100, Andrzej Popowski wrote:
Hi Gerd,
maybe treat it like default style, which is kind of build in? For example, when invoking mkgmap with an option --recommended, mkgmap could include all options from default config.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd Sorry to hear that your're not well. It seems that the behaviour of this feature is device dependent (I used the same map on the same SD card on both my devices). Each device was consistent in its behaviour for all streets I looked at, regardless of street name length. I didn't like the effect of this option on the old eTrex Legend, but it was justifiable. On the new 30x it is plain misleading, picking one suffix to show on the street completion list then show results that include all the other suffixes. Having --split-name-index without --road-names-config would, I imagine, greatly increase the index size. And again, I don't think this option gives anything that a UK user would expect. Reading the documentation for the option, one of the reasons for it was to show just the significant part of the name at outer zoom levels and the full name as you zoom it. This doesn't happen on my devices, the full street name appears in one go as you zoom in. It would be interesting to know the behaviour on other devices and maybe all that should be done is add a bit more to the documentation. I don't think either should be enabled in the sample.cfg Best wishes Ticker On Wed, 2019-02-20 at 10:44 +0000, Gerd Petermann wrote:
Hi Ticker,
I am currently sick again (influenca), so I will not do anything complex during the next days. Please provide more details so that I can try to reproduce this. Maybe the results depend on the device, maybe it's the firmware, or maybe there is a bug. I guess you see this problem also with other (longer) street names?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Mittwoch, 20. Februar 2019 11:38 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Sample basic mkgmap config file
Hi Gerd
I've just built a map with --split-name-index and --road-name-config as below, using latest trunk.
On my old eTrex Legend, I still get the behaviour as described earlier. I didn't use --split-name-index before, but it seems to behave as expected - all words except the suffix words are in the street list and can be found quickly and the result list then shows the full name.
On my new eTrex 30x the behaviour is slightly different and worse. In the example from before, if I enter 'Xx' into the Street part of the address search, the selection list shows just "Xx Avenue". If I select this, the result list shows all addresses in Xx Avenue/Close/Way...
I don't think this is relevant, but none of these streets have house number information and I've used option --no-housenumbers. The result list has 1 entry per street.
Regards Ticker
On Tue, 2019-02-19 at 18:21 +0000, Gerd Petermann wrote:
What you describe would be an error in my understanding. Can you still reproduce it?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 19. Februar 2019 19:06 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Sample basic mkgmap config file
Hi Gerd
I experimented with --road-name-config=../roadNameConfig.txt just after it was committed to trunk a few months ago, using my old eTrex Legend HCx. Nothing strange in my style.
roadNameConfig.txt included:
# english #no prefix1:en = "East ", "North ", "South ", "West " suffix:en = " Avenue", " Close", " Court", " Crescent", " Drive", "Gardens", " Gate", " Grove", " Lane", " Mews", " Parade", " Park", "Passage", " Place", " Rise", " Road", " Square", " Street", "Terrace", " View", " Walk", " Way", " Yard" ... lang:GBR = en
Around where I live there are "Xx Road", "Xx Avenue", "Xx Close", "Xx Mews" and "Xx Way"
Doing Find > Address, I select the "Region" (=country), enter the "City" and, into the "Street" field, enter "X" and it shows the list of matching streets, just "Xx". Then entering a "Number" (or clearing the Number field to show all addresses in the street) it shows, in a single list, all the matching addresses in Xx Road, Avenue, Close, Mews and Way.
It is much quicker and I consider it more natural, to select the particular Street in the "Street" stage (from the small, presented list of 5 in this case) and then be shown the matching addresses in just this street.
Does this make sense?
Ticker
On Tue, 2019-02-19 at 17:26 +0000, Gerd Petermann wrote:
Hi Ticker,
I don't understand what you mean with "Removing all the common suffixes (road/street/etc) to the second stage of address searching just makes finding an address awkward and unnatural. It is normal to select the full street in 1 stage then the locations within the street in the next stage." Is that something that you do in your style?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 19. Februar 2019 12:32 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Sample basic mkgmap config file
Hi Gerd
--split-name-index and --road-name-config behave as expected, but:
UK roads are always indexed by their first word, even when the word is 'The'.
Removing all the common suffixes (road/street/etc) to the second stage of address searching just makes finding an address awkward and unnatural. It is normal to select the full street in 1 stage then the locations within the street in the next stage.
My opinion is that using --order-by-decreasing-area and then, if you have a typ-file, setting all [_drawOrder] to the same value, gives a good map, whereas attempting to pre-define which polygons overwrite others using [_drawOrder] will be wrong in some cases.
Ticker
On Thu, 2019-02-14 at 17:35 +0000, Gerd Petermann wrote:
Hi Ticker,
thanks for the comments. - I forgot route, that was not intended. - no-tdbfile and nsis are a bad combination, and I see no problem when we generate all possible formats unless one starts to create really large maps. - I am not aware of problems with --split-name-index or --road -name -config, please give examples in a new thread. Besides that I see no problems to remove those. - I agree that --add-pois-to-lines is a rather problematic option, but I see no need to add no-add-pois-to-lines - My understanding is that we don't need order-by-decreasing -area once we have a default typ?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 14. Februar 2019 18:19 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Sample basic mkgmap config file
Hi
I have a few suggestions / comments:
I don't agree with --recommended because this file will often required some tweaking and eventually become the basis of the new users building environment.
I think forward slash (/) works as a directory seperator on DOS/Windows so can always use this.
It should be written to assume various items are in the current directory, including the .cfg file itself, the outputs from splitter, bounds.zip, sea.zip and mkgmap release subdirectory
It should be aimed at generating a GMAPSUPP.IMG file to put on a Garmin device. All the PC bits for basecamp/mapsource are a distraction and a great deal of time can be wasted trying to get these installed on a PC and then trying to use them install the map image on a device; so shouldn't have 'gmapi' and should have 'no-tdbfile'
Should specify: code-page=1252
I'm not convinced of the general benefits of 'split-name-index' and 'road-name-config'. They don't give good behaviour for the UK
The 'bounds' option to location-autofill doesn't do anything
No need to specify the style - it will use 'default'
name-tag-list=name:XX,int_name,name,place_name,loc_name is a useful option where XX is the map user's language code
Should specify: route
I don't think 'check-roundabouts' is of any benefit for a new user
Option 'add-pois-to-lines' generates a lot of 'not very useful' POIs and I think it is better turned off. This is a topic that could be re -visited in 'default style improvements'
'make-opposite-cycleways' is wrong for a lot of countries
I'd specify: 'order-by-decreasing-area' as the way to get a map that shows polygon features overlayed in the best order, without having to make fixed arbitrary decisions about all the [_drawOrder] levels in a typ-file.
Following, inline, is a version with some changes - feel free to take/ignore whatever you think is best. It should probably be more heavily commented.
Regards Ticker
# # Set options to create a routable map for a Garmin GPS # Assumes that the files bounds.zip and sea.zip exist # gmapsupp code-page=1252 no-tdbfile nsis index #split-name-index #road-name-config=mkgmap/examples/roadNameConfig.txt bounds=bounds.zip location-autofill=is_in,nearest housenumbers #name-tag-list=name:en,int_name,name,place_name,loc_name max-jobs route drive-on=detect no-add-pois-to-lines add-pois-to-areas precomp-sea=sea.zip #make-opposite-cycleways link-pois-to-ways process-destination process-exits order-by-decreasing-area
#that's it
On Thu, 2019-02-14 at 14:29 +0100, Andrzej Popowski wrote:
Hi Gerd,
maybe treat it like default style, which is kind of build in? For example, when invoking mkgmap with an option --recommended, mkgmap could include all options from default config.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd It would be good if this idea was resurrected - initially just releasing the file, as you last had it, somewhere under trunk/resources. Then suggestions can be incorporated and mention made of it elsewhere in the documentation. Ticker On Thu, 2019-02-21 at 10:50 +0000, Ticker Berkin wrote:
Hi Gerd
Sorry to hear that your're not well.
It seems that the behaviour of this feature is device dependent (I used the same map on the same SD card on both my devices).
Each device was consistent in its behaviour for all streets I looked at, regardless of street name length.
I didn't like the effect of this option on the old eTrex Legend, but it was justifiable.
On the new 30x it is plain misleading, picking one suffix to show on the street completion list then show results that include all the other suffixes.
Having --split-name-index without --road-names-config would, I imagine, greatly increase the index size. And again, I don't think this option gives anything that a UK user would expect.
Reading the documentation for the option, one of the reasons for it was to show just the significant part of the name at outer zoom levels and the full name as you zoom it. This doesn't happen on my devices, the full street name appears in one go as you zoom in.
It would be interesting to know the behaviour on other devices and maybe all that should be done is add a bit more to the documentation.
I don't think either should be enabled in the sample.cfg
Best wishes Ticker
On Wed, 2019-02-20 at 10:44 +0000, Gerd Petermann wrote:
Hi Ticker,
I am currently sick again (influenca), so I will not do anything complex during the next days. Please provide more details so that I can try to reproduce this. Maybe the results depend on the device, maybe it's the firmware, or maybe there is a bug. I guess you see this problem also with other (longer) street names?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Mittwoch, 20. Februar 2019 11:38 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Sample basic mkgmap config file
Hi Gerd
I've just built a map with --split-name-index and --road-name -config as below, using latest trunk.
On my old eTrex Legend, I still get the behaviour as described earlier. I didn't use --split-name-index before, but it seems to behave as expected - all words except the suffix words are in the street list and can be found quickly and the result list then shows the full name.
On my new eTrex 30x the behaviour is slightly different and worse. In the example from before, if I enter 'Xx' into the Street part of the address search, the selection list shows just "Xx Avenue". If I select this, the result list shows all addresses in Xx Avenue/Close/Way...
I don't think this is relevant, but none of these streets have house number information and I've used option --no-housenumbers. The result list has 1 entry per street.
Regards Ticker
On Tue, 2019-02-19 at 18:21 +0000, Gerd Petermann wrote:
What you describe would be an error in my understanding. Can you still reproduce it?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 19. Februar 2019 19:06 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Sample basic mkgmap config file
Hi Gerd
I experimented with --road-name-config=../roadNameConfig.txt just after it was committed to trunk a few months ago, using my old eTrex Legend HCx. Nothing strange in my style.
roadNameConfig.txt included:
# english #no prefix1:en = "East ", "North ", "South ", "West " suffix:en = " Avenue", " Close", " Court", " Crescent", " Drive", "Gardens", " Gate", " Grove", " Lane", " Mews", " Parade", " Park", "Passage", " Place", " Rise", " Road", " Square", " Street", "Terrace", " View", " Walk", " Way", " Yard" ... lang:GBR = en
Around where I live there are "Xx Road", "Xx Avenue", "Xx Close", "Xx Mews" and "Xx Way"
Doing Find > Address, I select the "Region" (=country), enter the "City" and, into the "Street" field, enter "X" and it shows the list of matching streets, just "Xx". Then entering a "Number" (or clearing the Number field to show all addresses in the street) it shows, in a single list, all the matching addresses in Xx Road, Avenue, Close, Mews and Way.
It is much quicker and I consider it more natural, to select the particular Street in the "Street" stage (from the small, presented list of 5 in this case) and then be shown the matching addresses in just this street.
Does this make sense?
Ticker
On Tue, 2019-02-19 at 17:26 +0000, Gerd Petermann wrote:
Hi Ticker,
I don't understand what you mean with "Removing all the common suffixes (road/street/etc) to the second stage of address searching just makes finding an address awkward and unnatural. It is normal to select the full street in 1 stage then the locations within the street in the next stage." Is that something that you do in your style?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 19. Februar 2019 12:32 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Sample basic mkgmap config file
Hi Gerd
--split-name-index and --road-name-config behave as expected, but:
UK roads are always indexed by their first word, even when the word is 'The'.
Removing all the common suffixes (road/street/etc) to the second stage of address searching just makes finding an address awkward and unnatural. It is normal to select the full street in 1 stage then the locations within the street in the next stage.
My opinion is that using --order-by-decreasing-area and then, if you have a typ-file, setting all [_drawOrder] to the same value, gives a good map, whereas attempting to pre-define which polygons overwrite others using [_drawOrder] will be wrong in some cases.
Ticker
On Thu, 2019-02-14 at 17:35 +0000, Gerd Petermann wrote:
Hi Ticker,
thanks for the comments. - I forgot route, that was not intended. - no-tdbfile and nsis are a bad combination, and I see no problem when we generate all possible formats unless one starts to create really large maps. - I am not aware of problems with --split-name-index or - -road -name -config, please give examples in a new thread. Besides that I see no problems to remove those. - I agree that --add-pois-to-lines is a rather problematic option, but I see no need to add no-add-pois-to-lines - My understanding is that we don't need order-by-decreasing -area once we have a default typ?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 14. Februar 2019 18:19 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Sample basic mkgmap config file
Hi
I have a few suggestions / comments:
I don't agree with --recommended because this file will often required some tweaking and eventually become the basis of the new users building environment.
I think forward slash (/) works as a directory seperator on DOS/Windows so can always use this.
It should be written to assume various items are in the current directory, including the .cfg file itself, the outputs from splitter, bounds.zip, sea.zip and mkgmap release subdirectory
It should be aimed at generating a GMAPSUPP.IMG file to put on a Garmin device. All the PC bits for basecamp/mapsource are a distraction and a great deal of time can be wasted trying to get these installed on a PC and then trying to use them install the map image on a device; so shouldn't have 'gmapi' and should have 'no-tdbfile'
Should specify: code-page=1252
I'm not convinced of the general benefits of 'split-name -index' and 'road-name-config'. They don't give good behaviour for the UK
The 'bounds' option to location-autofill doesn't do anything
No need to specify the style - it will use 'default'
name-tag-list=name:XX,int_name,name,place_name,loc_name is a useful option where XX is the map user's language code
Should specify: route
I don't think 'check-roundabouts' is of any benefit for a new user
Option 'add-pois-to-lines' generates a lot of 'not very useful' POIs and I think it is better turned off. This is a topic that could be re -visited in 'default style improvements'
'make-opposite-cycleways' is wrong for a lot of countries
I'd specify: 'order-by-decreasing-area' as the way to get a map that shows polygon features overlayed in the best order, without having to make fixed arbitrary decisions about all the [_drawOrder] levels in a typ-file.
Following, inline, is a version with some changes - feel free to take/ignore whatever you think is best. It should probably be more heavily commented.
Regards Ticker
# # Set options to create a routable map for a Garmin GPS # Assumes that the files bounds.zip and sea.zip exist # gmapsupp code-page=1252 no-tdbfile nsis index #split-name-index #road-name-config=mkgmap/examples/roadNameConfig.txt bounds=bounds.zip location-autofill=is_in,nearest housenumbers #name-tag-list=name:en,int_name,name,place_name,loc_name max-jobs route drive-on=detect no-add-pois-to-lines add-pois-to-areas precomp-sea=sea.zip #make-opposite-cycleways link-pois-to-ways process-destination process-exits order-by-decreasing-area
#that's it
On Thu, 2019-02-14 at 14:29 +0100, Andrzej Popowski wrote:
Hi Gerd,
maybe treat it like default style, which is kind of build in? For example, when invoking mkgmap with an option --recommended, mkgmap could include all options from default config.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk
Hi Ticker, I don't think that it will be of much help when we distribute a sample without any hint regarding the usage. The attached patch shows how to change build.xml so that it copies a sample.cfg to examples directory. I think we need at least a README.html or HOWTO.html that explains how to use it and I have no idea where to start with this. Here is a brief description how I create a map for my bicycle tours: 1) Extract attached zip file to produce a directory map containing makemap.cmd and mkgmaps.args 2) Create a gpx file with a router like brouter http://brouter.de/brouter-web 3) Load the gpx file into JOSM and draw a polygon around it, store it as map.poly in the map directory 4) Download osm.pbf from geofabrik that covers the map.poly (typically europe-lastest.osm.pbf) 5) Modify the first rows in script makemap.cmd so that the wanted osm input file is used and map name is set 6) Execute the script (don't try it, it will only work on my PC) If you look at the script you will find that it requires some tools and input files in exactly the right places and there is no code to react on errors, so it may help some people but probably it will only be confusing for a newbie, esp. one who uses Linux. The program map-composer (1) tries to solve this problem with a dialog, but it is only available in German. (1) http://composer.waldpfa.de/ Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 12. November 2019 15:32 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Sample basic mkgmap config file Hi Gerd It would be good if this idea was resurrected - initially just releasing the file, as you last had it, somewhere under trunk/resources. Then suggestions can be incorporated and mention made of it elsewhere in the documentation. Ticker On Thu, 2019-02-21 at 10:50 +0000, Ticker Berkin wrote:
Hi Gerd
Sorry to hear that your're not well.
It seems that the behaviour of this feature is device dependent (I used the same map on the same SD card on both my devices).
Each device was consistent in its behaviour for all streets I looked at, regardless of street name length.
I didn't like the effect of this option on the old eTrex Legend, but it was justifiable.
On the new 30x it is plain misleading, picking one suffix to show on the street completion list then show results that include all the other suffixes.
Having --split-name-index without --road-names-config would, I imagine, greatly increase the index size. And again, I don't think this option gives anything that a UK user would expect.
Reading the documentation for the option, one of the reasons for it was to show just the significant part of the name at outer zoom levels and the full name as you zoom it. This doesn't happen on my devices, the full street name appears in one go as you zoom in.
It would be interesting to know the behaviour on other devices and maybe all that should be done is add a bit more to the documentation.
I don't think either should be enabled in the sample.cfg
Best wishes Ticker
On Wed, 2019-02-20 at 10:44 +0000, Gerd Petermann wrote:
Hi Ticker,
I am currently sick again (influenca), so I will not do anything complex during the next days. Please provide more details so that I can try to reproduce this. Maybe the results depend on the device, maybe it's the firmware, or maybe there is a bug. I guess you see this problem also with other (longer) street names?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Mittwoch, 20. Februar 2019 11:38 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Sample basic mkgmap config file
Hi Gerd
I've just built a map with --split-name-index and --road-name -config as below, using latest trunk.
On my old eTrex Legend, I still get the behaviour as described earlier. I didn't use --split-name-index before, but it seems to behave as expected - all words except the suffix words are in the street list and can be found quickly and the result list then shows the full name.
On my new eTrex 30x the behaviour is slightly different and worse. In the example from before, if I enter 'Xx' into the Street part of the address search, the selection list shows just "Xx Avenue". If I select this, the result list shows all addresses in Xx Avenue/Close/Way...
I don't think this is relevant, but none of these streets have house number information and I've used option --no-housenumbers. The result list has 1 entry per street.
Regards Ticker
On Tue, 2019-02-19 at 18:21 +0000, Gerd Petermann wrote:
What you describe would be an error in my understanding. Can you still reproduce it?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 19. Februar 2019 19:06 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Sample basic mkgmap config file
Hi Gerd
I experimented with --road-name-config=../roadNameConfig.txt just after it was committed to trunk a few months ago, using my old eTrex Legend HCx. Nothing strange in my style.
roadNameConfig.txt included:
# english #no prefix1:en = "East ", "North ", "South ", "West " suffix:en = " Avenue", " Close", " Court", " Crescent", " Drive", "Gardens", " Gate", " Grove", " Lane", " Mews", " Parade", " Park", "Passage", " Place", " Rise", " Road", " Square", " Street", "Terrace", " View", " Walk", " Way", " Yard" ... lang:GBR = en
Around where I live there are "Xx Road", "Xx Avenue", "Xx Close", "Xx Mews" and "Xx Way"
Doing Find > Address, I select the "Region" (=country), enter the "City" and, into the "Street" field, enter "X" and it shows the list of matching streets, just "Xx". Then entering a "Number" (or clearing the Number field to show all addresses in the street) it shows, in a single list, all the matching addresses in Xx Road, Avenue, Close, Mews and Way.
It is much quicker and I consider it more natural, to select the particular Street in the "Street" stage (from the small, presented list of 5 in this case) and then be shown the matching addresses in just this street.
Does this make sense?
Ticker
On Tue, 2019-02-19 at 17:26 +0000, Gerd Petermann wrote:
Hi Ticker,
I don't understand what you mean with "Removing all the common suffixes (road/street/etc) to the second stage of address searching just makes finding an address awkward and unnatural. It is normal to select the full street in 1 stage then the locations within the street in the next stage." Is that something that you do in your style?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 19. Februar 2019 12:32 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Sample basic mkgmap config file
Hi Gerd
--split-name-index and --road-name-config behave as expected, but:
UK roads are always indexed by their first word, even when the word is 'The'.
Removing all the common suffixes (road/street/etc) to the second stage of address searching just makes finding an address awkward and unnatural. It is normal to select the full street in 1 stage then the locations within the street in the next stage.
My opinion is that using --order-by-decreasing-area and then, if you have a typ-file, setting all [_drawOrder] to the same value, gives a good map, whereas attempting to pre-define which polygons overwrite others using [_drawOrder] will be wrong in some cases.
Ticker
On Thu, 2019-02-14 at 17:35 +0000, Gerd Petermann wrote:
Hi Ticker,
thanks for the comments. - I forgot route, that was not intended. - no-tdbfile and nsis are a bad combination, and I see no problem when we generate all possible formats unless one starts to create really large maps. - I am not aware of problems with --split-name-index or - -road -name -config, please give examples in a new thread. Besides that I see no problems to remove those. - I agree that --add-pois-to-lines is a rather problematic option, but I see no need to add no-add-pois-to-lines - My understanding is that we don't need order-by-decreasing -area once we have a default typ?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 14. Februar 2019 18:19 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Sample basic mkgmap config file
Hi
I have a few suggestions / comments:
I don't agree with --recommended because this file will often required some tweaking and eventually become the basis of the new users building environment.
I think forward slash (/) works as a directory seperator on DOS/Windows so can always use this.
It should be written to assume various items are in the current directory, including the .cfg file itself, the outputs from splitter, bounds.zip, sea.zip and mkgmap release subdirectory
It should be aimed at generating a GMAPSUPP.IMG file to put on a Garmin device. All the PC bits for basecamp/mapsource are a distraction and a great deal of time can be wasted trying to get these installed on a PC and then trying to use them install the map image on a device; so shouldn't have 'gmapi' and should have 'no-tdbfile'
Should specify: code-page=1252
I'm not convinced of the general benefits of 'split-name -index' and 'road-name-config'. They don't give good behaviour for the UK
The 'bounds' option to location-autofill doesn't do anything
No need to specify the style - it will use 'default'
name-tag-list=name:XX,int_name,name,place_name,loc_name is a useful option where XX is the map user's language code
Should specify: route
I don't think 'check-roundabouts' is of any benefit for a new user
Option 'add-pois-to-lines' generates a lot of 'not very useful' POIs and I think it is better turned off. This is a topic that could be re -visited in 'default style improvements'
'make-opposite-cycleways' is wrong for a lot of countries
I'd specify: 'order-by-decreasing-area' as the way to get a map that shows polygon features overlayed in the best order, without having to make fixed arbitrary decisions about all the [_drawOrder] levels in a typ-file.
Following, inline, is a version with some changes - feel free to take/ignore whatever you think is best. It should probably be more heavily commented.
Regards Ticker
# # Set options to create a routable map for a Garmin GPS # Assumes that the files bounds.zip and sea.zip exist # gmapsupp code-page=1252 no-tdbfile nsis index #split-name-index #road-name-config=mkgmap/examples/roadNameConfig.txt bounds=bounds.zip location-autofill=is_in,nearest housenumbers #name-tag-list=name:en,int_name,name,place_name,loc_name max-jobs route drive-on=detect no-add-pois-to-lines add-pois-to-areas precomp-sea=sea.zip #make-opposite-cycleways link-pois-to-ways process-destination process-exits order-by-decreasing-area
#that's it
On Thu, 2019-02-14 at 14:29 +0100, Andrzej Popowski wrote:
Hi Gerd,
maybe treat it like default style, which is kind of build in? For example, when invoking mkgmap with an option --recommended, mkgmap could include all options from default config.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd I've tweaked the file a bit and put a hint to it in the README in the root directory of the distribution; this file is very out-of-date but I didn't want to start re-writing it. Attached is the updated patch and resources/sample.cfg (which I couldn't work out how to get into the patch because it's a new file) I don't think we can solve all a new users build problems, but the idea of this was just to start the user off with a good set of options and how they can be specified, along with the splitter generated template.args, to mkgmap. Ticker On Wed, 2019-11-13 at 11:12 +0000, Gerd Petermann wrote:
Hi Ticker,
I don't think that it will be of much help when we distribute a sample without any hint regarding the usage.
The attached patch shows how to change build.xml so that it copies a sample.cfg to examples directory. I think we need at least a README.html or HOWTO.html that explains how to use it and I have no idea where to start with this.
Here is a brief description how I create a map for my bicycle tours: 1) Extract attached zip file to produce a directory map containing makemap.cmd and mkgmaps.args 2) Create a gpx file with a router like brouter http://brouter.de/brouter-web 3) Load the gpx file into JOSM and draw a polygon around it, store it as map.poly in the map directory 4) Download osm.pbf from geofabrik that covers the map.poly (typically europe-lastest.osm.pbf) 5) Modify the first rows in script makemap.cmd so that the wanted osm input file is used and map name is set 6) Execute the script (don't try it, it will only work on my PC)
If you look at the script you will find that it requires some tools and input files in exactly the right places and there is no code to react on errors, so it may help some people but probably it will only be confusing for a newbie, esp. one who uses Linux.
The program map-composer (1) tries to solve this problem with a dialog, but it is only available in German.
(1) http://composer.waldpfa.de/
Gerd
Hi Ticker, I use "svn add" to add a new file. A following svn diff produces the patch with the file. I think the README is not distributed, so you have to change build.xml as well. If you use svn patch with my patch the file is "automagically" svn-aded Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Mittwoch, 13. November 2019 18:43 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Sample basic mkgmap config file Hi Gerd I've tweaked the file a bit and put a hint to it in the README in the root directory of the distribution; this file is very out-of-date but I didn't want to start re-writing it. Attached is the updated patch and resources/sample.cfg (which I couldn't work out how to get into the patch because it's a new file) I don't think we can solve all a new users build problems, but the idea of this was just to start the user off with a good set of options and how they can be specified, along with the splitter generated template.args, to mkgmap. Ticker On Wed, 2019-11-13 at 11:12 +0000, Gerd Petermann wrote:
Hi Ticker,
I don't think that it will be of much help when we distribute a sample without any hint regarding the usage.
The attached patch shows how to change build.xml so that it copies a sample.cfg to examples directory. I think we need at least a README.html or HOWTO.html that explains how to use it and I have no idea where to start with this.
Here is a brief description how I create a map for my bicycle tours: 1) Extract attached zip file to produce a directory map containing makemap.cmd and mkgmaps.args 2) Create a gpx file with a router like brouter http://brouter.de/brouter-web 3) Load the gpx file into JOSM and draw a polygon around it, store it as map.poly in the map directory 4) Download osm.pbf from geofabrik that covers the map.poly (typically europe-lastest.osm.pbf) 5) Modify the first rows in script makemap.cmd so that the wanted osm input file is used and map name is set 6) Execute the script (don't try it, it will only work on my PC)
If you look at the script you will find that it requires some tools and input files in exactly the right places and there is no code to react on errors, so it may help some people but probably it will only be confusing for a newbie, esp. one who uses Linux.
The program map-composer (1) tries to solve this problem with a dialog, but it is only available in German.
(1) http://composer.waldpfa.de/
Gerd
Hi Gerd Here is revised patch including sample.cfg. The README is distributed; build.xml already copies it. Ticker On Wed, 2019-11-13 at 17:50 +0000, Gerd Petermann wrote:
Hi Ticker,
I use "svn add" to add a new file. A following svn diff produces the patch with the file. I think the README is not distributed, so you have to change build.xml as well.
If you use svn patch with my patch the file is "automagically" svn -aded
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Mittwoch, 13. November 2019 18:43 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Sample basic mkgmap config file
Hi Gerd
I've tweaked the file a bit and put a hint to it in the README in the root directory of the distribution; this file is very out-of-date but I didn't want to start re-writing it.
Attached is the updated patch and resources/sample.cfg (which I couldn't work out how to get into the patch because it's a new file)
I don't think we can solve all a new users build problems, but the idea of this was just to start the user off with a good set of options and how they can be specified, along with the splitter generated template.args, to mkgmap.
Ticker
On Wed, 2019-11-13 at 11:12 +0000, Gerd Petermann wrote:
Hi Ticker,
I don't think that it will be of much help when we distribute a sample without any hint regarding the usage.
The attached patch shows how to change build.xml so that it copies a sample.cfg to examples directory. I think we need at least a README.html or HOWTO.html that explains how to use it and I have no idea where to start with this.
Here is a brief description how I create a map for my bicycle tours: 1) Extract attached zip file to produce a directory map containing makemap.cmd and mkgmaps.args 2) Create a gpx file with a router like brouter http://brouter.de/brouter-web 3) Load the gpx file into JOSM and draw a polygon around it, store it as map.poly in the map directory 4) Download osm.pbf from geofabrik that covers the map.poly (typically europe-lastest.osm.pbf) 5) Modify the first rows in script makemap.cmd so that the wanted osm input file is used and map name is set 6) Execute the script (don't try it, it will only work on my PC)
If you look at the script you will find that it requires some tools and input files in exactly the right places and there is no code to react on errors, so it may help some people but probably it will only be confusing for a newbie, esp. one who uses Linux.
The program map-composer (1) tries to solve this problem with a dialog, but it is only available in German.
(1) http://composer.waldpfa.de/
Gerd
Hi Ticker,
I don't agree with --recommended because this file will often required some tweaking and eventually become the basis of the new users building environment.
I don't see problems with tweaking --recommended option. Mkgmap allows for repeated options and process the last one. Minor tweaks for beginners could work like this: mkgmap --recommended --drive-on=left ... I assume, that default config would be distributed with mkgmap, just like default style. This copy could be a basis for more advanced users. -- Best regards, Andrzej
participants (4)
-
Andrzej Popowski -
Gerd Petermann -
Gerd Petermann
-
Ticker Berkin