Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases

[Felix Hartmann]

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,  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@gmail.com 
> *Sent:* woensdag 2 juni 2021 17:02
> *To:* 'Development list for mkgmap' 
> *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@gmail.com 
> *Sent:* woensdag 2 juni 2021 15:08
> *To:* 'Development list for mkgmap' 
> *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 capi

Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases

[ankeric.osm]

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@gmail.com  
Sent: woensdag 2 juni 2021 17:02
To: 'Development list for mkgmap' 
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@gmail.com   
mailto:ankeric@gmail.com> > 
Sent: woensdag 2 juni 2021 15:08
To: 'Development list for mkgmap' 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 yea

Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases

[ankeric.osm]

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@gmail.com  
Sent: woensdag 2 juni 2021 15:08
To: 'Development list for mkgmap' 
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 mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk> > On Behalf Of Felix Hartmann
Sent: woensdag 2 juni 2021 12:15
To: Development list for mkgmap 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 
s

Re: [mkgmap-dev] special case where splitting fails without a log message

[Gerd Petermann]

Hi Ticker,

That seems to work better. I still see some error messages but those are 
probably really invalid shapes produced by ShapeMerger. At least I see that one 
point is visited more than twice and that should not happen.

Maybe you can add unit tests to test the error cases?

Gerd


Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Mittwoch, 2. Juni 2021 16:06
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] special case where splitting fails without a log 
message

Hi Gerd

I've found and fixed some stupid mistakes - sorry for wasting your
time.

Patch attached - works with your test case.

Ticker

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] splitter default resolution 13 and overview map from default style

[Ticker Berkin]

Hi all

Outermost level should be as Gerd suggests
5 levels of overview seems excessive - what about:

overview-levels = 4:17, 5:15, 6:13

Ticker


On Tue, 2021-06-01 at 13:29 +, Gerd Petermann wrote:
> Hi all,
> 
> I am not sure but I think it is a bad idea to have 
> overview-levels = 4:17, 5:16, 6:15, 7:14, 8:12
> in the default style.
> The lowest resolution is 12 while splitter uses the default 13 for
> its resolution. This also means that tiles from splitter are aligned
> to a resolution of 13. The lowest level in the overview map is
> therefore sometimes much more distorted at tile boundaries than the
> next higher. I think it should be changed to 
> overview-levels = 4:17, 5:16, 6:15, 7:14, 8:13
> 
> I've never thought about this relationship between splitter and the
> overview map. Just wondered why my test data looks so ugly at
> resolution 12.
> An alternative would be to remove the lowest level completely.
> Maybe mkgmap should print a warning when tiles are not aligned for
> the lowest resolution used in the map?
> 
> Any thoughts? 
> 
> Gerd
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases

[ankeric.osm]

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  On Behalf Of Felix 
Hartmann
Sent: woensdag 2 juni 2021 12:15
To: Development list for mkgmap 
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, mailto:ankeric@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-boun...@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 mailto:gpetermann_muenc...@hotmail.com> > wrote:

Hi Felix,

I could

Re: [mkgmap-dev] special case where splitting fails without a log message

[Ticker Berkin]

Hi Gerd

I've found and fixed some stupid mistakes - sorry for wasting your
time.

Patch attached - works with your test case.

Ticker

Index: src/uk/me/parabola/util/ShapeSplitter.java
===
--- src/uk/me/parabola/util/ShapeSplitter.java	(revision 4753)
+++ src/uk/me/parabola/util/ShapeSplitter.java	(working copy)
@@ -275,11 +275,23 @@
 		return pointsToPath2D(outputList, countVals);
 	}
 
-/* Dec16/Jan17. Ticker Berkin. New implementation for splitting shapes.
+// Dec16/Jan17. Ticker Berkin. New implementation for splitting shapes and clipping
 
-Eventually maybe can be used instead of some of the above and elsewhere
-*/
+	private boolean detectedProblems;
+	private List newLess, newMore;
+	private String gpxDirectory;
+	private long fullArea;
 
