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

[Gerd Petermann]

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] Basecamp crashes on search if searching for many 2+ word phrases

[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
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Ticker Berkin]

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-devIndex: src/uk/me/parabola/util/ShapeSplitter.java
===
--- src/uk/me/parabola/util/ShapeSplitter.java	(revision 4752)
+++ 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 lineInfoParam, List> origListParam) {
+		lineInfo = lineInfoParam;
+		origList = origListParam;
 		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);
-			ret

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

[Joris Bo]

Hallo Gerd



You just solved a long time wish of getting country borders more nice at low 
zoom:

Left with overview 8:12  and right with lowest  8:13 (which is much nicer !)





Basecamp zoomlevel 300km

Gulf of Genua



[cid:image001.png@01D75704.89BA1B80]





Met vriendelijke groeten,



Joris Bo

jori...@hotmail.com



-Oorspronkelijk bericht-
Van: mkgmap-dev 
mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
 Namens Gerd Petermann
Verzonden: dinsdag 1 juni 2021 15:30
Aan: mkgmap-dev@lists.mkgmap.org.uk
Onderwerp: [mkgmap-dev] splitter default resolution 13 and overview map from 
default style



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

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

[Gerd Petermann]

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