Hi,
recently I started playing with splitting using polygon files, primarily
based on the documentation in
https://www.mkgmap.org.uk/doc/splitter.html. 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...).
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.
1. Although the doc for --polygon-files says:
"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."
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.
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)?
Is this functionatlity still in place, or has it been deprecated?
Neither am I shure, I understand the target.
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?
2. The .poly files should follow the Osmosis syntax, which also specifies:
"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."
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.
Does splitter respect this syntax at all? (testing only, no application)
3. 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?
Is that 80% tiles @ > 80% targeted nodes and <3% tiles below 33%
targeted nodes?
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"?
What would define a good split?
4. 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.
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?
5. 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.
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?
6. Not being mentioned in the doc but (briefly) in the --help output at
least 2 options seem to be accessible and might be involved:
a) --search-limit, seems to be set and increased automatically if
needed
b) --num-tiles, seems to be unset/unused by default
Any use to temper with a), p.e. start below default?
What would be the difference (benefit?) of using b) over decreasing
max-nodes to control tile count?
Sorry for so many questions; thanks for any input ;-)
//Felix Herwegh
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
