[mkgmap-dev] [Patch] "Area too small to split at " ... followed by "Too many POIs at location " error message

Mon Jan 16 15:48:58 GMT 2017

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 combination with --order-by-decreasing-area I guess
it would be better to avoid unnessary splits. Am i right?

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen at hotmail.com>
Gesendet: Sonntag, 15. Januar 2017 15:10:48
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] [Patch] "Area too small to split at " ... followed by "Too many POIs at location " error message

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 the handling with largeObjectAreas.
I think I should remove it.

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
Gesendet: Sonntag, 15. Januar 2017 14:41:27
An: mkgmap-dev at lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] [Patch] "Area too small to split at " ... followed by "Too many POIs at location " error message

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 sizes in the subdivision.

Maybe splitIntoAreas (and, for that matter, points) shouldn't set
used[area] to true so that lines can be distributed between the two
areas.

Also the test ... && (this.lines.size() > 1 || this.shapes.size() > 1))
should take ((lines.size + shapes.size) > 1). But not including shapes
if --order-by...

Another possibility is that the caller of MapArea.split, with accurate
information on the number/size of subdivision data items, knowing that
this is more that will fit into a subDivision and further splits by
area are not possible, passes a flag that make it send excess items
into other subdivisions - very much like the way it handles
largeObjectAreas

Ticker

On Sun, 2017-01-15 at 10:00 +0000, Gerd Petermann wrote:
> 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] is never true when there is a shape
> in that area. I think this can cause problems if we also have some
> complex
> lines with (nearly) the same center point in the same area.
>
> Gerd
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev