[Fwd: Re: Suggestions for roadNameConfig.txt]

Hi Gerd Could you consider this change to roadNameConfig.txt for GBR I've attached an updated version based current trunk.o1 Thank you Ticker -------- Forwarded Message -------- From: Ticker Berkin <rwb-mkgmap@jagit.co.uk> Reply-to: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] Suggestions for roadNameConfig.txt Date: Thu, 23 Jan 2020 16:56:17 +0000 Hi Gerd I've just been going through some old mails/patches. I think the updated contents of roadNameConfig.txt is correct and better than the previous version. The fact that it doesn't work consistently across devices and, on some, is misleading shouldn't stop the file being available as an example in the distribution. The user has the choice about how to use it and it contains some comments and a link relating to these problems. I've attached an updated patch with UTF-8 encoding markers, a different section for UK road names and improved some comments. This file has always been read by mkgmap as UTF-8. The function of the markers is to make editors aware of this; it contains characters outside the 7-bit ascii range. Ticker On Mon, 2019-12-16 at 11:30 +0000, Gerd Petermann wrote:
Hi Ticker,
reg. search: You are probably right, address search works very different on the Garmin devices. On the Oregon, I have several dialogs, first to chose country, next to chose city or "all", next to type house number, last one asking for road name. In this dialog there is no autocompletion, I just have to type characters. Sometimes the device switches automatically to a result list while I am typing, sometimes it doesn't. When I press OK I get a list of matching roads. So, for the Oregon it works fine. Maybe it doesn't for those devices with auto-completion. Cannot test this right now. I tried it once with a Nüvi and it seemed to work well, but I don't own one.
Reg. combination of --road-name-config and --split-name-index: Yes, this gives confusing results. Not sure if it worked better in the past. I tried with Essex extract: java -jar d:\mkgmap\dist\mkgmap.jar --bounds=f:\osm\bounds.zip - -gmapi --net --index --road-name -config=d:\mkgmap\resources\roadNameConfig.txt --gmapsupp --split -name-index f:\dwnload\temp\essex-latest.osm.pbf
According to Mapsource a search for "Mace" without giving a city name should list "John Mace Road", "Mace Avenue", "Mace Court", and "Mace Walk", maybe in a different order. Without your patch I get a list showing "Mace Road", "Mace Avenue", and "Mace Walk", so "Mace Court" is missing and when I select "Mace Road" the device shows the "John Mace Road". With your patch this gets worse: The list shows only "Mace Road", when I select that entry I get a new list containing ",Thurrock","Braintree,Essex","Chelmsford,Essex", and "Colchester, Essex". Each of them points to just one of the expected roads.
Results look much better when I specify a city name. Result also looks very different without the --split-name-option. I have to do more tests, I think it worked better in the past. Maybe sorting is broken.
Gerd

Hi Ticker, did you consider disabling this feature for the UK? It looks wrong to me to have such a long list of rather meaningful names. BTW: Boulivard is probably a typo? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 16. April 2020 10:35 An: mkgmap development Betreff: [mkgmap-dev] [Fwd: Re: Suggestions for roadNameConfig.txt] Hi Gerd Could you consider this change to roadNameConfig.txt for GBR I've attached an updated version based current trunk.o1 Thank you Ticker -------- Forwarded Message -------- From: Ticker Berkin <rwb-mkgmap@jagit.co.uk> Reply-to: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] Suggestions for roadNameConfig.txt Date: Thu, 23 Jan 2020 16:56:17 +0000 Hi Gerd I've just been going through some old mails/patches. I think the updated contents of roadNameConfig.txt is correct and better than the previous version. The fact that it doesn't work consistently across devices and, on some, is misleading shouldn't stop the file being available as an example in the distribution. The user has the choice about how to use it and it contains some comments and a link relating to these problems. I've attached an updated patch with UTF-8 encoding markers, a different section for UK road names and improved some comments. This file has always been read by mkgmap as UTF-8. The function of the markers is to make editors aware of this; it contains characters outside the 7-bit ascii range. Ticker On Mon, 2019-12-16 at 11:30 +0000, Gerd Petermann wrote:
Hi Ticker,
reg. search: You are probably right, address search works very different on the Garmin devices. On the Oregon, I have several dialogs, first to chose country, next to chose city or "all", next to type house number, last one asking for road name. In this dialog there is no autocompletion, I just have to type characters. Sometimes the device switches automatically to a result list while I am typing, sometimes it doesn't. When I press OK I get a list of matching roads. So, for the Oregon it works fine. Maybe it doesn't for those devices with auto-completion. Cannot test this right now. I tried it once with a Nüvi and it seemed to work well, but I don't own one.
Reg. combination of --road-name-config and --split-name-index: Yes, this gives confusing results. Not sure if it worked better in the past. I tried with Essex extract: java -jar d:\mkgmap\dist\mkgmap.jar --bounds=f:\osm\bounds.zip - -gmapi --net --index --road-name -config=d:\mkgmap\resources\roadNameConfig.txt --gmapsupp --split -name-index f:\dwnload\temp\essex-latest.osm.pbf
According to Mapsource a search for "Mace" without giving a city name should list "John Mace Road", "Mace Avenue", "Mace Court", and "Mace Walk", maybe in a different order. Without your patch I get a list showing "Mace Road", "Mace Avenue", and "Mace Walk", so "Mace Court" is missing and when I select "Mace Road" the device shows the "John Mace Road". With your patch this gets worse: The list shows only "Mace Road", when I select that entry I get a new list containing ",Thurrock","Braintree,Essex","Chelmsford,Essex", and "Colchester, Essex". Each of them points to just one of the expected roads.
Results look much better when I specify a city name. Result also looks very different without the --split-name-option. I have to do more tests, I think it worked better in the past. Maybe sorting is broken.
Gerd

