Hi Ticker,
reg. largeObjectArea:
I found some cases where 5 or more boundary lines with > 1000 points ended up
in the same small map-area,
e.g. in 63240103 with my split-file of Germany. This happens quite often
because those lines are added to the map
for different admin-levels.
I can send
Hi Gerd
Sorry about the delay in replying.
I think the solution needs to be along the lines of the way
largeObjectArea creates addition subdivisions, but with changed rules,
and replacing largeObjectArea and !useNormalSplit logic. Is there an
existing problem with largeObjectArea?
Some thoughts
Hi Ticker,
(see 3756)
the useNormalSplit code is still needed, maybe because the rules for the
largeObjectAreas are not okay.
So if you find a better solution please let me know. I am also no longer
convinced that the code in MapSplitter
which sets wantSplit to true is a good idea, esp. in
Hi Ticker,
the original intention of the useNormalSplit code was to solve a problem with
two huge polygons having the same center point.
At that time I tried to minimize the possibility that this code is executed in
other cases.
However, it seems that this is dead code since r3351 because of
Hi Gerd
Yes; however, regardless of useNormalSplit, with --order-by... the
shapes need to be split into their correct area.
This bit of code has always troubled me. I wasn't sure if its objective
was to lessen the chance of empty subdivisions or to lessen the chance
of exceeding maximum data
Hi all,
attached is a patch to solve this problem.
A binary is here:
http://files.mkgmap.org.uk/download/327/mkgmap.jar
@Ticker: Please review.
I've noticed that with --order-by-decreasing-area
the code in MapArea to set useNormalSplit may not be used because
the condition used[0] != used[1]
