Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases
Even though Gerd also speaks German, I think its better to continue in English. I am quite sure that this is the same bug then. Your map does not crash because it find another POI first. I also sometimes have two POI for the same thing - one for finding it via a category POI search, the other for the symbol in the map. I do wonder if you have two POI the order in the style matters? If you change the order they are created - does it crash? Could it be that only 0x1234 POI are affected, but the newer 0x12345 types not? As soon as it finds 0x12345 it does not crash? Lets take Verbier Village - it is not a ciy POI https://www.openstreetmap.org/node/8307159228 I use: highway=bus_stop | amenity=bus_stop | highway=busstop | amenity=busstop | railway=bus_stop {set name='bus_stop ${name}' | 'bus_stop' } [0x2f17 resolution 24] for that one. Cold de Jaman https://www.openstreetmap.org/node/1437437792 I have the rule: 0x1c01 resolution 24 continue] [0x11607 resolution 20-21 continue] [0x1151f resolution 22-22 continue [0x1151f resolution 23-24]] However the first one in my map obviously is 0x1c01 - an old type. The other ones are a bit bad examples I noticed - because there exists several entries in osm data that could be found with identical name. However I have found no actual city only poi where it crashes - Saas Fee also has other POI named the same. So maybe they cause a crash. On Wed, 2 Jun 2021 at 10:25, Thomas Morgenstern <webmaster@img2ms.de> wrote:
Kann sein, dass es am Style liegt. Ich nutze meinen eigenen Style, der z.B einen zusätzlichen POI für Städte einfügt. ich fand vor geraumer Zeit, dass Städte in der MDR nicht eingebbar sind, wenn der String Leerzeichen enthält. Dazu hatte ich auch in der mailinglist gepostet. Hr.Petermann sagte damals, das die MDR für Städte aber nicht anpassbar sei. deshalb hat bei mir jede Stadt noch einen zusätzlichen POI einer anderen Kategorie. mfg
Am 02.06.2021 um 09:07 schrieb Felix Hartmann:
Very strange - I also tested this on "Frezeitkarte" Schweiz and it crashed too. It usually does not crash if you before had a non crash search.
On Wed, 2 Jun 2021 at 08:35, Thomas Morgenstern <webmaster@img2ms.de> wrote:
Kann ich nicht bestätigen, alle hier genannten Suchen sind erfolgreich ohne Abstutz. BC Ver 4.7.0 und eigene OSM map mfg
Am 01.06.2021 um 22:32 schrieb Felix Hartmann:
A user of my maps just told me that there are some crashes in the Basecamp search. There is a clear pattern - only search phrases of minimum 2 words with a space between cause crashes.
I tested it on my maps, and on other mkgmap created maps and the crashes are more or less happening on all maps.
For Switzerland some places causing crashes: Verbier Village Saas Fee Col de Jaman Pic chaussy Pic chosy
Also 2) the search must be the first from BC execution 3) if a good search already has been executed (single word), then the crash rarely occurs
Not happening with Garmin's own maps. The more entries (POIs) of the name exist - the more likely? Seems to happen more often in the French part of Switzerland compared to the Garmin part. But as many words like Saas Fee do not contain any special characters - I do not think it is related to any codepage problem. -- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing listmkgmap-dev@lists.mkgmap.org.ukhttps://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
I just thought about it - could it be related to multi word street search? Maybe what works for multi word street search is not possible for old type POI search? So it is the multi word stuff that got introduced for roads that causes the crashes in Basecamp (not sure about what happens on devices - will check that out later). --add-pois-to-areas --pois-to-areas-placement=entrance=main;entrance=yes;building=entrance;barrier=entrance --link-pois-to-ways --location-autofill=bounds,is_in,nearest and of coure --index are the most relevant to this thread options I am using. On Wed, 2 Jun 2021 at 10:49, Felix Hartmann <extremecarver@gmail.com> wrote:
Even though Gerd also speaks German, I think its better to continue in English. I am quite sure that this is the same bug then. Your map does not crash because it find another POI first. I also sometimes have two POI for the same thing - one for finding it via a category POI search, the other for the symbol in the map. I do wonder if you have two POI the order in the style matters? If you change the order they are created - does it crash?
Could it be that only 0x1234 POI are affected, but the newer 0x12345 types not? As soon as it finds 0x12345 it does not crash?
Lets take Verbier Village - it is not a ciy POI https://www.openstreetmap.org/node/8307159228
I use: highway=bus_stop | amenity=bus_stop | highway=busstop | amenity=busstop | railway=bus_stop {set name='bus_stop ${name}' | 'bus_stop' } [0x2f17 resolution 24] for that one.
Cold de Jaman https://www.openstreetmap.org/node/1437437792 I have the rule: 0x1c01 resolution 24 continue] [0x11607 resolution 20-21 continue] [0x1151f resolution 22-22 continue [0x1151f resolution 23-24]]
However the first one in my map obviously is 0x1c01 - an old type.
The other ones are a bit bad examples I noticed - because there exists several entries in osm data that could be found with identical name. However I have found no actual city only poi where it crashes - Saas Fee also has other POI named the same. So maybe they cause a crash.
On Wed, 2 Jun 2021 at 10:25, Thomas Morgenstern <webmaster@img2ms.de> wrote:
Kann sein, dass es am Style liegt. Ich nutze meinen eigenen Style, der z.B einen zusätzlichen POI für Städte einfügt. ich fand vor geraumer Zeit, dass Städte in der MDR nicht eingebbar sind, wenn der String Leerzeichen enthält. Dazu hatte ich auch in der mailinglist gepostet. Hr.Petermann sagte damals, das die MDR für Städte aber nicht anpassbar sei. deshalb hat bei mir jede Stadt noch einen zusätzlichen POI einer anderen Kategorie. mfg
Am 02.06.2021 um 09:07 schrieb Felix Hartmann:
Very strange - I also tested this on "Frezeitkarte" Schweiz and it crashed too. It usually does not crash if you before had a non crash search.
On Wed, 2 Jun 2021 at 08:35, Thomas Morgenstern <webmaster@img2ms.de> wrote:
Kann ich nicht bestätigen, alle hier genannten Suchen sind erfolgreich ohne Abstutz. BC Ver 4.7.0 und eigene OSM map mfg
Am 01.06.2021 um 22:32 schrieb Felix Hartmann:
A user of my maps just told me that there are some crashes in the Basecamp search. There is a clear pattern - only search phrases of minimum 2 words with a space between cause crashes.
I tested it on my maps, and on other mkgmap created maps and the crashes are more or less happening on all maps.
For Switzerland some places causing crashes: Verbier Village Saas Fee Col de Jaman Pic chaussy Pic chosy
Also 2) the search must be the first from BC execution 3) if a good search already has been executed (single word), then the crash rarely occurs
Not happening with Garmin's own maps. The more entries (POIs) of the name exist - the more likely? Seems to happen more often in the French part of Switzerland compared to the Garmin part. But as many words like Saas Fee do not contain any special characters - I do not think it is related to any codepage problem. -- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing listmkgmap-dev@lists.mkgmap.org.ukhttps://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
https://www.openstreetmap.org/node/3268115540 shop=hardware | shop=trade [0x2e01 resolution 24] does not crash - it has a full address field. Maybe if we have address for a POI it does not crash? I have to look but I think so far only entries without an address cause a crash. Also it does not crash if being nearby and only searching for one of the words of the entry thereby finding it. On Wed, 2 Jun 2021 at 11:08, Felix Hartmann <extremecarver@gmail.com> wrote:
I just thought about it - could it be related to multi word street search? Maybe what works for multi word street search is not possible for old type POI search? So it is the multi word stuff that got introduced for roads that causes the crashes in Basecamp (not sure about what happens on devices - will check that out later). --add-pois-to-areas --pois-to-areas-placement=entrance=main;entrance=yes;building=entrance;barrier=entrance --link-pois-to-ways --location-autofill=bounds,is_in,nearest and of coure --index are the most relevant to this thread options I am using.
On Wed, 2 Jun 2021 at 10:49, Felix Hartmann <extremecarver@gmail.com> wrote:
Even though Gerd also speaks German, I think its better to continue in English. I am quite sure that this is the same bug then. Your map does not crash because it find another POI first. I also sometimes have two POI for the same thing - one for finding it via a category POI search, the other for the symbol in the map. I do wonder if you have two POI the order in the style matters? If you change the order they are created - does it crash?
Could it be that only 0x1234 POI are affected, but the newer 0x12345 types not? As soon as it finds 0x12345 it does not crash?
Lets take Verbier Village - it is not a ciy POI https://www.openstreetmap.org/node/8307159228
I use: highway=bus_stop | amenity=bus_stop | highway=busstop | amenity=busstop | railway=bus_stop {set name='bus_stop ${name}' | 'bus_stop' } [0x2f17 resolution 24] for that one.
Cold de Jaman https://www.openstreetmap.org/node/1437437792 I have the rule: 0x1c01 resolution 24 continue] [0x11607 resolution 20-21 continue] [0x1151f resolution 22-22 continue [0x1151f resolution 23-24]]
However the first one in my map obviously is 0x1c01 - an old type.
The other ones are a bit bad examples I noticed - because there exists several entries in osm data that could be found with identical name. However I have found no actual city only poi where it crashes - Saas Fee also has other POI named the same. So maybe they cause a crash.
On Wed, 2 Jun 2021 at 10:25, Thomas Morgenstern <webmaster@img2ms.de> wrote:
Kann sein, dass es am Style liegt. Ich nutze meinen eigenen Style, der z.B einen zusätzlichen POI für Städte einfügt. ich fand vor geraumer Zeit, dass Städte in der MDR nicht eingebbar sind, wenn der String Leerzeichen enthält. Dazu hatte ich auch in der mailinglist gepostet. Hr.Petermann sagte damals, das die MDR für Städte aber nicht anpassbar sei. deshalb hat bei mir jede Stadt noch einen zusätzlichen POI einer anderen Kategorie. mfg
Am 02.06.2021 um 09:07 schrieb Felix Hartmann:
Very strange - I also tested this on "Frezeitkarte" Schweiz and it crashed too. It usually does not crash if you before had a non crash search.
On Wed, 2 Jun 2021 at 08:35, Thomas Morgenstern <webmaster@img2ms.de> wrote:
Kann ich nicht bestätigen, alle hier genannten Suchen sind erfolgreich ohne Abstutz. BC Ver 4.7.0 und eigene OSM map mfg
Am 01.06.2021 um 22:32 schrieb Felix Hartmann:
A user of my maps just told me that there are some crashes in the Basecamp search. There is a clear pattern - only search phrases of minimum 2 words with a space between cause crashes.
I tested it on my maps, and on other mkgmap created maps and the crashes are more or less happening on all maps.
For Switzerland some places causing crashes: Verbier Village Saas Fee Col de Jaman Pic chaussy Pic chosy
Also 2) the search must be the first from BC execution 3) if a good search already has been executed (single word), then the crash rarely occurs
Not happening with Garmin's own maps. The more entries (POIs) of the name exist - the more likely? Seems to happen more often in the French part of Switzerland compared to the Garmin part. But as many words like Saas Fee do not contain any special characters - I do not think it is related to any codepage problem. -- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing listmkgmap-dev@lists.mkgmap.org.ukhttps://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
Hi Felix, I couldn't reproduce the crash so far. Please provide a small map and exact instructions how to reproduce. What happens when BC crashes? Do you have some kind of report? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Mittwoch, 2. Juni 2021 10:16 An: Thomas Morgenstern; Development list for mkgmap Betreff: Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases https://www.openstreetmap.org/node/3268115540 shop=hardware | shop=trade [0x2e01 resolution 24] does not crash - it has a full address field. Maybe if we have address for a POI it does not crash? I have to look but I think so far only entries without an address cause a crash. Also it does not crash if being nearby and only searching for one of the words of the entry thereby finding it. On Wed, 2 Jun 2021 at 11:08, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com>> wrote: I just thought about it - could it be related to multi word street search? Maybe what works for multi word street search is not possible for old type POI search? So it is the multi word stuff that got introduced for roads that causes the crashes in Basecamp (not sure about what happens on devices - will check that out later). --add-pois-to-areas --pois-to-areas-placement=entrance=main;entrance=yes;building=entrance;barrier=entrance --link-pois-to-ways --location-autofill=bounds,is_in,nearest and of coure --index are the most relevant to this thread options I am using. On Wed, 2 Jun 2021 at 10:49, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com>> wrote: Even though Gerd also speaks German, I think its better to continue in English. I am quite sure that this is the same bug then. Your map does not crash because it find another POI first. I also sometimes have two POI for the same thing - one for finding it via a category POI search, the other for the symbol in the map. I do wonder if you have two POI the order in the style matters? If you change the order they are created - does it crash? Could it be that only 0x1234 POI are affected, but the newer 0x12345 types not? As soon as it finds 0x12345 it does not crash? Lets take Verbier Village - it is not a ciy POI https://www.openstreetmap.org/node/8307159228 I use: highway=bus_stop | amenity=bus_stop | highway=busstop | amenity=busstop | railway=bus_stop {set name='bus_stop ${name}' | 'bus_stop' } [0x2f17 resolution 24] for that one. Cold de Jaman https://www.openstreetmap.org/node/1437437792 I have the rule: 0x1c01 resolution 24 continue] [0x11607 resolution 20-21 continue] [0x1151f resolution 22-22 continue [0x1151f resolution 23-24]] However the first one in my map obviously is 0x1c01 - an old type. The other ones are a bit bad examples I noticed - because there exists several entries in osm data that could be found with identical name. However I have found no actual city only poi where it crashes - Saas Fee also has other POI named the same. So maybe they cause a crash. On Wed, 2 Jun 2021 at 10:25, Thomas Morgenstern <webmaster@img2ms.de<mailto:webmaster@img2ms.de>> wrote: Kann sein, dass es am Style liegt. Ich nutze meinen eigenen Style, der z.B einen zusätzlichen POI für Städte einfügt. ich fand vor geraumer Zeit, dass Städte in der MDR nicht eingebbar sind, wenn der String Leerzeichen enthält. Dazu hatte ich auch in der mailinglist gepostet. Hr.Petermann sagte damals, das die MDR für Städte aber nicht anpassbar sei. deshalb hat bei mir jede Stadt noch einen zusätzlichen POI einer anderen Kategorie. mfg Am 02.06.2021 um 09:07 schrieb Felix Hartmann: Very strange - I also tested this on "Frezeitkarte" Schweiz and it crashed too. It usually does not crash if you before had a non crash search. On Wed, 2 Jun 2021 at 08:35, Thomas Morgenstern <webmaster@img2ms.de<mailto:webmaster@img2ms.de>> wrote: Kann ich nicht bestätigen, alle hier genannten Suchen sind erfolgreich ohne Abstutz. BC Ver 4.7.0 und eigene OSM map mfg Am 01.06.2021 um 22:32 schrieb Felix Hartmann: A user of my maps just told me that there are some crashes in the Basecamp search. There is a clear pattern - only search phrases of minimum 2 words with a space between cause crashes. I tested it on my maps, and on other mkgmap created maps and the crashes are more or less happening on all maps. For Switzerland some places causing crashes: Verbier Village Saas Fee Col de Jaman Pic chaussy Pic chosy Also 2) the search must be the first from BC execution 3) if a good search already has been executed (single word), then the crash rarely occurs Not happening with Garmin's own maps. The more entries (POIs) of the name exist - the more likely? Seems to happen more often in the French part of Switzerland compared to the Garmin part. But as many words like Saas Fee do not contain any special characters - I do not think it is related to any codepage problem. -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org
Basecamp just closes 0-3 seconds after entering that term into the search bar. No warning, no error notice, nothing. Seems to have been happening a long time already. Okay this evening I will try to produce a map as small as possible that still crashes. I do not have much time now anymore - but will try if removing --split-name-index changes something. I kinda feel it has something to do with split-name-index. On Wed, 2 Jun 2021 at 12:07, Gerd Petermann <gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
I couldn't reproduce the crash so far. Please provide a small map and exact instructions how to reproduce. What happens when BC crashes? Do you have some kind of report?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Mittwoch, 2. Juni 2021 10:16 An: Thomas Morgenstern; Development list for mkgmap Betreff: Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases
https://www.openstreetmap.org/node/3268115540 shop=hardware | shop=trade [0x2e01 resolution 24] does not crash - it has a full address field. Maybe if we have address for a POI it does not crash?
I have to look but I think so far only entries without an address cause a crash. Also it does not crash if being nearby and only searching for one of the words of the entry thereby finding it.
On Wed, 2 Jun 2021 at 11:08, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com>> wrote: I just thought about it - could it be related to multi word street search? Maybe what works for multi word street search is not possible for old type POI search? So it is the multi word stuff that got introduced for roads that causes the crashes in Basecamp (not sure about what happens on devices - will check that out later). --add-pois-to-areas --pois-to-areas-placement=entrance=main;entrance=yes;building=entrance;barrier=entrance --link-pois-to-ways --location-autofill=bounds,is_in,nearest and of coure --index are the most relevant to this thread options I am using.
On Wed, 2 Jun 2021 at 10:49, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com>> wrote: Even though Gerd also speaks German, I think its better to continue in English. I am quite sure that this is the same bug then. Your map does not crash because it find another POI first. I also sometimes have two POI for the same thing - one for finding it via a category POI search, the other for the symbol in the map. I do wonder if you have two POI the order in the style matters? If you change the order they are created - does it crash?
Could it be that only 0x1234 POI are affected, but the newer 0x12345 types not? As soon as it finds 0x12345 it does not crash?
Lets take Verbier Village - it is not a ciy POI https://www.openstreetmap.org/node/8307159228
I use: highway=bus_stop | amenity=bus_stop | highway=busstop | amenity=busstop | railway=bus_stop {set name='bus_stop ${name}' | 'bus_stop' } [0x2f17 resolution 24] for that one.
Cold de Jaman https://www.openstreetmap.org/node/1437437792 I have the rule: 0x1c01 resolution 24 continue] [0x11607 resolution 20-21 continue] [0x1151f resolution 22-22 continue [0x1151f resolution 23-24]]
However the first one in my map obviously is 0x1c01 - an old type.
The other ones are a bit bad examples I noticed - because there exists several entries in osm data that could be found with identical name. However I have found no actual city only poi where it crashes - Saas Fee also has other POI named the same. So maybe they cause a crash.
On Wed, 2 Jun 2021 at 10:25, Thomas Morgenstern <webmaster@img2ms.de <mailto:webmaster@img2ms.de>> wrote: Kann sein, dass es am Style liegt. Ich nutze meinen eigenen Style, der z.B einen zusätzlichen POI für Städte einfügt. ich fand vor geraumer Zeit, dass Städte in der MDR nicht eingebbar sind, wenn der String Leerzeichen enthält. Dazu hatte ich auch in der mailinglist gepostet. Hr.Petermann sagte damals, das die MDR für Städte aber nicht anpassbar sei. deshalb hat bei mir jede Stadt noch einen zusätzlichen POI einer anderen Kategorie. mfg
Am 02.06.2021 um 09:07 schrieb Felix Hartmann: Very strange - I also tested this on "Frezeitkarte" Schweiz and it crashed too. It usually does not crash if you before had a non crash search.
On Wed, 2 Jun 2021 at 08:35, Thomas Morgenstern <webmaster@img2ms.de <mailto:webmaster@img2ms.de>> wrote: Kann ich nicht bestätigen, alle hier genannten Suchen sind erfolgreich ohne Abstutz. BC Ver 4.7.0 und eigene OSM map mfg
Am 01.06.2021 um 22:32 schrieb Felix Hartmann: A user of my maps just told me that there are some crashes in the Basecamp search. There is a clear pattern - only search phrases of minimum 2 words with a space between cause crashes.
I tested it on my maps, and on other mkgmap created maps and the crashes are more or less happening on all maps.
For Switzerland some places causing crashes: Verbier Village Saas Fee Col de Jaman Pic chaussy Pic chosy
Also 2) the search must be the first from BC execution 3) if a good search already has been executed (single word), then the crash rarely occurs
Not happening with Garmin's own maps. The more entries (POIs) of the name exist - the more likely? Seems to happen more often in the French part of Switzerland compared to the Garmin part. But as many words like Saas Fee do not contain any special characters - I do not think it is related to any codepage problem. -- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
Okay -no removing --split-name-index does not change anything. Still crashes. I will try to produce a minimalist map that still crashes tonight then upload the style and options used. On Wed, 2 Jun 2021 at 12:20, Felix Hartmann <extremecarver@gmail.com> wrote:
Basecamp just closes 0-3 seconds after entering that term into the search bar. No warning, no error notice, nothing. Seems to have been happening a long time already. Okay this evening I will try to produce a map as small as possible that still crashes. I do not have much time now anymore - but will try if removing --split-name-index changes something. I kinda feel it has something to do with split-name-index.
On Wed, 2 Jun 2021 at 12:07, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
I couldn't reproduce the crash so far. Please provide a small map and exact instructions how to reproduce. What happens when BC crashes? Do you have some kind of report?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Mittwoch, 2. Juni 2021 10:16 An: Thomas Morgenstern; Development list for mkgmap Betreff: Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases
https://www.openstreetmap.org/node/3268115540 shop=hardware | shop=trade [0x2e01 resolution 24] does not crash - it has a full address field. Maybe if we have address for a POI it does not crash?
I have to look but I think so far only entries without an address cause a crash. Also it does not crash if being nearby and only searching for one of the words of the entry thereby finding it.
On Wed, 2 Jun 2021 at 11:08, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com>> wrote: I just thought about it - could it be related to multi word street search? Maybe what works for multi word street search is not possible for old type POI search? So it is the multi word stuff that got introduced for roads that causes the crashes in Basecamp (not sure about what happens on devices - will check that out later). --add-pois-to-areas --pois-to-areas-placement=entrance=main;entrance=yes;building=entrance;barrier=entrance --link-pois-to-ways --location-autofill=bounds,is_in,nearest and of coure --index are the most relevant to this thread options I am using.
On Wed, 2 Jun 2021 at 10:49, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com>> wrote: Even though Gerd also speaks German, I think its better to continue in English. I am quite sure that this is the same bug then. Your map does not crash because it find another POI first. I also sometimes have two POI for the same thing - one for finding it via a category POI search, the other for the symbol in the map. I do wonder if you have two POI the order in the style matters? If you change the order they are created - does it crash?
Could it be that only 0x1234 POI are affected, but the newer 0x12345 types not? As soon as it finds 0x12345 it does not crash?
Lets take Verbier Village - it is not a ciy POI https://www.openstreetmap.org/node/8307159228
I use: highway=bus_stop | amenity=bus_stop | highway=busstop | amenity=busstop | railway=bus_stop {set name='bus_stop ${name}' | 'bus_stop' } [0x2f17 resolution 24] for that one.
Cold de Jaman https://www.openstreetmap.org/node/1437437792 I have the rule: 0x1c01 resolution 24 continue] [0x11607 resolution 20-21 continue] [0x1151f resolution 22-22 continue [0x1151f resolution 23-24]]
However the first one in my map obviously is 0x1c01 - an old type.
The other ones are a bit bad examples I noticed - because there exists several entries in osm data that could be found with identical name. However I have found no actual city only poi where it crashes - Saas Fee also has other POI named the same. So maybe they cause a crash.
On Wed, 2 Jun 2021 at 10:25, Thomas Morgenstern <webmaster@img2ms.de <mailto:webmaster@img2ms.de>> wrote: Kann sein, dass es am Style liegt. Ich nutze meinen eigenen Style, der z.B einen zusätzlichen POI für Städte einfügt. ich fand vor geraumer Zeit, dass Städte in der MDR nicht eingebbar sind, wenn der String Leerzeichen enthält. Dazu hatte ich auch in der mailinglist gepostet. Hr.Petermann sagte damals, das die MDR für Städte aber nicht anpassbar sei. deshalb hat bei mir jede Stadt noch einen zusätzlichen POI einer anderen Kategorie. mfg
Am 02.06.2021 um 09:07 schrieb Felix Hartmann: Very strange - I also tested this on "Frezeitkarte" Schweiz and it crashed too. It usually does not crash if you before had a non crash search.
On Wed, 2 Jun 2021 at 08:35, Thomas Morgenstern <webmaster@img2ms.de <mailto:webmaster@img2ms.de>> wrote: Kann ich nicht bestätigen, alle hier genannten Suchen sind erfolgreich ohne Abstutz. BC Ver 4.7.0 und eigene OSM map mfg
Am 01.06.2021 um 22:32 schrieb Felix Hartmann: A user of my maps just told me that there are some crashes in the Basecamp search. There is a clear pattern - only search phrases of minimum 2 words with a space between cause crashes.
I tested it on my maps, and on other mkgmap created maps and the crashes are more or less happening on all maps.
For Switzerland some places causing crashes: Verbier Village Saas Fee Col de Jaman Pic chaussy Pic chosy
Also 2) the search must be the first from BC execution 3) if a good search already has been executed (single word), then the crash rarely occurs
Not happening with Garmin's own maps. The more entries (POIs) of the name exist - the more likely? Seems to happen more often in the French part of Switzerland compared to the Garmin part. But as many words like Saas Fee do not contain any special characters - I do not think it is related to any codepage problem. -- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
Yes, this has been happening for a very long time (longer than my memory lane). My “facts”: * Not possible to reproduce; * Sometimes it will take hours before the crash occurs. So, I don’t agree: “if a good search already has been executed (single word), then the crash rarely occurs”. * Long, long ago I have tested by uninstall all mkgmaps, which left over City Navigator 2007 (yes; 2007). And still: the error did occur. But harder to reproduce; * But also: I have the impression (no fact) that more Maps increases the chance of crashing; * I have never seen GPS crash on search (Vista HCx, Etrex 30, GPSMAP 62/66) * Find Addresses (Ctrl+Alt+A) will never crash (so: work-around); * I have also seen strange addresses found, which do not match my search criteria. * And – lol – I could reproduce a BaseCamp search which will take 10 minutes to respond. Oeps, or was this a GPS search? Is this a search where BaseCamp will crash (impatience, no retry, no error handling) and GPS will try for 10 minutes and succeed??? My work-around: Do not use BaseCamp for any Search. Not ever! I use my smartphone + OsmAnd or Google search on second PC monitor. I will only test a new version of BaseCamp and until now, it’s always not oké. Still not oké. In BaseCamp I can only find an object, if I know where it is…. A BaseCamp crash is 99% harmless, but at 1% I lose information (in which case always (...) relevant information, so bad for my mood). But I might have to apologize to Garmin. I have always considered BaseCamp to be extreme bad software, but perhaps Garmin is not to blame??? If (but only “if”) you are gone investigate and mkgmap might be the cause, I could try “memory lane”. I have posted several times on Garmin Vendor forum about searching and not finding or finding the wrong answers or crashing. I even might have found a way to reproduce ????? But these posting are all in Dutch language, so therefore: “If and only if”. Sorry, too many “???”. But I assumed I had managed to suppress my - bad - memories Eric (AnkEric) From: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> On Behalf Of Felix Hartmann Sent: woensdag 2 juni 2021 11:20 To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases Basecamp just closes 0-3 seconds after entering that term into the search bar. No warning, no error notice, nothing. Seems to have been happening a long time already. Okay this evening I will try to produce a map as small as possible that still crashes. I do not have much time now anymore - but will try if removing --split-name-index changes something. I kinda feel it has something to do with split-name-index. On Wed, 2 Jun 2021 at 12:07, Gerd Petermann <gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com> > wrote: Hi Felix, I couldn't reproduce the crash so far. Please provide a small map and exact instructions how to reproduce. What happens when BC crashes? Do you have some kind of report? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk <mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk> > im Auftrag von Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com> > Gesendet: Mittwoch, 2. Juni 2021 10:16 An: Thomas Morgenstern; Development list for mkgmap Betreff: Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases https://www.openstreetmap.org/node/3268115540 shop=hardware | shop=trade [0x2e01 resolution 24] does not crash - it has a full address field. Maybe if we have address for a POI it does not crash? I have to look but I think so far only entries without an address cause a crash. Also it does not crash if being nearby and only searching for one of the words of the entry thereby finding it. On Wed, 2 Jun 2021 at 11:08, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com> <mailto:extremecarver@gmail.com <mailto:extremecarver@gmail.com> >> wrote: I just thought about it - could it be related to multi word street search? Maybe what works for multi word street search is not possible for old type POI search? So it is the multi word stuff that got introduced for roads that causes the crashes in Basecamp (not sure about what happens on devices - will check that out later). --add-pois-to-areas --pois-to-areas-placement=entrance=main;entrance=yes;building=entrance;barrier=entrance --link-pois-to-ways --location-autofill=bounds,is_in,nearest and of coure --index are the most relevant to this thread options I am using. On Wed, 2 Jun 2021 at 10:49, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com> <mailto:extremecarver@gmail.com <mailto:extremecarver@gmail.com> >> wrote: Even though Gerd also speaks German, I think its better to continue in English. I am quite sure that this is the same bug then. Your map does not crash because it find another POI first. I also sometimes have two POI for the same thing - one for finding it via a category POI search, the other for the symbol in the map. I do wonder if you have two POI the order in the style matters? If you change the order they are created - does it crash? Could it be that only 0x1234 POI are affected, but the newer 0x12345 types not? As soon as it finds 0x12345 it does not crash? Lets take Verbier Village - it is not a ciy POI https://www.openstreetmap.org/node/8307159228 I use: highway=bus_stop | amenity=bus_stop | highway=busstop | amenity=busstop | railway=bus_stop {set name='bus_stop ${name}' | 'bus_stop' } [0x2f17 resolution 24] for that one. Cold de Jaman https://www.openstreetmap.org/node/1437437792 I have the rule: 0x1c01 resolution 24 continue] [0x11607 resolution 20-21 continue] [0x1151f resolution 22-22 continue [0x1151f resolution 23-24]] However the first one in my map obviously is 0x1c01 - an old type. The other ones are a bit bad examples I noticed - because there exists several entries in osm data that could be found with identical name. However I have found no actual city only poi where it crashes - Saas Fee also has other POI named the same. So maybe they cause a crash. On Wed, 2 Jun 2021 at 10:25, Thomas Morgenstern <webmaster@img2ms.de <mailto:webmaster@img2ms.de> <mailto:webmaster@img2ms.de <mailto:webmaster@img2ms.de> >> wrote: Kann sein, dass es am Style liegt. Ich nutze meinen eigenen Style, der z.B einen zusätzlichen POI für Städte einfügt. ich fand vor geraumer Zeit, dass Städte in der MDR nicht eingebbar sind, wenn der String Leerzeichen enthält. Dazu hatte ich auch in der mailinglist gepostet. Hr.Petermann sagte damals, das die MDR für Städte aber nicht anpassbar sei. deshalb hat bei mir jede Stadt noch einen zusätzlichen POI einer anderen Kategorie. mfg Am 02.06.2021 um 09:07 schrieb Felix Hartmann: Very strange - I also tested this on "Frezeitkarte" Schweiz and it crashed too. It usually does not crash if you before had a non crash search. On Wed, 2 Jun 2021 at 08:35, Thomas Morgenstern <webmaster@img2ms.de <mailto:webmaster@img2ms.de> <mailto:webmaster@img2ms.de <mailto:webmaster@img2ms.de> >> wrote: Kann ich nicht bestätigen, alle hier genannten Suchen sind erfolgreich ohne Abstutz. BC Ver 4.7.0 und eigene OSM map mfg Am 01.06.2021 um 22:32 schrieb Felix Hartmann: A user of my maps just told me that there are some crashes in the Basecamp search. There is a clear pattern - only search phrases of minimum 2 words with a space between cause crashes. I tested it on my maps, and on other mkgmap created maps and the crashes are more or less happening on all maps. For Switzerland some places causing crashes: Verbier Village Saas Fee Col de Jaman Pic chaussy Pic chosy Also 2) the search must be the first from BC execution 3) if a good search already has been executed (single word), then the crash rarely occurs Not happening with Garmin's own maps. The more entries (POIs) of the name exist - the more likely? Seems to happen more often in the French part of Switzerland compared to the Garmin part. But as many words like Saas Fee do not contain any special characters - I do not think it is related to any codepage problem. -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> <mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org
well it clearly only happens with a blank in the name. That is the most common factor. Never seen one where the name is a single word. And in recent versions of Basecamp the search actually became really useful - it is way faster than at the beginning, it finds all addresses / POI - just missing the nice POI category search. I will try to get a minimalist style to crash. If that doesn't work maybe we can introduce _ instead of blanks? Better not being able to search for two words normally with crash vs not crashing. Well only for 0x1??? and 0x2??? POI. I do feel like if Basecamp can first find a 0x????? type of POI it will not crash. That is what is causing those really random results. Last message for now - need to get some fresh air after working 6 hours straight this morning. But will try to drill down the problem a bit more tonight. On Wed, 2 Jun 2021 at 13:03, <ankeric.osm@gmail.com> wrote:
Yes, this has been happening for a very long time (longer than my memory lane).
My “facts”:
- Not possible to reproduce; - Sometimes it will take hours before the crash occurs. So, I don’t agree: “if a good search already has been executed (single word), then the crash rarely occurs”. - Long, long ago I have tested by uninstall all mkgmaps, which left over City Navigator 2007 (yes; 2007). And still: the error did occur. But harder to reproduce; - But also: I have the impression (no fact) that more Maps increases the chance of crashing; - I have never seen GPS crash on search (Vista HCx, Etrex 30, GPSMAP 62/66) - Find Addresses (Ctrl+Alt+A) will never crash (so: work-around); - I have also seen strange addresses found, which do not match my search criteria. - And – lol – I could reproduce a BaseCamp search which will take 10 minutes to respond. Oeps, or was this a GPS search? Is this a search where BaseCamp will crash (impatience, no retry, no error handling) and GPS will try for 10 minutes and succeed???
My work-around:
Do not use BaseCamp for any Search. Not ever! I use my smartphone + OsmAnd or Google search on second PC monitor.
I will only test a new version of BaseCamp and until now, it’s always not oké. Still not oké.
In BaseCamp I can only find an object, if I know where it is….
A BaseCamp crash is 99% harmless, but at 1% I lose information (in which case always (...) relevant information, so bad for my mood).
But I might have to apologize to Garmin.
I have always considered BaseCamp to be extreme bad software, but perhaps Garmin is not to blame???
If (but only “if”) you are gone investigate and mkgmap might be the cause, I could try “memory lane”.
I have posted several times on Garmin Vendor forum about searching and not finding or finding the wrong answers or crashing.
I even might have found a way to reproduce ?????
But these posting are all in Dutch language, so therefore: “If and only if”.
Sorry, too many “???”.
But I assumed I had managed to suppress my - bad - memories
Eric (AnkEric)
*From:* mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> *On Behalf Of *Felix Hartmann *Sent:* woensdag 2 juni 2021 11:20 *To:* Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> *Subject:* Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases
Basecamp just closes 0-3 seconds after entering that term into the search bar. No warning, no error notice, nothing. Seems to have been happening a long time already. Okay this evening I will try to produce a map as small as possible that still crashes. I do not have much time now anymore - but will try if removing --split-name-index changes something. I kinda feel it has something to do with split-name-index.
On Wed, 2 Jun 2021 at 12:07, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
I couldn't reproduce the crash so far. Please provide a small map and exact instructions how to reproduce. What happens when BC crashes? Do you have some kind of report?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Mittwoch, 2. Juni 2021 10:16 An: Thomas Morgenstern; Development list for mkgmap Betreff: Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases
https://www.openstreetmap.org/node/3268115540 shop=hardware | shop=trade [0x2e01 resolution 24] does not crash - it has a full address field. Maybe if we have address for a POI it does not crash?
I have to look but I think so far only entries without an address cause a crash. Also it does not crash if being nearby and only searching for one of the words of the entry thereby finding it.
On Wed, 2 Jun 2021 at 11:08, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com>> wrote: I just thought about it - could it be related to multi word street search? Maybe what works for multi word street search is not possible for old type POI search? So it is the multi word stuff that got introduced for roads that causes the crashes in Basecamp (not sure about what happens on devices - will check that out later). --add-pois-to-areas --pois-to-areas-placement=entrance=main;entrance=yes;building=entrance;barrier=entrance --link-pois-to-ways --location-autofill=bounds,is_in,nearest and of coure --index are the most relevant to this thread options I am using.
On Wed, 2 Jun 2021 at 10:49, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com>> wrote: Even though Gerd also speaks German, I think its better to continue in English. I am quite sure that this is the same bug then. Your map does not crash because it find another POI first. I also sometimes have two POI for the same thing - one for finding it via a category POI search, the other for the symbol in the map. I do wonder if you have two POI the order in the style matters? If you change the order they are created - does it crash?
Could it be that only 0x1234 POI are affected, but the newer 0x12345 types not? As soon as it finds 0x12345 it does not crash?
Lets take Verbier Village - it is not a ciy POI https://www.openstreetmap.org/node/8307159228
I use: highway=bus_stop | amenity=bus_stop | highway=busstop | amenity=busstop | railway=bus_stop {set name='bus_stop ${name}' | 'bus_stop' } [0x2f17 resolution 24] for that one.
Cold de Jaman https://www.openstreetmap.org/node/1437437792 I have the rule: 0x1c01 resolution 24 continue] [0x11607 resolution 20-21 continue] [0x1151f resolution 22-22 continue [0x1151f resolution 23-24]]
However the first one in my map obviously is 0x1c01 - an old type.
The other ones are a bit bad examples I noticed - because there exists several entries in osm data that could be found with identical name. However I have found no actual city only poi where it crashes - Saas Fee also has other POI named the same. So maybe they cause a crash.
On Wed, 2 Jun 2021 at 10:25, Thomas Morgenstern <webmaster@img2ms.de <mailto:webmaster@img2ms.de>> wrote: Kann sein, dass es am Style liegt. Ich nutze meinen eigenen Style, der z.B einen zusätzlichen POI für Städte einfügt. ich fand vor geraumer Zeit, dass Städte in der MDR nicht eingebbar sind, wenn der String Leerzeichen enthält. Dazu hatte ich auch in der mailinglist gepostet. Hr.Petermann sagte damals, das die MDR für Städte aber nicht anpassbar sei. deshalb hat bei mir jede Stadt noch einen zusätzlichen POI einer anderen Kategorie. mfg
Am 02.06.2021 um 09:07 schrieb Felix Hartmann: Very strange - I also tested this on "Frezeitkarte" Schweiz and it crashed too. It usually does not crash if you before had a non crash search.
On Wed, 2 Jun 2021 at 08:35, Thomas Morgenstern <webmaster@img2ms.de <mailto:webmaster@img2ms.de>> wrote: Kann ich nicht bestätigen, alle hier genannten Suchen sind erfolgreich ohne Abstutz. BC Ver 4.7.0 und eigene OSM map mfg
Am 01.06.2021 um 22:32 schrieb Felix Hartmann: A user of my maps just told me that there are some crashes in the Basecamp search. There is a clear pattern - only search phrases of minimum 2 words with a space between cause crashes.
I tested it on my maps, and on other mkgmap created maps and the crashes are more or less happening on all maps.
For Switzerland some places causing crashes: Verbier Village Saas Fee Col de Jaman Pic chaussy Pic chosy
Also 2) the search must be the first from BC execution 3) if a good search already has been executed (single word), then the crash rarely occurs
Not happening with Garmin's own maps. The more entries (POIs) of the name exist - the more likely? Seems to happen more often in the French part of Switzerland compared to the Garmin part. But as many words like Saas Fee do not contain any special characters - I do not think it is related to any codepage problem. -- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
--
Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
Hi Felix, I don’t appreciate your post; -)) Please let sleeping dogs lie. Oké, get to the point. BaseCamp version is relevant. I assume. I tried to reproduce and since BaseCamp is remembering search history, this should be easy. I don’t abide my own rule (don’t search by BaseCamp); -) After 15 minutes I gave up. No success in reproducing a crash. All searches (10x different) contained space(s) and comma! So I moved mouse to “Exit”, wanted to give up, but before I could Exit, BaseCamp crashed. On my last search??? Oké, what was my last search? I don’t know. So restart testing. 10x success, so mood problem. But then: Search for “338 dijkweg, andijk” Crash. Restart BaseCamp Search for “338 dijkweg, andijk” Crash. Reproduced 10 times in a row! Oké, now search for Search for “338 dijkweg, andijk” by using: Find Addresses (Ctrl+Alt+A) Now BaseCamp search will correct my incorrect capitalisation before search is started: 338 + Dijkweg + Andijk Success, no crash! And address has been found! Oke, now search for Search for “338 dijkweg, andijk” (not by Ctrl+Alt+A, but in Search box) Success, no crash! Reproduced 10 times in a row! Not oké, my test is NOT oké! This is only true IF (and only if) I keep the Ctrl+Alt+A window open! I’m allowed to search (textbox) to different text (and BaseCamp will find those) en then again for “338 dijkweg, andijk” (success), but as soon as I close Ctrl+Alt+A window, search for “338 dijkweg, andijk” won’t find any results and will crash after a few seconds. Exit BaseCamp Start BaseCamp Search for “338 dijkweg, andijk” (not by Ctrl+Alt+A, but in Search box, incorrect capitalization) Again: crash! Search for “andijk” No crash! Exit BaseCamp Start BaseCamp Search for “338 Dijkweg, Andijk” (correct capitalization) Again: crash! Exit BaseCamp Start BaseCamp Search for “338 Dijkweg, Andijk” or “338 dijkweg, andijk” BaseCamp won’t find the address! BaseCamp only finds “Dijkwegpad, Amsterdam” BaseCamp Shows 1x result Searching…… Again: crash! Next step might be: Uninstall ALL maps. Reinstall OpenFietsMap (Gerd also uses OpenFietsMap for testing purposes) But will uninstall force a BaseCamp index update? If I’m very lucky I can reproduce…????? But I’m assuming this is BaseCamp error and not mkgmap????? BTW: “338 Dijkweg, Andijk” is not a privacy issue. This is a pub, end-of-life after 125 years and then locals bought the pub and they will reopen next month (1 July). So this is “promotion”: old name “Het Ankertje”, new name “Eetcafé Sels”. I did therefore search for it. Eric (AnkEric) From: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> On Behalf Of Felix Hartmann Sent: woensdag 2 juni 2021 12:15 To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases well it clearly only happens with a blank in the name. That is the most common factor. Never seen one where the name is a single word. And in recent versions of Basecamp the search actually became really useful - it is way faster than at the beginning, it finds all addresses / POI - just missing the nice POI category search. I will try to get a minimalist style to crash. If that doesn't work maybe we can introduce _ instead of blanks? Better not being able to search for two words normally with crash vs not crashing. Well only for 0x1??? and 0x2??? POI. I do feel like if Basecamp can first find a 0x????? type of POI it will not crash. That is what is causing those really random results. Last message for now - need to get some fresh air after working 6 hours straight this morning. But will try to drill down the problem a bit more tonight. On Wed, 2 Jun 2021 at 13:03, <ankeric.osm@gmail.com <mailto:ankeric.osm@gmail.com> > wrote: Yes, this has been happening for a very long time (longer than my memory lane). My “facts”: * Not possible to reproduce; * Sometimes it will take hours before the crash occurs. So, I don’t agree: “if a good search already has been executed (single word), then the crash rarely occurs”. * Long, long ago I have tested by uninstall all mkgmaps, which left over City Navigator 2007 (yes; 2007). And still: the error did occur. But harder to reproduce; * But also: I have the impression (no fact) that more Maps increases the chance of crashing; * I have never seen GPS crash on search (Vista HCx, Etrex 30, GPSMAP 62/66) * Find Addresses (Ctrl+Alt+A) will never crash (so: work-around); * I have also seen strange addresses found, which do not match my search criteria. * And – lol – I could reproduce a BaseCamp search which will take 10 minutes to respond. Oeps, or was this a GPS search? Is this a search where BaseCamp will crash (impatience, no retry, no error handling) and GPS will try for 10 minutes and succeed??? My work-around: Do not use BaseCamp for any Search. Not ever! I use my smartphone + OsmAnd or Google search on second PC monitor. I will only test a new version of BaseCamp and until now, it’s always not oké. Still not oké. In BaseCamp I can only find an object, if I know where it is…. A BaseCamp crash is 99% harmless, but at 1% I lose information (in which case always (...) relevant information, so bad for my mood). But I might have to apologize to Garmin. I have always considered BaseCamp to be extreme bad software, but perhaps Garmin is not to blame??? If (but only “if”) you are gone investigate and mkgmap might be the cause, I could try “memory lane”. I have posted several times on Garmin Vendor forum about searching and not finding or finding the wrong answers or crashing. I even might have found a way to reproduce ????? But these posting are all in Dutch language, so therefore: “If and only if”. Sorry, too many “???”. But I assumed I had managed to suppress my - bad - memories Eric (AnkEric) From: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk <mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk> > On Behalf Of Felix Hartmann Sent: woensdag 2 juni 2021 11:20 To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> > Subject: Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases Basecamp just closes 0-3 seconds after entering that term into the search bar. No warning, no error notice, nothing. Seems to have been happening a long time already. Okay this evening I will try to produce a map as small as possible that still crashes. I do not have much time now anymore - but will try if removing --split-name-index changes something. I kinda feel it has something to do with split-name-index. On Wed, 2 Jun 2021 at 12:07, Gerd Petermann <gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com> > wrote: Hi Felix, I couldn't reproduce the crash so far. Please provide a small map and exact instructions how to reproduce. What happens when BC crashes? Do you have some kind of report? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk <mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk> > im Auftrag von Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com> > Gesendet: Mittwoch, 2. Juni 2021 10:16 An: Thomas Morgenstern; Development list for mkgmap Betreff: Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases https://www.openstreetmap.org/node/3268115540 shop=hardware | shop=trade [0x2e01 resolution 24] does not crash - it has a full address field. Maybe if we have address for a POI it does not crash? I have to look but I think so far only entries without an address cause a crash. Also it does not crash if being nearby and only searching for one of the words of the entry thereby finding it. On Wed, 2 Jun 2021 at 11:08, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com> <mailto:extremecarver@gmail.com <mailto:extremecarver@gmail.com> >> wrote: I just thought about it - could it be related to multi word street search? Maybe what works for multi word street search is not possible for old type POI search? So it is the multi word stuff that got introduced for roads that causes the crashes in Basecamp (not sure about what happens on devices - will check that out later). --add-pois-to-areas --pois-to-areas-placement=entrance=main;entrance=yes;building=entrance;barrier=entrance --link-pois-to-ways --location-autofill=bounds,is_in,nearest and of coure --index are the most relevant to this thread options I am using. On Wed, 2 Jun 2021 at 10:49, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com> <mailto:extremecarver@gmail.com <mailto:extremecarver@gmail.com> >> wrote: Even though Gerd also speaks German, I think its better to continue in English. I am quite sure that this is the same bug then. Your map does not crash because it find another POI first. I also sometimes have two POI for the same thing - one for finding it via a category POI search, the other for the symbol in the map. I do wonder if you have two POI the order in the style matters? If you change the order they are created - does it crash? Could it be that only 0x1234 POI are affected, but the newer 0x12345 types not? As soon as it finds 0x12345 it does not crash? Lets take Verbier Village - it is not a ciy POI https://www.openstreetmap.org/node/8307159228 I use: highway=bus_stop | amenity=bus_stop | highway=busstop | amenity=busstop | railway=bus_stop {set name='bus_stop ${name}' | 'bus_stop' } [0x2f17 resolution 24] for that one. Cold de Jaman https://www.openstreetmap.org/node/1437437792 I have the rule: 0x1c01 resolution 24 continue] [0x11607 resolution 20-21 continue] [0x1151f resolution 22-22 continue [0x1151f resolution 23-24]] However the first one in my map obviously is 0x1c01 - an old type. The other ones are a bit bad examples I noticed - because there exists several entries in osm data that could be found with identical name. However I have found no actual city only poi where it crashes - Saas Fee also has other POI named the same. So maybe they cause a crash. On Wed, 2 Jun 2021 at 10:25, Thomas Morgenstern <webmaster@img2ms.de <mailto:webmaster@img2ms.de> <mailto:webmaster@img2ms.de <mailto:webmaster@img2ms.de> >> wrote: Kann sein, dass es am Style liegt. Ich nutze meinen eigenen Style, der z.B einen zusätzlichen POI für Städte einfügt. ich fand vor geraumer Zeit, dass Städte in der MDR nicht eingebbar sind, wenn der String Leerzeichen enthält. Dazu hatte ich auch in der mailinglist gepostet. Hr.Petermann sagte damals, das die MDR für Städte aber nicht anpassbar sei. deshalb hat bei mir jede Stadt noch einen zusätzlichen POI einer anderen Kategorie. mfg Am 02.06.2021 um 09:07 schrieb Felix Hartmann: Very strange - I also tested this on "Frezeitkarte" Schweiz and it crashed too. It usually does not crash if you before had a non crash search. On Wed, 2 Jun 2021 at 08:35, Thomas Morgenstern <webmaster@img2ms.de <mailto:webmaster@img2ms.de> <mailto:webmaster@img2ms.de <mailto:webmaster@img2ms.de> >> wrote: Kann ich nicht bestätigen, alle hier genannten Suchen sind erfolgreich ohne Abstutz. BC Ver 4.7.0 und eigene OSM map mfg Am 01.06.2021 um 22:32 schrieb Felix Hartmann: A user of my maps just told me that there are some crashes in the Basecamp search. There is a clear pattern - only search phrases of minimum 2 words with a space between cause crashes. I tested it on my maps, and on other mkgmap created maps and the crashes are more or less happening on all maps. For Switzerland some places causing crashes: Verbier Village Saas Fee Col de Jaman Pic chaussy Pic chosy Also 2) the search must be the first from BC execution 3) if a good search already has been executed (single word), then the crash rarely occurs Not happening with Garmin's own maps. The more entries (POIs) of the name exist - the more likely? Seems to happen more often in the French part of Switzerland compared to the Garmin part. But as many words like Saas Fee do not contain any special characters - I do not think it is related to any codepage problem. -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> <mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org
Re-installed all my Maps (now: 6x): Search for “338 dijkweg, andijk” by OpenFietsMap: oké, no crash Not even after restart BaseCamp. Switch to my own Map Search for “338 dijkweg, andijk” by my own Map: crash! Switch to OpenFietsMap Search for “338 dijkweg, andijk” by OpenFietsMap: : oké, no crash Switch to my own Map Search for “338 dijkweg, andijk” by my own Map: crash! Must be a very simple explanation; -)) What also might be relevant: Last year vacation I did install my own Bike and my own Hike Map on GpsMap 66. But also (just for fun): OSM_GENERIC Map (Joris Bo). My own Maps use a different Categorization for POI’s (Attractions, AutoService, etc.). Different from OSM_Generic. This was my doing: a change for OpenFietsMap to allow search for picnic_table and bicycle_parking on the map. To find bicycle_parking I have to Search for “Auto Services” + “Wrecker Service”. Having OSM_Generic installed I could not search by Category. Not anymore. Is the crash the result of different POI Categorization by two different sets of Maps????? If the crash occurs, BaseCamp will find some hits, continues the search and after a few (of more) seconds BaseCamp crashes on not finding any more…. So finding is not the issue, not finding is the issue. Oké, very wild guess…. Eric (AnkEric) From: ankeric.osm@gmail.com <ankeric.osm@gmail.com> Sent: woensdag 2 juni 2021 15:08 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: RE: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases Hi Felix, I don’t appreciate your post; -)) Please let sleeping dogs lie. Oké, get to the point. BaseCamp version is relevant. I assume. I tried to reproduce and since BaseCamp is remembering search history, this should be easy. I don’t abide my own rule (don’t search by BaseCamp); -) After 15 minutes I gave up. No success in reproducing a crash. All searches (10x different) contained space(s) and comma! So I moved mouse to “Exit”, wanted to give up, but before I could Exit, BaseCamp crashed. On my last search??? Oké, what was my last search? I don’t know. So restart testing. 10x success, so mood problem. But then: Search for “338 dijkweg, andijk” Crash. Restart BaseCamp Search for “338 dijkweg, andijk” Crash. Reproduced 10 times in a row! Oké, now search for Search for “338 dijkweg, andijk” by using: Find Addresses (Ctrl+Alt+A) Now BaseCamp search will correct my incorrect capitalisation before search is started: 338 + Dijkweg + Andijk Success, no crash! And address has been found! Oke, now search for Search for “338 dijkweg, andijk” (not by Ctrl+Alt+A, but in Search box) Success, no crash! Reproduced 10 times in a row! Not oké, my test is NOT oké! This is only true IF (and only if) I keep the Ctrl+Alt+A window open! I’m allowed to search (textbox) to different text (and BaseCamp will find those) en then again for “338 dijkweg, andijk” (success), but as soon as I close Ctrl+Alt+A window, search for “338 dijkweg, andijk” won’t find any results and will crash after a few seconds. Exit BaseCamp Start BaseCamp Search for “338 dijkweg, andijk” (not by Ctrl+Alt+A, but in Search box, incorrect capitalization) Again: crash! Search for “andijk” No crash! Exit BaseCamp Start BaseCamp Search for “338 Dijkweg, Andijk” (correct capitalization) Again: crash! Exit BaseCamp Start BaseCamp Search for “338 Dijkweg, Andijk” or “338 dijkweg, andijk” BaseCamp won’t find the address! BaseCamp only finds “Dijkwegpad, Amsterdam” BaseCamp Shows 1x result Searching…… Again: crash! Next step might be: Uninstall ALL maps. Reinstall OpenFietsMap (Gerd also uses OpenFietsMap for testing purposes) But will uninstall force a BaseCamp index update? If I’m very lucky I can reproduce…????? But I’m assuming this is BaseCamp error and not mkgmap????? BTW: “338 Dijkweg, Andijk” is not a privacy issue. This is a pub, end-of-life after 125 years and then locals bought the pub and they will reopen next month (1 July). So this is “promotion”: old name “Het Ankertje”, new name “Eetcafé Sels”. I did therefore search for it. Eric (AnkEric) From: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk <mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk> > On Behalf Of Felix Hartmann Sent: woensdag 2 juni 2021 12:15 To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> > Subject: Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases well it clearly only happens with a blank in the name. That is the most common factor. Never seen one where the name is a single word. And in recent versions of Basecamp the search actually became really useful - it is way faster than at the beginning, it finds all addresses / POI - just missing the nice POI category search. I will try to get a minimalist style to crash. If that doesn't work maybe we can introduce _ instead of blanks? Better not being able to search for two words normally with crash vs not crashing. Well only for 0x1??? and 0x2??? POI. I do feel like if Basecamp can first find a 0x????? type of POI it will not crash. That is what is causing those really random results. Last message for now - need to get some fresh air after working 6 hours straight this morning. But will try to drill down the problem a bit more tonight. On Wed, 2 Jun 2021 at 13:03, <ankeric.osm@gmail.com <mailto:ankeric.osm@gmail.com> > wrote: Yes, this has been happening for a very long time (longer than my memory lane). My “facts”: * Not possible to reproduce; * Sometimes it will take hours before the crash occurs. So, I don’t agree: “if a good search already has been executed (single word), then the crash rarely occurs”. * Long, long ago I have tested by uninstall all mkgmaps, which left over City Navigator 2007 (yes; 2007). And still: the error did occur. But harder to reproduce; * But also: I have the impression (no fact) that more Maps increases the chance of crashing; * I have never seen GPS crash on search (Vista HCx, Etrex 30, GPSMAP 62/66) * Find Addresses (Ctrl+Alt+A) will never crash (so: work-around); * I have also seen strange addresses found, which do not match my search criteria. * And – lol – I could reproduce a BaseCamp search which will take 10 minutes to respond. Oeps, or was this a GPS search? Is this a search where BaseCamp will crash (impatience, no retry, no error handling) and GPS will try for 10 minutes and succeed??? My work-around: Do not use BaseCamp for any Search. Not ever! I use my smartphone + OsmAnd or Google search on second PC monitor. I will only test a new version of BaseCamp and until now, it’s always not oké. Still not oké. In BaseCamp I can only find an object, if I know where it is…. A BaseCamp crash is 99% harmless, but at 1% I lose information (in which case always (...) relevant information, so bad for my mood). But I might have to apologize to Garmin. I have always considered BaseCamp to be extreme bad software, but perhaps Garmin is not to blame??? If (but only “if”) you are gone investigate and mkgmap might be the cause, I could try “memory lane”. I have posted several times on Garmin Vendor forum about searching and not finding or finding the wrong answers or crashing. I even might have found a way to reproduce ????? But these posting are all in Dutch language, so therefore: “If and only if”. Sorry, too many “???”. But I assumed I had managed to suppress my - bad - memories Eric (AnkEric) From: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk <mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk> > On Behalf Of Felix Hartmann Sent: woensdag 2 juni 2021 11:20 To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> > Subject: Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases Basecamp just closes 0-3 seconds after entering that term into the search bar. No warning, no error notice, nothing. Seems to have been happening a long time already. Okay this evening I will try to produce a map as small as possible that still crashes. I do not have much time now anymore - but will try if removing --split-name-index changes something. I kinda feel it has something to do with split-name-index. On Wed, 2 Jun 2021 at 12:07, Gerd Petermann <gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com> > wrote: Hi Felix, I couldn't reproduce the crash so far. Please provide a small map and exact instructions how to reproduce. What happens when BC crashes? Do you have some kind of report? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk <mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk> > im Auftrag von Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com> > Gesendet: Mittwoch, 2. Juni 2021 10:16 An: Thomas Morgenstern; Development list for mkgmap Betreff: Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases https://www.openstreetmap.org/node/3268115540 shop=hardware | shop=trade [0x2e01 resolution 24] does not crash - it has a full address field. Maybe if we have address for a POI it does not crash? I have to look but I think so far only entries without an address cause a crash. Also it does not crash if being nearby and only searching for one of the words of the entry thereby finding it. On Wed, 2 Jun 2021 at 11:08, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com> <mailto:extremecarver@gmail.com <mailto:extremecarver@gmail.com> >> wrote: I just thought about it - could it be related to multi word street search? Maybe what works for multi word street search is not possible for old type POI search? So it is the multi word stuff that got introduced for roads that causes the crashes in Basecamp (not sure about what happens on devices - will check that out later). --add-pois-to-areas --pois-to-areas-placement=entrance=main;entrance=yes;building=entrance;barrier=entrance --link-pois-to-ways --location-autofill=bounds,is_in,nearest and of coure --index are the most relevant to this thread options I am using. On Wed, 2 Jun 2021 at 10:49, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com> <mailto:extremecarver@gmail.com <mailto:extremecarver@gmail.com> >> wrote: Even though Gerd also speaks German, I think its better to continue in English. I am quite sure that this is the same bug then. Your map does not crash because it find another POI first. I also sometimes have two POI for the same thing - one for finding it via a category POI search, the other for the symbol in the map. I do wonder if you have two POI the order in the style matters? If you change the order they are created - does it crash? Could it be that only 0x1234 POI are affected, but the newer 0x12345 types not? As soon as it finds 0x12345 it does not crash? Lets take Verbier Village - it is not a ciy POI https://www.openstreetmap.org/node/8307159228 I use: highway=bus_stop | amenity=bus_stop | highway=busstop | amenity=busstop | railway=bus_stop {set name='bus_stop ${name}' | 'bus_stop' } [0x2f17 resolution 24] for that one. Cold de Jaman https://www.openstreetmap.org/node/1437437792 I have the rule: 0x1c01 resolution 24 continue] [0x11607 resolution 20-21 continue] [0x1151f resolution 22-22 continue [0x1151f resolution 23-24]] However the first one in my map obviously is 0x1c01 - an old type. The other ones are a bit bad examples I noticed - because there exists several entries in osm data that could be found with identical name. However I have found no actual city only poi where it crashes - Saas Fee also has other POI named the same. So maybe they cause a crash. On Wed, 2 Jun 2021 at 10:25, Thomas Morgenstern <webmaster@img2ms.de <mailto:webmaster@img2ms.de> <mailto:webmaster@img2ms.de <mailto:webmaster@img2ms.de> >> wrote: Kann sein, dass es am Style liegt. Ich nutze meinen eigenen Style, der z.B einen zusätzlichen POI für Städte einfügt. ich fand vor geraumer Zeit, dass Städte in der MDR nicht eingebbar sind, wenn der String Leerzeichen enthält. Dazu hatte ich auch in der mailinglist gepostet. Hr.Petermann sagte damals, das die MDR für Städte aber nicht anpassbar sei. deshalb hat bei mir jede Stadt noch einen zusätzlichen POI einer anderen Kategorie. mfg Am 02.06.2021 um 09:07 schrieb Felix Hartmann: Very strange - I also tested this on "Frezeitkarte" Schweiz and it crashed too. It usually does not crash if you before had a non crash search. On Wed, 2 Jun 2021 at 08:35, Thomas Morgenstern <webmaster@img2ms.de <mailto:webmaster@img2ms.de> <mailto:webmaster@img2ms.de <mailto:webmaster@img2ms.de> >> wrote: Kann ich nicht bestätigen, alle hier genannten Suchen sind erfolgreich ohne Abstutz. BC Ver 4.7.0 und eigene OSM map mfg Am 01.06.2021 um 22:32 schrieb Felix Hartmann: A user of my maps just told me that there are some crashes in the Basecamp search. There is a clear pattern - only search phrases of minimum 2 words with a space between cause crashes. I tested it on my maps, and on other mkgmap created maps and the crashes are more or less happening on all maps. For Switzerland some places causing crashes: Verbier Village Saas Fee Col de Jaman Pic chaussy Pic chosy Also 2) the search must be the first from BC execution 3) if a good search already has been executed (single word), then the crash rarely occurs Not happening with Garmin's own maps. The more entries (POIs) of the name exist - the more likely? Seems to happen more often in the French part of Switzerland compared to the Garmin part. But as many words like Saas Fee do not contain any special characters - I do not think it is related to any codepage problem. -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> <mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org
Next: Search by OSM_GENERIC = Crash Restart Search by OSM_GENERIC = Crash Switch to my own Map Search for “338 dijkweg, andijk” by my own Map: NO Crash! Restart Search for “338 dijkweg, andijk” by my own Map: NO Crash! Restart Search for “338 dijkweg, andijk” by OpenFietsMap: NO Crash! Restart Search for “338 dijkweg, andijk” by OSM_GENERIC: Crash! So (+ ????) there is one Map (and one Map only) where the crash occurs. As long as this is not my own Map (or OpenFietsMap) my own Map is safe for Crashing. Just need one Map for Crashing purposes only….????? To reproduce: more than one Map might be required ????? Eric (AnkEric) From: ankeric.osm@gmail.com <ankeric.osm@gmail.com> Sent: woensdag 2 juni 2021 17:02 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: RE: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases Re-installed all my Maps (now: 6x): Search for “338 dijkweg, andijk” by OpenFietsMap: oké, no crash Not even after restart BaseCamp. Switch to my own Map Search for “338 dijkweg, andijk” by my own Map: crash! Switch to OpenFietsMap Search for “338 dijkweg, andijk” by OpenFietsMap: : oké, no crash Switch to my own Map Search for “338 dijkweg, andijk” by my own Map: crash! Must be a very simple explanation; -)) What also might be relevant: Last year vacation I did install my own Bike and my own Hike Map on GpsMap 66. But also (just for fun): OSM_GENERIC Map (Joris Bo). My own Maps use a different Categorization for POI’s (Attractions, AutoService, etc.). Different from OSM_Generic. This was my doing: a change for OpenFietsMap to allow search for picnic_table and bicycle_parking on the map. To find bicycle_parking I have to Search for “Auto Services” + “Wrecker Service”. Having OSM_Generic installed I could not search by Category. Not anymore. Is the crash the result of different POI Categorization by two different sets of Maps????? If the crash occurs, BaseCamp will find some hits, continues the search and after a few (of more) seconds BaseCamp crashes on not finding any more…. So finding is not the issue, not finding is the issue. Oké, very wild guess…. Eric (AnkEric) From: ankeric.osm@gmail.com <mailto:ankeric.osm@gmail.com> <ankeric.osm@gmail.com <mailto:ankeric.osm@gmail.com> > Sent: woensdag 2 juni 2021 15:08 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> > Subject: RE: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases Hi Felix, I don’t appreciate your post; -)) Please let sleeping dogs lie. Oké, get to the point. BaseCamp version is relevant. I assume. I tried to reproduce and since BaseCamp is remembering search history, this should be easy. I don’t abide my own rule (don’t search by BaseCamp); -) After 15 minutes I gave up. No success in reproducing a crash. All searches (10x different) contained space(s) and comma! So I moved mouse to “Exit”, wanted to give up, but before I could Exit, BaseCamp crashed. On my last search??? Oké, what was my last search? I don’t know. So restart testing. 10x success, so mood problem. But then: Search for “338 dijkweg, andijk” Crash. Restart BaseCamp Search for “338 dijkweg, andijk” Crash. Reproduced 10 times in a row! Oké, now search for Search for “338 dijkweg, andijk” by using: Find Addresses (Ctrl+Alt+A) Now BaseCamp search will correct my incorrect capitalisation before search is started: 338 + Dijkweg + Andijk Success, no crash! And address has been found! Oke, now search for Search for “338 dijkweg, andijk” (not by Ctrl+Alt+A, but in Search box) Success, no crash! Reproduced 10 times in a row! Not oké, my test is NOT oké! This is only true IF (and only if) I keep the Ctrl+Alt+A window open! I’m allowed to search (textbox) to different text (and BaseCamp will find those) en then again for “338 dijkweg, andijk” (success), but as soon as I close Ctrl+Alt+A window, search for “338 dijkweg, andijk” won’t find any results and will crash after a few seconds. Exit BaseCamp Start BaseCamp Search for “338 dijkweg, andijk” (not by Ctrl+Alt+A, but in Search box, incorrect capitalization) Again: crash! Search for “andijk” No crash! Exit BaseCamp Start BaseCamp Search for “338 Dijkweg, Andijk” (correct capitalization) Again: crash! Exit BaseCamp Start BaseCamp Search for “338 Dijkweg, Andijk” or “338 dijkweg, andijk” BaseCamp won’t find the address! BaseCamp only finds “Dijkwegpad, Amsterdam” BaseCamp Shows 1x result Searching…… Again: crash! Next step might be: Uninstall ALL maps. Reinstall OpenFietsMap (Gerd also uses OpenFietsMap for testing purposes) But will uninstall force a BaseCamp index update? If I’m very lucky I can reproduce…????? But I’m assuming this is BaseCamp error and not mkgmap????? BTW: “338 Dijkweg, Andijk” is not a privacy issue. This is a pub, end-of-life after 125 years and then locals bought the pub and they will reopen next month (1 July). So this is “promotion”: old name “Het Ankertje”, new name “Eetcafé Sels”. I did therefore search for it. Eric (AnkEric) From: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk <mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk> > On Behalf Of Felix Hartmann Sent: woensdag 2 juni 2021 12:15 To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> > Subject: Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases well it clearly only happens with a blank in the name. That is the most common factor. Never seen one where the name is a single word. And in recent versions of Basecamp the search actually became really useful - it is way faster than at the beginning, it finds all addresses / POI - just missing the nice POI category search. I will try to get a minimalist style to crash. If that doesn't work maybe we can introduce _ instead of blanks? Better not being able to search for two words normally with crash vs not crashing. Well only for 0x1??? and 0x2??? POI. I do feel like if Basecamp can first find a 0x????? type of POI it will not crash. That is what is causing those really random results. Last message for now - need to get some fresh air after working 6 hours straight this morning. But will try to drill down the problem a bit more tonight. On Wed, 2 Jun 2021 at 13:03, <ankeric.osm@gmail.com <mailto:ankeric.osm@gmail.com> > wrote: Yes, this has been happening for a very long time (longer than my memory lane). My “facts”: * Not possible to reproduce; * Sometimes it will take hours before the crash occurs. So, I don’t agree: “if a good search already has been executed (single word), then the crash rarely occurs”. * Long, long ago I have tested by uninstall all mkgmaps, which left over City Navigator 2007 (yes; 2007). And still: the error did occur. But harder to reproduce; * But also: I have the impression (no fact) that more Maps increases the chance of crashing; * I have never seen GPS crash on search (Vista HCx, Etrex 30, GPSMAP 62/66) * Find Addresses (Ctrl+Alt+A) will never crash (so: work-around); * I have also seen strange addresses found, which do not match my search criteria. * And – lol – I could reproduce a BaseCamp search which will take 10 minutes to respond. Oeps, or was this a GPS search? Is this a search where BaseCamp will crash (impatience, no retry, no error handling) and GPS will try for 10 minutes and succeed??? My work-around: Do not use BaseCamp for any Search. Not ever! I use my smartphone + OsmAnd or Google search on second PC monitor. I will only test a new version of BaseCamp and until now, it’s always not oké. Still not oké. In BaseCamp I can only find an object, if I know where it is…. A BaseCamp crash is 99% harmless, but at 1% I lose information (in which case always (...) relevant information, so bad for my mood). But I might have to apologize to Garmin. I have always considered BaseCamp to be extreme bad software, but perhaps Garmin is not to blame??? If (but only “if”) you are gone investigate and mkgmap might be the cause, I could try “memory lane”. I have posted several times on Garmin Vendor forum about searching and not finding or finding the wrong answers or crashing. I even might have found a way to reproduce ????? But these posting are all in Dutch language, so therefore: “If and only if”. Sorry, too many “???”. But I assumed I had managed to suppress my - bad - memories Eric (AnkEric) From: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk <mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk> > On Behalf Of Felix Hartmann Sent: woensdag 2 juni 2021 11:20 To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> > Subject: Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases Basecamp just closes 0-3 seconds after entering that term into the search bar. No warning, no error notice, nothing. Seems to have been happening a long time already. Okay this evening I will try to produce a map as small as possible that still crashes. I do not have much time now anymore - but will try if removing --split-name-index changes something. I kinda feel it has something to do with split-name-index. On Wed, 2 Jun 2021 at 12:07, Gerd Petermann <gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com> > wrote: Hi Felix, I couldn't reproduce the crash so far. Please provide a small map and exact instructions how to reproduce. What happens when BC crashes? Do you have some kind of report? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk <mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk> > im Auftrag von Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com> > Gesendet: Mittwoch, 2. Juni 2021 10:16 An: Thomas Morgenstern; Development list for mkgmap Betreff: Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases https://www.openstreetmap.org/node/3268115540 shop=hardware | shop=trade [0x2e01 resolution 24] does not crash - it has a full address field. Maybe if we have address for a POI it does not crash? I have to look but I think so far only entries without an address cause a crash. Also it does not crash if being nearby and only searching for one of the words of the entry thereby finding it. On Wed, 2 Jun 2021 at 11:08, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com> <mailto:extremecarver@gmail.com <mailto:extremecarver@gmail.com> >> wrote: I just thought about it - could it be related to multi word street search? Maybe what works for multi word street search is not possible for old type POI search? So it is the multi word stuff that got introduced for roads that causes the crashes in Basecamp (not sure about what happens on devices - will check that out later). --add-pois-to-areas --pois-to-areas-placement=entrance=main;entrance=yes;building=entrance;barrier=entrance --link-pois-to-ways --location-autofill=bounds,is_in,nearest and of coure --index are the most relevant to this thread options I am using. On Wed, 2 Jun 2021 at 10:49, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com> <mailto:extremecarver@gmail.com <mailto:extremecarver@gmail.com> >> wrote: Even though Gerd also speaks German, I think its better to continue in English. I am quite sure that this is the same bug then. Your map does not crash because it find another POI first. I also sometimes have two POI for the same thing - one for finding it via a category POI search, the other for the symbol in the map. I do wonder if you have two POI the order in the style matters? If you change the order they are created - does it crash? Could it be that only 0x1234 POI are affected, but the newer 0x12345 types not? As soon as it finds 0x12345 it does not crash? Lets take Verbier Village - it is not a ciy POI https://www.openstreetmap.org/node/8307159228 I use: highway=bus_stop | amenity=bus_stop | highway=busstop | amenity=busstop | railway=bus_stop {set name='bus_stop ${name}' | 'bus_stop' } [0x2f17 resolution 24] for that one. Cold de Jaman https://www.openstreetmap.org/node/1437437792 I have the rule: 0x1c01 resolution 24 continue] [0x11607 resolution 20-21 continue] [0x1151f resolution 22-22 continue [0x1151f resolution 23-24]] However the first one in my map obviously is 0x1c01 - an old type. The other ones are a bit bad examples I noticed - because there exists several entries in osm data that could be found with identical name. However I have found no actual city only poi where it crashes - Saas Fee also has other POI named the same. So maybe they cause a crash. On Wed, 2 Jun 2021 at 10:25, Thomas Morgenstern <webmaster@img2ms.de <mailto:webmaster@img2ms.de> <mailto:webmaster@img2ms.de <mailto:webmaster@img2ms.de> >> wrote: Kann sein, dass es am Style liegt. Ich nutze meinen eigenen Style, der z.B einen zusätzlichen POI für Städte einfügt. ich fand vor geraumer Zeit, dass Städte in der MDR nicht eingebbar sind, wenn der String Leerzeichen enthält. Dazu hatte ich auch in der mailinglist gepostet. Hr.Petermann sagte damals, das die MDR für Städte aber nicht anpassbar sei. deshalb hat bei mir jede Stadt noch einen zusätzlichen POI einer anderen Kategorie. mfg Am 02.06.2021 um 09:07 schrieb Felix Hartmann: Very strange - I also tested this on "Frezeitkarte" Schweiz and it crashed too. It usually does not crash if you before had a non crash search. On Wed, 2 Jun 2021 at 08:35, Thomas Morgenstern <webmaster@img2ms.de <mailto:webmaster@img2ms.de> <mailto:webmaster@img2ms.de <mailto:webmaster@img2ms.de> >> wrote: Kann ich nicht bestätigen, alle hier genannten Suchen sind erfolgreich ohne Abstutz. BC Ver 4.7.0 und eigene OSM map mfg Am 01.06.2021 um 22:32 schrieb Felix Hartmann: A user of my maps just told me that there are some crashes in the Basecamp search. There is a clear pattern - only search phrases of minimum 2 words with a space between cause crashes. I tested it on my maps, and on other mkgmap created maps and the crashes are more or less happening on all maps. For Switzerland some places causing crashes: Verbier Village Saas Fee Col de Jaman Pic chaussy Pic chosy Also 2) the search must be the first from BC execution 3) if a good search already has been executed (single word), then the crash rarely occurs Not happening with Garmin's own maps. The more entries (POIs) of the name exist - the more likely? Seems to happen more often in the French part of Switzerland compared to the Garmin part. But as many words like Saas Fee do not contain any special characters - I do not think it is related to any codepage problem. -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> <mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org
True - it seems a big mystery. Mostly it needs two maps of the same area installed to cause crashes. So I really do not know how to proceed here. I tried with various minimalist styles - and it was the same - needed two maps installed to cause crashes. E.g. Alps and Switzerland then searching in Switzerland. I did not even know that Basecamp has any kind of shared index. On Wed, 2 Jun 2021 at 18:16, <ankeric.osm@gmail.com> wrote:
Next:
Search by OSM_GENERIC = Crash
Restart
Search by OSM_GENERIC = Crash
Switch to my own Map
Search for “338 dijkweg, andijk” by my own Map: NO Crash!
Restart
Search for “338 dijkweg, andijk” by my own Map: NO Crash!
Restart
Search for “338 dijkweg, andijk” by OpenFietsMap: NO Crash!
Restart
Search for “338 dijkweg, andijk” by OSM_GENERIC: Crash!
So (+ ????) there is one Map (and one Map only) where the crash occurs.
As long as this is not my own Map (or OpenFietsMap) my own Map is safe for Crashing.
Just need one Map for Crashing purposes only….?????
To reproduce: more than one Map might be required ?????
Eric (AnkEric)
*From:* ankeric.osm@gmail.com <ankeric.osm@gmail.com> *Sent:* woensdag 2 juni 2021 17:02 *To:* 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> *Subject:* RE: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases
Re-installed all my Maps (now: 6x):
Search for “338 dijkweg, andijk” by OpenFietsMap: oké, no crash
Not even after restart BaseCamp.
Switch to my own Map
Search for “338 dijkweg, andijk” by my own Map: crash!
Switch to OpenFietsMap
Search for “338 dijkweg, andijk” by OpenFietsMap: : oké, no crash
Switch to my own Map
Search for “338 dijkweg, andijk” by my own Map: crash!
Must be a very simple explanation; -))
What also might be relevant:
Last year vacation I did install my own Bike and my own Hike Map on GpsMap 66.
But also (just for fun): OSM_GENERIC Map (Joris Bo).
My own Maps use a different Categorization for POI’s (Attractions, AutoService, etc.).
Different from OSM_Generic.
This was my doing: a change for OpenFietsMap to allow search for picnic_table and bicycle_parking on the map.
To find bicycle_parking I have to Search for “Auto Services” + “Wrecker Service”.
Having OSM_Generic installed I could not search by Category. Not anymore.
Is the crash the result of different POI Categorization by two different sets of Maps?????
If the crash occurs, BaseCamp will find some hits, continues the search and after a few (of more) seconds BaseCamp crashes on not finding any more….
So finding is not the issue, not finding is the issue.
Oké, very wild guess….
Eric (AnkEric)
*From:* ankeric.osm@gmail.com <ankeric.osm@gmail.com> *Sent:* woensdag 2 juni 2021 15:08 *To:* 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> *Subject:* RE: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases
Hi Felix,
I don’t appreciate your post; -))
Please let sleeping dogs lie.
Oké, get to the point.
BaseCamp version is relevant. I assume.
I tried to reproduce and since BaseCamp is remembering search history, this should be easy.
I don’t abide my own rule (don’t search by BaseCamp); -)
After 15 minutes I gave up. No success in reproducing a crash.
All searches (10x different) contained space(s) and comma!
So I moved mouse to “Exit”, wanted to give up, but before I could Exit, BaseCamp crashed. On my last search??? Oké, what was my last search? I don’t know.
So restart testing.
10x success, so mood problem.
But then:
Search for “338 dijkweg, andijk”
Crash.
Restart BaseCamp
Search for “338 dijkweg, andijk”
Crash.
Reproduced 10 times in a row!
Oké, now search for Search for “338 dijkweg, andijk” by using: Find Addresses (Ctrl+Alt+A)
Now BaseCamp search will correct my incorrect capitalisation before search is started: 338 + Dijkweg + Andijk
Success, no crash!
And address has been found!
Oke, now search for Search for “338 dijkweg, andijk” (not by Ctrl+Alt+A, but in Search box)
Success, no crash!
Reproduced 10 times in a row!
Not oké, my test is NOT oké!
This is only true IF (and only if) I keep the Ctrl+Alt+A window open!
I’m allowed to search (textbox) to different text (and BaseCamp will find those) en then again for “338 dijkweg, andijk” (success), but as soon as I close Ctrl+Alt+A window, search for “338 dijkweg, andijk” won’t find any results and will crash after a few seconds.
Exit BaseCamp
Start BaseCamp
Search for “338 dijkweg, andijk” (not by Ctrl+Alt+A, but in Search box, incorrect capitalization)
Again: crash!
Search for “andijk”
No crash!
Exit BaseCamp
Start BaseCamp
Search for “338 Dijkweg, Andijk” (correct capitalization)
Again: crash!
Exit BaseCamp
Start BaseCamp
Search for “338 Dijkweg, Andijk” or “338 dijkweg, andijk”
BaseCamp won’t find the address!
BaseCamp only finds “Dijkwegpad, Amsterdam”
BaseCamp Shows 1x result
Searching……
Again: crash!
Next step might be:
Uninstall ALL maps.
Reinstall OpenFietsMap (Gerd also uses OpenFietsMap for testing purposes)
But will uninstall force a BaseCamp index update?
If I’m very lucky I can reproduce…?????
But I’m assuming this is BaseCamp error and not mkgmap?????
BTW: “338 Dijkweg, Andijk” is not a privacy issue. This is a pub, end-of-life after 125 years and then locals bought the pub and they will reopen next month (1 July).
So this is “promotion”: old name “Het Ankertje”, new name “Eetcafé Sels”. I did therefore search for it.
Eric (AnkEric)
*From:* mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> *On Behalf Of *Felix Hartmann *Sent:* woensdag 2 juni 2021 12:15 *To:* Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> *Subject:* Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases
well it clearly only happens with a blank in the name. That is the most common factor. Never seen one where the name is a single word. And in recent versions of Basecamp the search actually became really useful - it is way faster than at the beginning, it finds all addresses / POI - just missing the nice POI category search. I will try to get a minimalist style to crash. If that doesn't work maybe we can introduce _ instead of blanks? Better not being able to search for two words normally with crash vs not crashing. Well only for 0x1??? and 0x2??? POI. I do feel like if Basecamp can first find a 0x????? type of POI it will not crash. That is what is causing those really random results.
Last message for now - need to get some fresh air after working 6 hours straight this morning. But will try to drill down the problem a bit more tonight.
On Wed, 2 Jun 2021 at 13:03, <ankeric.osm@gmail.com> wrote:
Yes, this has been happening for a very long time (longer than my memory lane).
My “facts”:
- Not possible to reproduce; - Sometimes it will take hours before the crash occurs. So, I don’t agree: “if a good search already has been executed (single word), then the crash rarely occurs”. - Long, long ago I have tested by uninstall all mkgmaps, which left over City Navigator 2007 (yes; 2007). And still: the error did occur. But harder to reproduce; - But also: I have the impression (no fact) that more Maps increases the chance of crashing; - I have never seen GPS crash on search (Vista HCx, Etrex 30, GPSMAP 62/66) - Find Addresses (Ctrl+Alt+A) will never crash (so: work-around); - I have also seen strange addresses found, which do not match my search criteria. - And – lol – I could reproduce a BaseCamp search which will take 10 minutes to respond. Oeps, or was this a GPS search? Is this a search where BaseCamp will crash (impatience, no retry, no error handling) and GPS will try for 10 minutes and succeed???
My work-around:
Do not use BaseCamp for any Search. Not ever! I use my smartphone + OsmAnd or Google search on second PC monitor.
I will only test a new version of BaseCamp and until now, it’s always not oké. Still not oké.
In BaseCamp I can only find an object, if I know where it is….
A BaseCamp crash is 99% harmless, but at 1% I lose information (in which case always (...) relevant information, so bad for my mood).
But I might have to apologize to Garmin.
I have always considered BaseCamp to be extreme bad software, but perhaps Garmin is not to blame???
If (but only “if”) you are gone investigate and mkgmap might be the cause, I could try “memory lane”.
I have posted several times on Garmin Vendor forum about searching and not finding or finding the wrong answers or crashing.
I even might have found a way to reproduce ?????
But these posting are all in Dutch language, so therefore: “If and only if”.
Sorry, too many “???”.
But I assumed I had managed to suppress my - bad - memories
Eric (AnkEric)
*From:* mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> *On Behalf Of *Felix Hartmann *Sent:* woensdag 2 juni 2021 11:20 *To:* Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> *Subject:* Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases
Basecamp just closes 0-3 seconds after entering that term into the search bar. No warning, no error notice, nothing. Seems to have been happening a long time already. Okay this evening I will try to produce a map as small as possible that still crashes. I do not have much time now anymore - but will try if removing --split-name-index changes something. I kinda feel it has something to do with split-name-index.
On Wed, 2 Jun 2021 at 12:07, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
I couldn't reproduce the crash so far. Please provide a small map and exact instructions how to reproduce. What happens when BC crashes? Do you have some kind of report?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Mittwoch, 2. Juni 2021 10:16 An: Thomas Morgenstern; Development list for mkgmap Betreff: Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases
https://www.openstreetmap.org/node/3268115540 shop=hardware | shop=trade [0x2e01 resolution 24] does not crash - it has a full address field. Maybe if we have address for a POI it does not crash?
I have to look but I think so far only entries without an address cause a crash. Also it does not crash if being nearby and only searching for one of the words of the entry thereby finding it.
On Wed, 2 Jun 2021 at 11:08, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com>> wrote: I just thought about it - could it be related to multi word street search? Maybe what works for multi word street search is not possible for old type POI search? So it is the multi word stuff that got introduced for roads that causes the crashes in Basecamp (not sure about what happens on devices - will check that out later). --add-pois-to-areas --pois-to-areas-placement=entrance=main;entrance=yes;building=entrance;barrier=entrance --link-pois-to-ways --location-autofill=bounds,is_in,nearest and of coure --index are the most relevant to this thread options I am using.
On Wed, 2 Jun 2021 at 10:49, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com>> wrote: Even though Gerd also speaks German, I think its better to continue in English. I am quite sure that this is the same bug then. Your map does not crash because it find another POI first. I also sometimes have two POI for the same thing - one for finding it via a category POI search, the other for the symbol in the map. I do wonder if you have two POI the order in the style matters? If you change the order they are created - does it crash?
Could it be that only 0x1234 POI are affected, but the newer 0x12345 types not? As soon as it finds 0x12345 it does not crash?
Lets take Verbier Village - it is not a ciy POI https://www.openstreetmap.org/node/8307159228
I use: highway=bus_stop | amenity=bus_stop | highway=busstop | amenity=busstop | railway=bus_stop {set name='bus_stop ${name}' | 'bus_stop' } [0x2f17 resolution 24] for that one.
Cold de Jaman https://www.openstreetmap.org/node/1437437792 I have the rule: 0x1c01 resolution 24 continue] [0x11607 resolution 20-21 continue] [0x1151f resolution 22-22 continue [0x1151f resolution 23-24]]
However the first one in my map obviously is 0x1c01 - an old type.
The other ones are a bit bad examples I noticed - because there exists several entries in osm data that could be found with identical name. However I have found no actual city only poi where it crashes - Saas Fee also has other POI named the same. So maybe they cause a crash.
On Wed, 2 Jun 2021 at 10:25, Thomas Morgenstern <webmaster@img2ms.de <mailto:webmaster@img2ms.de>> wrote: Kann sein, dass es am Style liegt. Ich nutze meinen eigenen Style, der z.B einen zusätzlichen POI für Städte einfügt. ich fand vor geraumer Zeit, dass Städte in der MDR nicht eingebbar sind, wenn der String Leerzeichen enthält. Dazu hatte ich auch in der mailinglist gepostet. Hr.Petermann sagte damals, das die MDR für Städte aber nicht anpassbar sei. deshalb hat bei mir jede Stadt noch einen zusätzlichen POI einer anderen Kategorie. mfg
Am 02.06.2021 um 09:07 schrieb Felix Hartmann: Very strange - I also tested this on "Frezeitkarte" Schweiz and it crashed too. It usually does not crash if you before had a non crash search.
On Wed, 2 Jun 2021 at 08:35, Thomas Morgenstern <webmaster@img2ms.de <mailto:webmaster@img2ms.de>> wrote: Kann ich nicht bestätigen, alle hier genannten Suchen sind erfolgreich ohne Abstutz. BC Ver 4.7.0 und eigene OSM map mfg
Am 01.06.2021 um 22:32 schrieb Felix Hartmann: A user of my maps just told me that there are some crashes in the Basecamp search. There is a clear pattern - only search phrases of minimum 2 words with a space between cause crashes.
I tested it on my maps, and on other mkgmap created maps and the crashes are more or less happening on all maps.
For Switzerland some places causing crashes: Verbier Village Saas Fee Col de Jaman Pic chaussy Pic chosy
Also 2) the search must be the first from BC execution 3) if a good search already has been executed (single word), then the crash rarely occurs
Not happening with Garmin's own maps. The more entries (POIs) of the name exist - the more likely? Seems to happen more often in the French part of Switzerland compared to the Garmin part. But as many words like Saas Fee do not contain any special characters - I do not think it is related to any codepage problem. -- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
--
Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
--
Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
Hi Felix, Uninstall all Maps (10x). Before 1x Map is installed (Global Map only) BaseCamp won’t find any and won’t crash. Install OpenFietsMap_2021-05-29. I can now reproduce by OpenFietsMap: Search by OpenFietsMap for “338 dijkweg, andijk” crash! Search by OpenFietsMap + Ctrl+Alt+A: 13x found, success But also: Search by OpenFietsMap + Ctrl+Alt+A: 13x found, success Close Ctrl+Alt+A window Search by OpenFietsMap + (text box): 5x found, success My first Test would crash! But now: I cannot reproduce any crash. Not anymore! Is my Search Item now cached in index ????? Even after uninstall + install OpenFietsMap_2021-05-29: I cannot reproduce any crash. Not anymore! So my shout of cheer: One time success to crash only. Eric (AnkEric) From: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> On Behalf Of Felix Hartmann Sent: woensdag 2 juni 2021 12:15 To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases well it clearly only happens with a blank in the name. That is the most common factor. Never seen one where the name is a single word. And in recent versions of Basecamp the search actually became really useful - it is way faster than at the beginning, it finds all addresses / POI - just missing the nice POI category search. I will try to get a minimalist style to crash. If that doesn't work maybe we can introduce _ instead of blanks? Better not being able to search for two words normally with crash vs not crashing. Well only for 0x1??? and 0x2??? POI. I do feel like if Basecamp can first find a 0x????? type of POI it will not crash. That is what is causing those really random results. Last message for now - need to get some fresh air after working 6 hours straight this morning. But will try to drill down the problem a bit more tonight. On Wed, 2 Jun 2021 at 13:03, <ankeric.osm@gmail.com <mailto:ankeric.osm@gmail.com> > wrote: Yes, this has been happening for a very long time (longer than my memory lane). My “facts”: * Not possible to reproduce; * Sometimes it will take hours before the crash occurs. So, I don’t agree: “if a good search already has been executed (single word), then the crash rarely occurs”. * Long, long ago I have tested by uninstall all mkgmaps, which left over City Navigator 2007 (yes; 2007). And still: the error did occur. But harder to reproduce; * But also: I have the impression (no fact) that more Maps increases the chance of crashing; * I have never seen GPS crash on search (Vista HCx, Etrex 30, GPSMAP 62/66) * Find Addresses (Ctrl+Alt+A) will never crash (so: work-around); * I have also seen strange addresses found, which do not match my search criteria. * And – lol – I could reproduce a BaseCamp search which will take 10 minutes to respond. Oeps, or was this a GPS search? Is this a search where BaseCamp will crash (impatience, no retry, no error handling) and GPS will try for 10 minutes and succeed??? My work-around: Do not use BaseCamp for any Search. Not ever! I use my smartphone + OsmAnd or Google search on second PC monitor. I will only test a new version of BaseCamp and until now, it’s always not oké. Still not oké. In BaseCamp I can only find an object, if I know where it is…. A BaseCamp crash is 99% harmless, but at 1% I lose information (in which case always (...) relevant information, so bad for my mood). But I might have to apologize to Garmin. I have always considered BaseCamp to be extreme bad software, but perhaps Garmin is not to blame??? If (but only “if”) you are gone investigate and mkgmap might be the cause, I could try “memory lane”. I have posted several times on Garmin Vendor forum about searching and not finding or finding the wrong answers or crashing. I even might have found a way to reproduce ????? But these posting are all in Dutch language, so therefore: “If and only if”. Sorry, too many “???”. But I assumed I had managed to suppress my - bad - memories Eric (AnkEric) From: mkgmap-dev < <mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk> mkgmap-dev-bounces@lists.mkgmap.org.uk> On Behalf Of Felix Hartmann Sent: woensdag 2 juni 2021 11:20 To: Development list for mkgmap < <mailto:mkgmap-dev@lists.mkgmap.org.uk> mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases Basecamp just closes 0-3 seconds after entering that term into the search bar. No warning, no error notice, nothing. Seems to have been happening a long time already. Okay this evening I will try to produce a map as small as possible that still crashes. I do not have much time now anymore - but will try if removing --split-name-index changes something. I kinda feel it has something to do with split-name-index. On Wed, 2 Jun 2021 at 12:07, Gerd Petermann <gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com> > wrote: Hi Felix, I couldn't reproduce the crash so far. Please provide a small map and exact instructions how to reproduce. What happens when BC crashes? Do you have some kind of report? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk <mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk> > im Auftrag von Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com> > Gesendet: Mittwoch, 2. Juni 2021 10:16 An: Thomas Morgenstern; Development list for mkgmap Betreff: Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases https://www.openstreetmap.org/node/3268115540 shop=hardware | shop=trade [0x2e01 resolution 24] does not crash - it has a full address field. Maybe if we have address for a POI it does not crash? I have to look but I think so far only entries without an address cause a crash. Also it does not crash if being nearby and only searching for one of the words of the entry thereby finding it. On Wed, 2 Jun 2021 at 11:08, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com> <mailto:extremecarver@gmail.com <mailto:extremecarver@gmail.com> >> wrote: I just thought about it - could it be related to multi word street search? Maybe what works for multi word street search is not possible for old type POI search? So it is the multi word stuff that got introduced for roads that causes the crashes in Basecamp (not sure about what happens on devices - will check that out later). --add-pois-to-areas --pois-to-areas-placement=entrance=main;entrance=yes;building=entrance;barrier=entrance --link-pois-to-ways --location-autofill=bounds,is_in,nearest and of coure --index are the most relevant to this thread options I am using. On Wed, 2 Jun 2021 at 10:49, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com> <mailto:extremecarver@gmail.com <mailto:extremecarver@gmail.com> >> wrote: Even though Gerd also speaks German, I think its better to continue in English. I am quite sure that this is the same bug then. Your map does not crash because it find another POI first. I also sometimes have two POI for the same thing - one for finding it via a category POI search, the other for the symbol in the map. I do wonder if you have two POI the order in the style matters? If you change the order they are created - does it crash? Could it be that only 0x1234 POI are affected, but the newer 0x12345 types not? As soon as it finds 0x12345 it does not crash? Lets take Verbier Village - it is not a ciy POI https://www.openstreetmap.org/node/8307159228 I use: highway=bus_stop | amenity=bus_stop | highway=busstop | amenity=busstop | railway=bus_stop {set name='bus_stop ${name}' | 'bus_stop' } [0x2f17 resolution 24] for that one. Cold de Jaman https://www.openstreetmap.org/node/1437437792 I have the rule: 0x1c01 resolution 24 continue] [0x11607 resolution 20-21 continue] [0x1151f resolution 22-22 continue [0x1151f resolution 23-24]] However the first one in my map obviously is 0x1c01 - an old type. The other ones are a bit bad examples I noticed - because there exists several entries in osm data that could be found with identical name. However I have found no actual city only poi where it crashes - Saas Fee also has other POI named the same. So maybe they cause a crash. On Wed, 2 Jun 2021 at 10:25, Thomas Morgenstern <webmaster@img2ms.de <mailto:webmaster@img2ms.de> <mailto:webmaster@img2ms.de <mailto:webmaster@img2ms.de> >> wrote: Kann sein, dass es am Style liegt. Ich nutze meinen eigenen Style, der z.B einen zusätzlichen POI für Städte einfügt. ich fand vor geraumer Zeit, dass Städte in der MDR nicht eingebbar sind, wenn der String Leerzeichen enthält. Dazu hatte ich auch in der mailinglist gepostet. Hr.Petermann sagte damals, das die MDR für Städte aber nicht anpassbar sei. deshalb hat bei mir jede Stadt noch einen zusätzlichen POI einer anderen Kategorie. mfg Am 02.06.2021 um 09:07 schrieb Felix Hartmann: Very strange - I also tested this on "Frezeitkarte" Schweiz and it crashed too. It usually does not crash if you before had a non crash search. On Wed, 2 Jun 2021 at 08:35, Thomas Morgenstern <webmaster@img2ms.de<mailto:webmaster@img2ms.de <mailto:webmaster@img2ms.de> >> wrote: Kann ich nicht bestätigen, alle hier genannten Suchen sind erfolgreich ohne Abstutz. BC Ver 4.7.0 und eigene OSM map mfg Am 01.06.2021 um 22:32 schrieb Felix Hartmann: A user of my maps just told me that there are some crashes in the Basecamp search. There is a clear pattern - only search phrases of minimum 2 words with a space between cause crashes. I tested it on my maps, and on other mkgmap created maps and the crashes are more or less happening on all maps. For Switzerland some places causing crashes: Verbier Village Saas Fee Col de Jaman Pic chaussy Pic chosy Also 2) the search must be the first from BC execution 3) if a good search already has been executed (single word), then the crash rarely occurs Not happening with Garmin's own maps. The more entries (POIs) of the name exist - the more likely? Seems to happen more often in the French part of Switzerland compared to the Garmin part. But as many words like Saas Fee do not contain any special characters - I do not think it is related to any codepage problem. -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> <mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org
participants (3)
-
ankeric.osm＠gmail.com -
Felix Hartmann -
Gerd Petermann