+	private List lineInfo; // for the side we are working on
+	private List> origList; // ditto
+
+	private boolean multSameLow; // lineInfo.sort(comparator) might set this
+
+	private void logMsg(Object ... olist) {
+		detectedProblems = true;
+		log.warn(olist);
+	}
+
 	/**
 	 * Service routine for processLineList. Processes a nested list of holes within a shape or
 	 * list of shapes within a hole.
@@ -290,11 +302,8 @@
 	 * @param endEnclosed point where starting line ends on dividing line.
 	 * @param addHolesToThis if not null, then called from a shape and subtract holes from it
 	 * otherwise new shapes within a hole.
-	 * @param lineInfo list of lines.
-	 * @param origList list of shapes to which we append new shapes.
 	 */
-	private static int doLines(int startInx, int endEnclosed, MergeCloseHelper addHolesToThis,
-   List lineInfo, List> origList) {
+	private int doLines(int startInx, int endEnclosed, MergeCloseHelper addHolesToThis) {
 		int inx = startInx;
 		final boolean calledFromHole = addHolesToThis == null;
 		while (inx < lineInfo.size()) {
@@ -304,9 +313,9 @@
 			if (thisLine.lowPoint == endEnclosed && thisLine.highPoint == endEnclosed) // consider carefully
 if (calledFromHole == (thisLine.areaOrHole == -1))
 	break; // stop if same type
-			inx = doLines(inx+1, thisLine.highPoint, calledFromHole ? thisLine : null, lineInfo, origList);
+			inx = doLines(inx+1, thisLine.highPoint, calledFromHole ? thisLine : null);
 			if (calledFromHole) // handling list of shapes
-thisLine.closeAppend(origList, true);
+thisLine.closeAppend(true);
 			else // handling list of holes
 addHolesToThis.addHole(thisLine);
 		}
@@ -317,17 +326,17 @@
 	 * Service routine for splitShape. Takes list of lines and appends distinct shapes
 	 * @param lineInfo list of lines that start and end on the dividing line (or orig startPoint)
 	 * @param origList list of shapes to which we append new shapes formed from above
-	 * @param fullArea of orig polygon. used for sign and handling of last line segment
 	 */
-	private static int processLineList(List lineInfo, List> origList, long fullArea) {
-		int errorCount = 0;
+	private void processLineList(List lineInfo, List> origList) {
+		this.lineInfo = lineInfo;
+		this.origList = origList;
 		if (origList == null) // never wanted this side
-			return errorCount;
+			return;
 		MergeCloseHelper firstLine = lineInfo.get(0);
 		if (lineInfo.size() == 1) { // single shape that never crossed line
 			if (!firstLine.points.isEmpty()) // all on this side
-firstLine.closeAppend(origList, false);
-			return errorCount;
+firstLine.closeAppend(false);
+			return;
 		}
 		// look at last item in list of lines
 		MergeCloseHelper lastLine = lineInfo.get(lineInfo.size()-1);
@@ -335,14 +344,14 @@
 			lineInfo.remove(lineInfo.size()-1);
 		else { // ended up on this side and must have crossed the line
 			// so first element is really the end of the last
-			lastLine.combineFirstIntoLast(firstLine, fullArea);
+			lastLine.combineFirstIntoLast(firstLine);
 			lineInfo.remove(0);
 			firstLine = lineInfo.get(0);
 		}
 		if (lineInfo.size() == 1) { // simple poly that crossed once and back
 			firstLine.setMoreInfo(0);
-			firstLine.closeAppend(origList, true);
-			return errorCount;
+			firstLine.closeAppend(true);
+			return;
 		}
 		// Above were the simple cases - probably 99% of calls.
 
@@ -358,7 +367,6 @@
 		// check and set any missing directions based on signs of full/area
 		boolean someDirectionsNotSet = false;
 		int areaDirection = 0;
-		String diagMsg = "";
 		for (MergeCloseHelper thisLine : lineInfo) {
 			thisLine.setMoreInfo(fullAreaSign);
 			if (thisLine.direction == 0)
@@ -368,78 +376,208 @@
 if (areaDirection == 0)
 	areaDirection = tmpAreaDirection;
 else if (areaDirection != tmpAreaDirection)
-	diagMsg += "Direction/Area conflict.";
+	logMsg("Direction/Area conflict", fullAreaSign, areaDirection, tmpAreaDirection);
 			}
 		}
 		if (someDirectionsNotSet) {
 			if (areaDirection == 0)
-diagMsg += "Cant deduce direction/Area mapping.";
+logMsg("Can't deduce direction/Area mapping", fullAreaSign);
 			else
 

Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases

[ankeric.osm]

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  On Behalf Of Felix 
Hartmann
Sent: woensdag 2 juni 2021 12:15
To: Development list for mkgmap 
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, mailto:ankeric@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 smart

Re: [mkgmap-dev] special case where splitting fails without a log message

[Ticker Berkin]

Hi Gerd

I was beginning to suspect this - there were 2 very close cut-lines
which is why I thought coords were not behaving.

I've reproduced with the .osm and am investigating 

Ticker

On Wed, 2021-06-02 at 09:50 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> yes, was with splitShapeFix_5_lowRes.patch
> I've just noticed that s_3 and s_4 were from a different split.
> The shape was the result of various steps with "too small island
> removal" and "cut again after full merge".
> 
> Maybe you can reproduce with the attached file. I've loaded the gpx
> into JOSM, fixed the duplicated points and used Shift+J (join
> overlapping areas)
> 
> Gerd
> 
> 
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Mittwoch, 2. Juni 2021 11:23
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] special case where splitting fails without
> a log message
> 
> Hi Gerd
> 
> I see what you mean. Is this with splitShaeFix_5_lowRes.patch?
> I'll investigate. Is there an OSM file I can run with?
> 
> Ticker
> 
> On Wed, 2021-06-02 at 06:32 +, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > please check 
> > https://files.mkgmap.org.uk/download/509/special-v5.zip
> > 
> > Can you tell me why ShapeSplitter drops some points, e.g the one
> > near
> > 68.2669706, 15.1206053 without complaining?
> > None of the points in the original data is visited more than twice
> > and all highprec equal points are unique.
> > 
> > I'm working on an improvement to make the connecting lines shorter,
> > but I don't see yet how I can avoid to have connecting lines like
> > that.
> > 
> > Gerd
> > 
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Ticker Berkin 
> > Gesendet: Dienstag, 1. Juni 2021 17:18
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] special case where splitting fails
> > without
> > a log message
> > 
> > Hi Gerd
> > 
> > I've added code to deal with some variants of the case as described
> > -
> > I
> > hope this will be enough to cope with more complex shapes generated
> > by
> > ShapeMerger.
> > 
> > There might be a bit more I can do without having to resort to more
> > complex geometry analysis if it still gives problems.
> > 
> > I've also restructured it a bit.
> > 
> > Patch attached based on low-res-opt. Trunk version will be the same
> > (but the patch would be different)
> > 
> > Ticker
> > 
> > On Mon, 2021-05-31 at 17:12 +0100, Ticker Berkin wrote:
> > > Hi Gerd
> > > 
> > > shapeSplitter will have problems (ie get it wrong some of the
> > > time)
> > > where there are in/out lines to a hole that share the same cut
> > > point
> > > as
> > > a line that is the boundary between a shape and hole; could be
> > > many
> > > holes (or shapes) and many lines. The simple sort/dedupe I was
> > > doing
> > > isn't adequate. I'll come up with something better tomorrow.
> > > 
> > > Ticker
> > > 
> > > ___
> > > mkgmap-dev mailing list
> > > mkgmap-dev@lists.mkgmap.org.uk
> > > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> > ___
> > mkgmap-dev mailing list
> > mkgmap-dev@lists.mkgmap.org.uk
> > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases

[Felix Hartmann]

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,  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  *On Behalf Of
> *Felix Hartmann
> *Sent:* woensdag 2 juni 2021 11:20
> *To:* Development list for mkgmap 
> *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_muenc...@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  im Auftrag von
> Felix Hartmann 
> 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  > 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 p

Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases

[ankeric.osm]

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  On Behalf Of Felix 
Hartmann
Sent: woensdag 2 juni 2021 11:20
To: Development list for mkgmap 
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 mailto:gpetermann_muenc...@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 mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk> > im Auftrag von Felix Hartmann 
mailto:extremecar...@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 mailto:extremecar...@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 mailto:extremecar...@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

Re: [mkgmap-dev] special case where splitting fails without a log message

[Ticker Berkin]

Hi Gerd

I'm thinking this is a problem with high-precision points and the
coordPool

Ticker

On Wed, 2021-06-02 at 10:23 +0100, Ticker Berkin wrote:
> Hi Gerd
> 
> I see what you mean. Is this with splitShaeFix_5_lowRes.patch?
> I'll investigate. Is there an OSM file I can run with?
> 
> Ticker
> 
> On Wed, 2021-06-02 at 06:32 +, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > please check 
> > https://files.mkgmap.org.uk/download/509/special-v5.zip
> > 
> > Can you tell me why ShapeSplitter drops some points, e.g the one
> > near
> > 68.2669706, 15.1206053 without complaining?
> > None of the points in the original data is visited more than twice
> > and all highprec equal points are unique.
> > 
> > I'm working on an improvement to make the connecting lines shorter,
> > but I don't see yet how I can avoid to have connecting lines like
> > that.
> > 
> > Gerd
> > 
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Ticker Berkin 
> > Gesendet: Dienstag, 1. Juni 2021 17:18
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] special case where splitting fails
> > without
> > a log message
> > 
> > Hi Gerd
> > 
> > I've added code to deal with some variants of the case as described
> > -
> > I
> > hope this will be enough to cope with more complex shapes generated
> > by
> > ShapeMerger.
> > 
> > There might be a bit more I can do without having to resort to more
> > complex geometry analysis if it still gives problems.
> > 
> > I've also restructured it a bit.
> > 
> > Patch attached based on low-res-opt. Trunk version will be the same
> > (but the patch would be different)
> > 
> > Ticker
> > 
> > On Mon, 2021-05-31 at 17:12 +0100, Ticker Berkin wrote:
> > > Hi Gerd
> > > 
> > > shapeSplitter will have problems (ie get it wrong some of the
> > > time)
> > > where there are in/out lines to a hole that share the same cut
> > > point
> > > as
> > > a line that is the boundary between a shape and hole; could be
> > > many
> > > holes (or shapes) and many lines. The simple sort/dedupe I was
> > > doing
> > > isn't adequate. I'll come up with something better tomorrow.
> > > 
> > > Ticker
> > > 
> > > ___
> > > mkgmap-dev mailing list
> > > mkgmap-dev@lists.mkgmap.org.uk
> > > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> > ___
> > mkgmap-dev mailing list
> > mkgmap-dev@lists.mkgmap.org.uk
> > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases

[Felix Hartmann]

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  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_muenc...@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  im Auftrag von
>> Felix Hartmann 
>> 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 > > 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 > > 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 > > 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 > > 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:

Re: [mkgmap-dev] special case where splitting fails without a log message

[Ticker Berkin]

Hi Gerd

I see what you mean. Is this with splitShaeFix_5_lowRes.patch?
I'll investigate. Is there an OSM file I can run with?

Ticker

On Wed, 2021-06-02 at 06:32 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> please check https://files.mkgmap.org.uk/download/509/special-v5.zip
> 
> Can you tell me why ShapeSplitter drops some points, e.g the one near
> 68.2669706, 15.1206053 without complaining?
> None of the points in the original data is visited more than twice
> and all highprec equal points are unique.
> 
> I'm working on an improvement to make the connecting lines shorter,
> but I don't see yet how I can avoid to have connecting lines like
> that.
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Dienstag, 1. Juni 2021 17:18
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] special case where splitting fails without
> a log message
> 
> Hi Gerd
> 
> I've added code to deal with some variants of the case as described -
> I
> hope this will be enough to cope with more complex shapes generated
> by
> ShapeMerger.
> 
> There might be a bit more I can do without having to resort to more
> complex geometry analysis if it still gives problems.
> 
> I've also restructured it a bit.
> 
> Patch attached based on low-res-opt. Trunk version will be the same
> (but the patch would be different)
> 
> Ticker
> 
> On Mon, 2021-05-31 at 17:12 +0100, Ticker Berkin wrote:
> > Hi Gerd
> > 
> > shapeSplitter will have problems (ie get it wrong some of the time)
> > where there are in/out lines to a hole that share the same cut
> > point
> > as
> > a line that is the boundary between a shape and hole; could be many
> > holes (or shapes) and many lines. The simple sort/dedupe I was
> > doing
> > isn't adequate. I'll come up with something better tomorrow.
> > 
> > Ticker
> > 
> > ___
> > mkgmap-dev mailing list
> > mkgmap-dev@lists.mkgmap.org.uk
> > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases

[Felix Hartmann]

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 
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  im Auftrag von
> Felix Hartmann 
> 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  > 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  > 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  > 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  > 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 

Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases

[Gerd Petermann]

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  im Auftrag von Felix 
Hartmann 
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 
mailto:extremecar...@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 
mailto:extremecar...@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 
mailto:webmas...@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 
mailto:webmas...@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 ma

Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases

[Felix Hartmann]

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  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 
> 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 
>> 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 
>>> 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-...@lists.mkgmap.org.ukhttps://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



>>>
>>> --
>>> Felix Hartman - Openmtbmap.org & VeloMap.org
>>>
>>>
>>>
>>
>> --
>> Felix Hartman - Openmtbmap.org & Ve

Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases

[Felix Hartmann]

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  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 
> 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 
>> 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-...@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
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Commit r4735: improve Logging/ debugging : todegrees.patch

[Gerd Petermann]

Hi Mike,

yes, sorry, forgot to adapt the source after applying the patch on mkgmap. 
Fixed now:
https://www.mkgmap.org.uk/websvn/revision.php?repname=display&rev=558

Gerd


Von: mkgmap-dev  im Auftrag von Mike 
Baggaley 
Gesendet: Mittwoch, 2. Juni 2021 09:50
An: 'Development list for mkgmap'
Betreff: [mkgmap-dev] Commit r4735: improve Logging/ debugging :
todegrees.patch