Hi Gerd I did think about this, but --road-names-config is optional and behaves as the documentation suggests and this patch includes a reasonably complete list of suffixes for the UK and useful comments. I tried it on my device and didn't like the effect and so don't use it, Others might like it. I've fixed Boulevard. Ticker On Thu, 2020-04-16 at 09:04 +0000, Gerd Petermann wrote:
Hi Ticker,
did you consider disabling this feature for the UK? It looks wrong to me to have such a long list of rather meaningful names.
BTW: Boulivard is probably a typo?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 16. April 2020 10:35 An: mkgmap development Betreff: [mkgmap-dev] [Fwd: Re: Suggestions for roadNameConfig.txt]
Hi Gerd
Could you consider this change to roadNameConfig.txt for GBR
I've attached an updated version based current trunk.o1
Thank you Ticker
-------- Forwarded Message -------- From: Ticker Berkin <rwb-mkgmap@jagit.co.uk> Reply-to: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk
To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] Suggestions for roadNameConfig.txt Date: Thu, 23 Jan 2020 16:56:17 +0000
Hi Gerd
I've just been going through some old mails/patches.
I think the updated contents of roadNameConfig.txt is correct and better than the previous version.
The fact that it doesn't work consistently across devices and, on some, is misleading shouldn't stop the file being available as an example in the distribution.
The user has the choice about how to use it and it contains some comments and a link relating to these problems.
I've attached an updated patch with UTF-8 encoding markers, a different section for UK road names and improved some comments.
This file has always been read by mkgmap as UTF-8. The function of the markers is to make editors aware of this; it contains characters outside the 7-bit ascii range.
Ticker
On Mon, 2019-12-16 at 11:30 +0000, Gerd Petermann wrote:
Hi Ticker,
reg. search: You are probably right, address search works very different on the Garmin devices. On the Oregon, I have several dialogs, first to chose country, next to chose city or "all", next to type house number, last one asking for road name. In this dialog there is no autocompletion, I just have to type characters. Sometimes the device switches automatically to a result list while I am typing, sometimes it doesn't. When I press OK I get a list of matching roads. So, for the Oregon it works fine. Maybe it doesn't for those devices with auto-completion. Cannot test this right now. I tried it once with a Nüvi and it seemed to work well, but I don't own one.
Reg. combination of --road-name-config and --split-name-index: Yes, this gives confusing results. Not sure if it worked better in the past. I tried with Essex extract: java -jar d:\mkgmap\dist\mkgmap.jar --bounds=f:\osm\bounds.zip - -gmapi --net --index --road-name -config=d:\mkgmap\resources\roadNameConfig.txt --gmapsupp --split -name-index f:\dwnload\temp\essex-latest.osm.pbf
According to Mapsource a search for "Mace" without giving a city name should list "John Mace Road", "Mace Avenue", "Mace Court", and "Mace Walk", maybe in a different order. Without your patch I get a list showing "Mace Road", "Mace Avenue", and "Mace Walk", so "Mace Court" is missing and when I select "Mace Road" the device shows the "John Mace Road". With your patch this gets worse: The list shows only "Mace Road", when I select that entry I get a new list containing ",Thurrock","Braintree,Essex","Chelmsford,Essex", and "Colchester, Essex". Each of them points to just one of the expected roads.
Results look much better when I specify a city name. Result also looks very different without the --split-name-option. I have to do more tests, I think it worked better in the past. Maybe sorting is broken.
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi Ticker, You say you don't like the result. Does that mean you like it more with your long list of suffixes than with the short one? I worry about road names like "The Parade". I didn't try it again but I think the suffixes are assumed to have no meaning without other words . In Germany, you rarely find a road with the suffix "Straße" that has a name like "Die Straße". I think it would be better to remove the defaults for GBR and wait until someone says that they are missing it. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 16. April 2020 13:09 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] [Fwd: Re: Suggestions for roadNameConfig.txt] Hi Gerd I did think about this, but --road-names-config is optional and behaves as the documentation suggests and this patch includes a reasonably complete list of suffixes for the UK and useful comments. I tried it on my device and didn't like the effect and so don't use it, Others might like it. I've fixed Boulevard. Ticker On Thu, 2020-04-16 at 09:04 +0000, Gerd Petermann wrote:
Hi Ticker,
did you consider disabling this feature for the UK? It looks wrong to me to have such a long list of rather meaningful names.
BTW: Boulivard is probably a typo?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 16. April 2020 10:35 An: mkgmap development Betreff: [mkgmap-dev] [Fwd: Re: Suggestions for roadNameConfig.txt]
Hi Gerd
Could you consider this change to roadNameConfig.txt for GBR
I've attached an updated version based current trunk.o1
Thank you Ticker
-------- Forwarded Message -------- From: Ticker Berkin <rwb-mkgmap@jagit.co.uk> Reply-to: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk
To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] Suggestions for roadNameConfig.txt Date: Thu, 23 Jan 2020 16:56:17 +0000
Hi Gerd
I've just been going through some old mails/patches.
I think the updated contents of roadNameConfig.txt is correct and better than the previous version.
The fact that it doesn't work consistently across devices and, on some, is misleading shouldn't stop the file being available as an example in the distribution.
The user has the choice about how to use it and it contains some comments and a link relating to these problems.
I've attached an updated patch with UTF-8 encoding markers, a different section for UK road names and improved some comments.
This file has always been read by mkgmap as UTF-8. The function of the markers is to make editors aware of this; it contains characters outside the 7-bit ascii range.
Ticker
On Mon, 2019-12-16 at 11:30 +0000, Gerd Petermann wrote:
Hi Ticker,
reg. search: You are probably right, address search works very different on the Garmin devices. On the Oregon, I have several dialogs, first to chose country, next to chose city or "all", next to type house number, last one asking for road name. In this dialog there is no autocompletion, I just have to type characters. Sometimes the device switches automatically to a result list while I am typing, sometimes it doesn't. When I press OK I get a list of matching roads. So, for the Oregon it works fine. Maybe it doesn't for those devices with auto-completion. Cannot test this right now. I tried it once with a Nüvi and it seemed to work well, but I don't own one.
Reg. combination of --road-name-config and --split-name-index: Yes, this gives confusing results. Not sure if it worked better in the past. I tried with Essex extract: java -jar d:\mkgmap\dist\mkgmap.jar --bounds=f:\osm\bounds.zip - -gmapi --net --index --road-name -config=d:\mkgmap\resources\roadNameConfig.txt --gmapsupp --split -name-index f:\dwnload\temp\essex-latest.osm.pbf
According to Mapsource a search for "Mace" without giving a city name should list "John Mace Road", "Mace Avenue", "Mace Court", and "Mace Walk", maybe in a different order. Without your patch I get a list showing "Mace Road", "Mace Avenue", and "Mace Walk", so "Mace Court" is missing and when I select "Mace Road" the device shows the "John Mace Road". With your patch this gets worse: The list shows only "Mace Road", when I select that entry I get a new list containing ",Thurrock","Braintree,Essex","Chelmsford,Essex", and "Colchester, Essex". Each of them points to just one of the expected roads.
Results look much better when I specify a city name. Result also looks very different without the --split-name-option. I have to do more tests, I think it worked better in the past. Maybe sorting is broken.
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi Gerd To be used for GBR, the prefix list need to different (actually empty), compared with some other English speaking countries and my patch includes this change and comments on the reason for it. Then, in GBR, there are many suffixes, and again, I've generated and included a comprehensive list. Finally, actually using this on my 2 different eTrex devices, the effects made address searching less obvious, in different ways, on the 2 devices. I put a reference to a post about this in the file. Other devices might behave in what I would consider a better way, or other people might consider the behaviour I see as perfectly acceptable. I could comment out the suffix list for GBR, leaving both lists empty, but it is easier not to use --road-name-config. I don't understand your reluctance to accept these changes. Ticker On Thu, 2020-04-16 at 11:28 +0000, Gerd Petermann wrote:
Hi Ticker,
You say you don't like the result. Does that mean you like it more with your long list of suffixes than with the short one? I worry about road names like "The Parade". I didn't try it again but I think the suffixes are assumed to have no meaning without other words . In Germany, you rarely find a road with the suffix "Straße" that has a name like "Die Straße".
I think it would be better to remove the defaults for GBR and wait until someone says that they are missing it.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 16. April 2020 13:09 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] [Fwd: Re: Suggestions for roadNameConfig.txt]
Hi Gerd
I did think about this, but --road-names-config is optional and behaves as the documentation suggests and this patch includes a reasonably complete list of suffixes for the UK and useful comments.
I tried it on my device and didn't like the effect and so don't use it, Others might like it.
I've fixed Boulevard.
Ticker
On Thu, 2020-04-16 at 09:04 +0000, Gerd Petermann wrote:
Hi Ticker,
did you consider disabling this feature for the UK? It looks wrong to me to have such a long list of rather meaningful names.
BTW: Boulivard is probably a typo?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 16. April 2020 10:35 An: mkgmap development Betreff: [mkgmap-dev] [Fwd: Re: Suggestions for roadNameConfig.txt]
Hi Gerd
Could you consider this change to roadNameConfig.txt for GBR
I've attached an updated version based current trunk.o1
Thank you Ticker
-------- Forwarded Message -------- From: Ticker Berkin <rwb-mkgmap@jagit.co.uk> Reply-to: Development list for mkgmap < mkgmap-dev@lists.mkgmap.org.uk
To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] Suggestions for roadNameConfig.txt Date: Thu, 23 Jan 2020 16:56:17 +0000
Hi Gerd
I've just been going through some old mails/patches.
I think the updated contents of roadNameConfig.txt is correct and better than the previous version.
The fact that it doesn't work consistently across devices and, on some, is misleading shouldn't stop the file being available as an example in the distribution.
The user has the choice about how to use it and it contains some comments and a link relating to these problems.
I've attached an updated patch with UTF-8 encoding markers, a different section for UK road names and improved some comments.
This file has always been read by mkgmap as UTF-8. The function of the markers is to make editors aware of this; it contains characters outside the 7-bit ascii range.
Ticker
On Mon, 2019-12-16 at 11:30 +0000, Gerd Petermann wrote:
Hi Ticker,
reg. search: You are probably right, address search works very different on the Garmin devices. On the Oregon, I have several dialogs, first to chose country, next to chose city or "all", next to type house number, last one asking for road name. In this dialog there is no autocompletion, I just have to type characters. Sometimes the device switches automatically to a result list while I am typing, sometimes it doesn't. When I press OK I get a list of matching roads. So, for the Oregon it works fine. Maybe it doesn't for those devices with auto-completion. Cannot test this right now. I tried it once with a Nüvi and it seemed to work well, but I don't own one.
Reg. combination of --road-name-config and --split-name-index: Yes, this gives confusing results. Not sure if it worked better in the past. I tried with Essex extract: java -jar d:\mkgmap\dist\mkgmap.jar --bounds=f:\osm\bounds.zip - -gmapi --net --index --road-name -config=d:\mkgmap\resources\roadNameConfig.txt --gmapsupp --split -name-index f:\dwnload\temp\essex-latest.osm.pbf
According to Mapsource a search for "Mace" without giving a city name should list "John Mace Road", "Mace Avenue", "Mace Court", and "Mace Walk", maybe in a different order. Without your patch I get a list showing "Mace Road", "Mace Avenue", and "Mace Walk", so "Mace Court" is missing and when I select "Mace Road" the device shows the "John Mace Road". With your patch this gets worse: The list shows only "Mace Road", when I select that entry I get a new list containing ",Thurrock","Braintree,Essex","Chelmsford,Essex", and "Colchester, Essex". Each of them points to just one of the expected roads.
Results look much better when I specify a city name. Result also looks very different without the --split-name-option. I have to do more tests, I think it worked better in the past. Maybe sorting is broken.
Gerd
_______________________________________________ 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

