<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi,</p>
<p>recently I started playing with splitting using polygon files,
primarily based on the documentation in
<a class="moz-txt-link-freetext" href="https://www.mkgmap.org.uk/doc/splitter.html">https://www.mkgmap.org.uk/doc/splitter.html</a>. Got it to work, even
with multiple areas in one .poly file (testing only, no
application). The idea is to better cut out neighboring countries'
and sea area for countries poorly aligned to lat/lon (NL, BE,
IT...).<br>
</p>
<p>Digging deeper though, severeal questions arose, that I couldn't
answer, neither by the doc mentioned above nor by the (seemingly
somewhat more topical but brief) --help output of splitter, not
even by searching this lists archives.</p>
<ol>
<li>Although the doc for --polygon-files says:<br>
"If the polygon
area(s) describe(s) a rectilinear area with no more than 40
vertices, splitter
will try to create output files that fit exactly into the area,
otherwise it
will approximate the polygon area with rectangles." <br>
So far I have not been able to generate a single split, that
exactly follows the polygon, even if quite simple (<<40
points). I always get tiles on or extending the polygone.<br>
I'm not shure, I understand that quoted sentence. Does it (for a
single area) mean a polygone of <= 41 points, hence <=40
lines (if first and last point are identical)?<br>
Is this functionatlity still in place, or has it been
deprecated?<br>
Neither am I shure, I understand the target.<br>
Should splitter generate non-rectangular tiles with an alignment
according to a polygone at all, or only rectangular aligned to
lat/lon? If the latter, "exactly follows" could only work for
polygones having each line parallel lat or lon? <br>
<br>
</li>
<li>The .poly files should follow the Osmosis syntax, which also
specifies: <br>
"The polygon section name may optionally be prefixed with "!" to
subtract the polygon. The section(s) containing the larger area
from which to subtract should be listed first. All the polygon
sections are combined together to create the final filter area."<br>
I couldn't make that work. Tried "!" directly in front of the
section-name, separated by blank and on an individual line.
Splitter does not complain, but seems generate identical splits
for all 3 tries and without that area specified at all.<br>
Does splitter respect this syntax at all? (testing only, no
application)<br>
<br>
</li>
<li>From what I've read so far, one might want to aim for
"solution is nice", sufficiently even distributed node counts
over all tiles, right? <br>
Is that 80% tiles @ > 80% targeted nodes and <3% tiles
below 33% targeted nodes? <br>
Why do I get nice solutions although (after having the search
limit being increased in several steps) splitter comments "No
good solution found, trying to find one accepting anything"?<br>
What would define a good split?<br>
<br>
</li>
<li>My initial approach was to increase tile count to better
follow the polygone. I basically did that by decreasing
--max-nodes and, when splitter ran into tiles having >100%
targeted nodes, raising resolution to allow for those tiles
(cities...) to be smaller. I eaven had the "feeling", that my
Edge 1040 appreciated more smaller tiles by zooming and
scrolling smoother.<br>
On the other hand from the doc and for example some discussion
here between Gerd and Felix Hartmann regarding and around r609
release I've got the impression, that the typical target might
be minimum tile count, as long as some (Garmin?) max. tilesize
(?) is not reached. Why is that?<br>
<br>
</li>
<li>Increasing a significant portion of Germany maps tile count
~by factor 7 from ~280 tiles (@ max-nodes=1200000,
resolution=13) to ~2000 tiles (@ max-nodes=150000,
resolution=15) only took around an additional 8% in gmappsupp
filesize, but another factor of 3 to ~6000 tiles (@
max-nodes=50000, resolution=??) made it "explode" to 300% of the
original size. This map did still load (altough with some
spinner delay) in QMapShack, but no longer on my Garmin device,
not even got listed. <br>
Just out of curiosity: I can understand some increased overhead
due to more tiles (as in the first step), but no progressive
increase like this, since the OSM data basically stays
identical. Is there some distinct border effect involved, like
having to switch to some bigger data-type at some tile count or
something similar?<br>
<br>
</li>
<li>Not being mentioned in the doc but (briefly) in the --help
output at least 2 options seem to be accessible and might be
involved:<br>
a) --search-limit, seems to be set and increased automatically
if needed <br>
b) --num-tiles, seems to be unset/unused by default<br>
Any use to temper with a), p.e. start below default?<br>
What would be the difference (benefit?) of using b) over
decreasing max-nodes to control tile count?<br>
</li>
</ol>
<p></p>
<p>Sorry for so many questions; thanks for any input ;-)<br>
</p>
<p>//Felix Herwegh <br>
</p>
</body>
</html>