[mkgmap-dev] split using --polgon-file

Wed Apr 3 14:18:30 BST 2024

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20240403/8c81de81/attachment.html>