>Version mkgmap-r4735 was committed by gerd on Mon, 24 May 2021

>improve Logging/ debugging : todegrees.patch
>- change Coord.toString() to return the same as toDegreeString() instead of
a pair of Garmin units
>- add method toGarminString() to get a string with Garmin units
>- deprecate toDegreeString()

It appears that display no longer compiles as it uses toDegreeString():

compile:
[javac] Compiling 76 source files to
C:\Users\Mike\Documents\MapBuild\Programs\display\build\classes
[javac]
C:\Users\Mike\Documents\MapBuild\Programs\display\src\test\svg\subdiv\SvgDiv
Doc.java:83: error: cannot find symbol
[javac] .setText(String.format("%d: %s",
div.getNumber(), div.getCenter().toDegreeString()));
[javac]
^
[javac]   symbol:   method toDegreeString()
[javac]   location: class Coord
[javac] 1 error

BUILD FAILED

Cheers,
Mike

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Commit r4735: improve Logging/ debugging : todegrees.patch

[Mike Baggaley]

>Version mkgmap-r4735 was committed by gerd on Mon, 24 May 2021

>improve Logging/ debugging : todegrees.patch
>- change Coord.toString() to return the same as toDegreeString() instead of
a pair of Garmin units
>- add method toGarminString() to get a string with Garmin units
>- deprecate toDegreeString()

It appears that display no longer compiles as it uses toDegreeString():

compile:
[javac] Compiling 76 source files to
C:\Users\Mike\Documents\MapBuild\Programs\display\build\classes
[javac]
C:\Users\Mike\Documents\MapBuild\Programs\display\src\test\svg\subdiv\SvgDiv
Doc.java:83: error: cannot find symbol
[javac] .setText(String.format("%d: %s",
div.getNumber(), div.getCenter().toDegreeString()));
[javac]
^
[javac]   symbol:   method toDegreeString()
[javac]   location: class Coord
[javac] 1 error

BUILD FAILED

Cheers,
Mike

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases

[Felix Hartmann]

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  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 
> 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-...@lists.mkgmap.org.ukhttps://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
>>
>>
>
> --
> 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