I don't understand your reluctance to accept these changes. When I added the code for option --road-name-config I was already unsure if this feature makes sense in countries with English or German road names or more generally speaking if it makes sense with suffixes. I think it can help for latin based languages like Frensh, Italian, Portugese, Spanish, and alike, but also only without --split-name-index.
Your long list somehow implies that the feature works well when you add lots of possible suffixes, I think it only works well the list is short. Since we both don't like the results of the function I'd prefer to comment the lists. Would be good to know if those how contributed to it (Alexandre Folle de Menezes and Carlos Davida) use it with Maps for the UK. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 17. April 2020 10:13 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] [Fwd: Re: Suggestions for roadNameConfig.txt] Hi Gerd To be used for GBR, the prefix list need to different (actually empty), compared with some other English speaking countries and my patch includes this change and comments on the reason for it. Then, in GBR, there are many suffixes, and again, I've generated and included a comprehensive list. Finally, actually using this on my 2 different eTrex devices, the effects made address searching less obvious, in different ways, on the 2 devices. I put a reference to a post about this in the file. Other devices might behave in what I would consider a better way, or other people might consider the behaviour I see as perfectly acceptable. I could comment out the suffix list for GBR, leaving both lists empty, but it is easier not to use --road-name-config. I don't understand your reluctance to accept these changes. Ticker On Thu, 2020-04-16 at 11:28 +0000, Gerd Petermann wrote:
Hi Ticker,
You say you don't like the result. Does that mean you like it more with your long list of suffixes than with the short one? I worry about road names like "The Parade". I didn't try it again but I think the suffixes are assumed to have no meaning without other words . In Germany, you rarely find a road with the suffix "Straße" that has a name like "Die Straße".
I think it would be better to remove the defaults for GBR and wait until someone says that they are missing it.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 16. April 2020 13:09 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] [Fwd: Re: Suggestions for roadNameConfig.txt]
Hi Gerd
I did think about this, but --road-names-config is optional and behaves as the documentation suggests and this patch includes a reasonably complete list of suffixes for the UK and useful comments.
I tried it on my device and didn't like the effect and so don't use it, Others might like it.
I've fixed Boulevard.
Ticker
On Thu, 2020-04-16 at 09:04 +0000, Gerd Petermann wrote:
Hi Ticker,
did you consider disabling this feature for the UK? It looks wrong to me to have such a long list of rather meaningful names.
BTW: Boulivard is probably a typo?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 16. April 2020 10:35 An: mkgmap development Betreff: [mkgmap-dev] [Fwd: Re: Suggestions for roadNameConfig.txt]
Hi Gerd
Could you consider this change to roadNameConfig.txt for GBR
I've attached an updated version based current trunk.o1
Thank you Ticker
-------- Forwarded Message -------- From: Ticker Berkin <rwb-mkgmap@jagit.co.uk> Reply-to: Development list for mkgmap < mkgmap-dev@lists.mkgmap.org.uk
To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] Suggestions for roadNameConfig.txt Date: Thu, 23 Jan 2020 16:56:17 +0000
Hi Gerd
I've just been going through some old mails/patches.
I think the updated contents of roadNameConfig.txt is correct and better than the previous version.
The fact that it doesn't work consistently across devices and, on some, is misleading shouldn't stop the file being available as an example in the distribution.
The user has the choice about how to use it and it contains some comments and a link relating to these problems.
I've attached an updated patch with UTF-8 encoding markers, a different section for UK road names and improved some comments.
This file has always been read by mkgmap as UTF-8. The function of the markers is to make editors aware of this; it contains characters outside the 7-bit ascii range.
Ticker
On Mon, 2019-12-16 at 11:30 +0000, Gerd Petermann wrote:
Hi Ticker,
reg. search: You are probably right, address search works very different on the Garmin devices. On the Oregon, I have several dialogs, first to chose country, next to chose city or "all", next to type house number, last one asking for road name. In this dialog there is no autocompletion, I just have to type characters. Sometimes the device switches automatically to a result list while I am typing, sometimes it doesn't. When I press OK I get a list of matching roads. So, for the Oregon it works fine. Maybe it doesn't for those devices with auto-completion. Cannot test this right now. I tried it once with a Nüvi and it seemed to work well, but I don't own one.
Reg. combination of --road-name-config and --split-name-index: Yes, this gives confusing results. Not sure if it worked better in the past. I tried with Essex extract: java -jar d:\mkgmap\dist\mkgmap.jar --bounds=f:\osm\bounds.zip - -gmapi --net --index --road-name -config=d:\mkgmap\resources\roadNameConfig.txt --gmapsupp --split -name-index f:\dwnload\temp\essex-latest.osm.pbf
According to Mapsource a search for "Mace" without giving a city name should list "John Mace Road", "Mace Avenue", "Mace Court", and "Mace Walk", maybe in a different order. Without your patch I get a list showing "Mace Road", "Mace Avenue", and "Mace Walk", so "Mace Court" is missing and when I select "Mace Road" the device shows the "John Mace Road". With your patch this gets worse: The list shows only "Mace Road", when I select that entry I get a new list containing ",Thurrock","Braintree,Essex","Chelmsford,Essex", and "Colchester, Essex". Each of them points to just one of the expected roads.
Results look much better when I specify a city name. Result also looks very different without the --split-name-option. I have to do more tests, I think it worked better in the past. Maybe sorting is broken.
Gerd
_______________________________________________ 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 Here is a patch with the GBR suffixes commented out. Ticker On Fri, 2020-04-17 at 08:39 +0000, Gerd Petermann wrote:
I don't understand your reluctance to accept these changes. When I added the code for option --road-name-config I was already unsure if this feature makes sense in countries with English or German road names or more generally speaking if it makes sense with suffixes. I think it can help for latin based languages like Frensh, Italian, Portugese, Spanish, and alike, but also only without --split-name -index.
Your long list somehow implies that the feature works well when you add lots of possible suffixes, I think it only works well the list is short. Since we both don't like the results of the function I'd prefer to comment the lists.
Would be good to know if those how contributed to it (Alexandre Folle de Menezes and Carlos Davida) use it with Maps for the UK.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 17. April 2020 10:13 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] [Fwd: Re: Suggestions for roadNameConfig.txt]
Hi Gerd
To be used for GBR, the prefix list need to different (actually empty), compared with some other English speaking countries and my patch includes this change and comments on the reason for it.
Then, in GBR, there are many suffixes, and again, I've generated and included a comprehensive list.
Finally, actually using this on my 2 different eTrex devices, the effects made address searching less obvious, in different ways, on the 2 devices. I put a reference to a post about this in the file.
Other devices might behave in what I would consider a better way, or other people might consider the behaviour I see as perfectly acceptable.
I could comment out the suffix list for GBR, leaving both lists empty, but it is easier not to use --road-name-config.
I don't understand your reluctance to accept these changes.
Ticker
On Thu, 2020-04-16 at 11:28 +0000, Gerd Petermann wrote:
Hi Ticker,
You say you don't like the result. Does that mean you like it more with your long list of suffixes than with the short one? I worry about road names like "The Parade". I didn't try it again but I think the suffixes are assumed to have no meaning without other words . In Germany, you rarely find a road with the suffix "Straße" that has a name like "Die Straße".
I think it would be better to remove the defaults for GBR and wait until someone says that they are missing it.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 16. April 2020 13:09 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] [Fwd: Re: Suggestions for roadNameConfig.txt]
Hi Gerd
I did think about this, but --road-names-config is optional and behaves as the documentation suggests and this patch includes a reasonably complete list of suffixes for the UK and useful comments.
I tried it on my device and didn't like the effect and so don't use it, Others might like it.
I've fixed Boulevard.
Ticker
On Thu, 2020-04-16 at 09:04 +0000, Gerd Petermann wrote:
Hi Ticker,
did you consider disabling this feature for the UK? It looks wrong to me to have such a long list of rather meaningful names.
BTW: Boulivard is probably a typo?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 16. April 2020 10:35 An: mkgmap development Betreff: [mkgmap-dev] [Fwd: Re: Suggestions for roadNameConfig.txt]
Hi Gerd
Could you consider this change to roadNameConfig.txt for GBR
I've attached an updated version based current trunk.o1
Thank you Ticker
-------- Forwarded Message -------- From: Ticker Berkin <rwb-mkgmap@jagit.co.uk> Reply-to: Development list for mkgmap < mkgmap-dev@lists.mkgmap.org.uk
To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] Suggestions for roadNameConfig.txt Date: Thu, 23 Jan 2020 16:56:17 +0000
Hi Gerd
I've just been going through some old mails/patches.
I think the updated contents of roadNameConfig.txt is correct and better than the previous version.
The fact that it doesn't work consistently across devices and, on some, is misleading shouldn't stop the file being available as an example in the distribution.
The user has the choice about how to use it and it contains some comments and a link relating to these problems.
I've attached an updated patch with UTF-8 encoding markers, a different section for UK road names and improved some comments.
This file has always been read by mkgmap as UTF-8. The function of the markers is to make editors aware of this; it contains characters outside the 7-bit ascii range.
Ticker
On Mon, 2019-12-16 at 11:30 +0000, Gerd Petermann wrote:
Hi Ticker,
reg. search: You are probably right, address search works very different on the Garmin devices. On the Oregon, I have several dialogs, first to chose country, next to chose city or "all", next to type house number, last one asking for road name. In this dialog there is no autocompletion, I just have to type characters. Sometimes the device switches automatically to a result list while I am typing, sometimes it doesn't. When I press OK I get a list of matching roads. So, for the Oregon it works fine. Maybe it doesn't for those devices with auto-completion. Cannot test this right now. I tried it once with a Nüvi and it seemed to work well, but I don't own one.
Reg. combination of --road-name-config and --split-name -index: Yes, this gives confusing results. Not sure if it worked better in the past. I tried with Essex extract: java -jar d:\mkgmap\dist\mkgmap.jar --bounds=f:\osm\bounds.zip - -gmapi --net --index --road-name -config=d:\mkgmap\resources\roadNameConfig.txt --gmapsupp - -split -name-index f:\dwnload\temp\essex-latest.osm.pbf
According to Mapsource a search for "Mace" without giving a city name should list "John Mace Road", "Mace Avenue", "Mace Court", and "Mace Walk", maybe in a different order. Without your patch I get a list showing "Mace Road", "Mace Avenue", and "Mace Walk", so "Mace Court" is missing and when I select "Mace Road" the device shows the "John Mace Road". With your patch this gets worse: The list shows only "Mace Road", when I select that entry I get a new list containing ",Thurrock","Braintree,Essex","Chelmsford,Essex", and "Colchester, Essex". Each of them points to just one of the expected roads.
Results look much better when I specify a city name. Result also looks very different without the --split-name -option. I have to do more tests, I think it worked better in the past. Maybe sorting is broken.
Gerd
_______________________________________________ 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 Ticker, It may be worth adding the following to Section 2: lang:BWA = en lang:KEN = en lang:MWI = en lang:ZMB = en lang:ZWE = en They are Botswana, Kenya, Malawi, Zambia and Zimbabwe. Owing to their colonial past the still have a similar naming format to the UK and roads with similar suffixes such as Avenue, Boulevard, Close, Crescent, Drive and Way will be found. Lusaka still has a Birdcage Walk. Dave -----Original Message----- From: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> On Behalf Of Ticker Berkin Sent: 27 April 2020 15:20 To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] [Fwd: Re: Suggestions for roadNameConfig.txt] Hi Gerd Could you apply this patch Thanks Ticker On Fri, 2020-04-17 at 10:18 +0100, Ticker Berkin wrote:
Hi Gerd
Here is a patch with the GBR suffixes commented out.
Ticker

Hi Ticker, I've attached a slightly modified version which I would accept. My understanding is that the user must know the common suffixes configured in the list when searching for roads. The long list is much too long to remember. So, I'd prefer to omit the list and just explain that the use of --road-name-config makes no sense in the UK. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Montag, 27. April 2020 15:20 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] [Fwd: Re: Suggestions for roadNameConfig.txt] Hi Gerd Could you apply this patch Thanks Ticker On Fri, 2020-04-17 at 10:18 +0100, Ticker Berkin wrote:
Hi Gerd
Here is a patch with the GBR suffixes commented out.
Ticker

Hi Gerd Yes, I'd be happy to accept this. The problem with having suffixes wasn't that "the user must know them when searching for roads". It was that, at least for my eTrex, there is just a single entry in the STREET part of the search for all suffix variants, and then, after selecting that, all address in all variants are given in the result list. I've included Dave's additions for mapping some Africa countries to en_gb in an updated patch. Ticker On Mon, 2020-04-27 at 13:54 +0000, Gerd Petermann wrote:
Hi Ticker,
I've attached a slightly modified version which I would accept. My understanding is that the user must know the common suffixes configured in the list when searching for roads. The long list is much too long to remember. So, I'd prefer to omit the list and just explain that the use of - -road-name-config makes no sense in the UK.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Montag, 27. April 2020 15:20 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] [Fwd: Re: Suggestions for roadNameConfig.txt]
Hi Gerd
Could you apply this patch
Thanks Ticker
On Fri, 2020-04-17 at 10:18 +0100, Ticker Berkin wrote:
Hi Gerd
Here is a patch with the GBR suffixes commented out.
Ticker
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi Ticker I agree that at times the effect is strange, particularly with short road names I have instead created my own list and only apply the abbreviation if the road name is over a certain length. So Oak street does not become Oak St which looks very odd Unfortunately I could not find a 'len' command to establish the length of a string - is there one? Instead I have to check if a road name has a character at a certain position in the string. r Nick On 16/04/2020 12:09, Ticker Berkin wrote:
Hi Gerd
I did think about this, but --road-names-config is optional and behaves as the documentation suggests and this patch includes a reasonably complete list of suffixes for the UK and useful comments.
I tried it on my device and didn't like the effect and so don't use it, Others might like it.
I've fixed Boulevard.
Ticker
On Thu, 2020-04-16 at 09:04 +0000, Gerd Petermann wrote:
Hi Ticker,
did you consider disabling this feature for the UK? It looks wrong to me to have such a long list of rather meaningful names.
BTW: Boulivard is probably a typo?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 16. April 2020 10:35 An: mkgmap development Betreff: [mkgmap-dev] [Fwd: Re: Suggestions for roadNameConfig.txt]
Hi Gerd
Could you consider this change to roadNameConfig.txt for GBR
I've attached an updated version based current trunk.o1
Thank you Ticker
-------- Forwarded Message -------- From: Ticker Berkin <rwb-mkgmap@jagit.co.uk> Reply-to: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] Suggestions for roadNameConfig.txt Date: Thu, 23 Jan 2020 16:56:17 +0000
Hi Gerd
I've just been going through some old mails/patches.
I think the updated contents of roadNameConfig.txt is correct and better than the previous version.
The fact that it doesn't work consistently across devices and, on some, is misleading shouldn't stop the file being available as an example in the distribution.
The user has the choice about how to use it and it contains some comments and a link relating to these problems.
I've attached an updated patch with UTF-8 encoding markers, a different section for UK road names and improved some comments.
This file has always been read by mkgmap as UTF-8. The function of the markers is to make editors aware of this; it contains characters outside the 7-bit ascii range.
Ticker
On Mon, 2019-12-16 at 11:30 +0000, Gerd Petermann wrote:
Hi Ticker,
reg. search: You are probably right, address search works very different on the Garmin devices. On the Oregon, I have several dialogs, first to chose country, next to chose city or "all", next to type house number, last one asking for road name. In this dialog there is no autocompletion, I just have to type characters. Sometimes the device switches automatically to a result list while I am typing, sometimes it doesn't. When I press OK I get a list of matching roads. So, for the Oregon it works fine. Maybe it doesn't for those devices with auto-completion. Cannot test this right now. I tried it once with a Nüvi and it seemed to work well, but I don't own one.
Reg. combination of --road-name-config and --split-name-index: Yes, this gives confusing results. Not sure if it worked better in the past. I tried with Essex extract: java -jar d:\mkgmap\dist\mkgmap.jar --bounds=f:\osm\bounds.zip - -gmapi --net --index --road-name -config=d:\mkgmap\resources\roadNameConfig.txt --gmapsupp --split -name-index f:\dwnload\temp\essex-latest.osm.pbf
According to Mapsource a search for "Mace" without giving a city name should list "John Mace Road", "Mace Avenue", "Mace Court", and "Mace Walk", maybe in a different order. Without your patch I get a list showing "Mace Road", "Mace Avenue", and "Mace Walk", so "Mace Court" is missing and when I select "Mace Road" the device shows the "John Mace Road". With your patch this gets worse: The list shows only "Mace Road", when I select that entry I get a new list containing ",Thurrock","Braintree,Essex","Chelmsford,Essex", and "Colchester, Essex". Each of them points to just one of the expected roads.
Results look much better when I specify a city name. Result also looks very different without the --split-name-option. I have to do more tests, I think it worked better in the past. Maybe sorting is broken.
Gerd
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 Nick, I don't understand this comment. The roadNameConfig.txt is not about abbreviations. I don't know a simple method to find the length of a string but a regex could be used to find out if it is at least n characters. Something like str ~ '.{10}.*' should only match for strings with at least 10 characters. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Pinns UK <osm@pinns.co.uk> Gesendet: Donnerstag, 16. April 2020 14:18 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] [Fwd: Re: Suggestions for roadNameConfig.txt] Hi Ticker I agree that at times the effect is strange, particularly with short road names I have instead created my own list and only apply the abbreviation if the road name is over a certain length. So Oak street does not become Oak St which looks very odd Unfortunately I could not find a 'len' command to establish the length of a string - is there one? Instead I have to check if a road name has a character at a certain position in the string. r Nick On 16/04/2020 12:09, Ticker Berkin wrote: Hi Gerd I did think about this, but --road-names-config is optional and behaves as the documentation suggests and this patch includes a reasonably complete list of suffixes for the UK and useful comments. I tried it on my device and didn't like the effect and so don't use it, Others might like it. I've fixed Boulevard. Ticker On Thu, 2020-04-16 at 09:04 +0000, Gerd Petermann wrote: Hi Ticker, did you consider disabling this feature for the UK? It looks wrong to me to have such a long list of rather meaningful names. BTW: Boulivard is probably a typo? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 16. April 2020 10:35 An: mkgmap development Betreff: [mkgmap-dev] [Fwd: Re: Suggestions for roadNameConfig.txt] Hi Gerd Could you consider this change to roadNameConfig.txt for GBR I've attached an updated version based current trunk.o1 Thank you Ticker -------- Forwarded Message -------- From: Ticker Berkin <rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk> Reply-to: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] Suggestions for roadNameConfig.txt Date: Thu, 23 Jan 2020 16:56:17 +0000 Hi Gerd I've just been going through some old mails/patches. I think the updated contents of roadNameConfig.txt is correct and better than the previous version. The fact that it doesn't work consistently across devices and, on some, is misleading shouldn't stop the file being available as an example in the distribution. The user has the choice about how to use it and it contains some comments and a link relating to these problems. I've attached an updated patch with UTF-8 encoding markers, a different section for UK road names and improved some comments. This file has always been read by mkgmap as UTF-8. The function of the markers is to make editors aware of this; it contains characters outside the 7-bit ascii range. Ticker On Mon, 2019-12-16 at 11:30 +0000, Gerd Petermann wrote: Hi Ticker, reg. search: You are probably right, address search works very different on the Garmin devices. On the Oregon, I have several dialogs, first to chose country, next to chose city or "all", next to type house number, last one asking for road name. In this dialog there is no autocompletion, I just have to type characters. Sometimes the device switches automatically to a result list while I am typing, sometimes it doesn't. When I press OK I get a list of matching roads. So, for the Oregon it works fine. Maybe it doesn't for those devices with auto-completion. Cannot test this right now. I tried it once with a Nüvi and it seemed to work well, but I don't own one. Reg. combination of --road-name-config and --split-name-index: Yes, this gives confusing results. Not sure if it worked better in the past. I tried with Essex extract: java -jar d:\mkgmap\dist\mkgmap.jar --bounds=f:\osm\bounds.zip - -gmapi --net --index --road-name -config=d:\mkgmap\resources\roadNameConfig.txt --gmapsupp --split -name-index f:\dwnload\temp\essex-latest.osm.pbf According to Mapsource a search for "Mace" without giving a city name should list "John Mace Road", "Mace Avenue", "Mace Court", and "Mace Walk", maybe in a different order. Without your patch I get a list showing "Mace Road", "Mace Avenue", and "Mace Walk", so "Mace Court" is missing and when I select "Mace Road" the device shows the "John Mace Road". With your patch this gets worse: The list shows only "Mace Road", when I select that entry I get a new list containing ",Thurrock","Braintree,Essex","Chelmsford,Essex", and "Colchester, Essex". Each of them points to just one of the expected roads. Results look much better when I specify a city name. Result also looks very different without the --split-name-option. I have to do more tests, I think it worked better in the past. Maybe sorting is broken. Gerd _______________________________________________ mkgmap-dev mailing list 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@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (4)
-
Dave
-
Gerd Petermann
-
Pinns UK
-
Ticker Berkin