Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution 23 raster problems

[Gerd Petermann]

Hi all,

my observations at resolution 22:
I think the patch re-introduces rendering problems at T-shaped crossings, 
sometimes they look like t-shapes at lower resolutions.
Sample: https://www.openstreetmap.org/node/260418111

It seems to filter more small polygons, even with  --min-size-polygon=0.
I think it tends to make polygons smaller, not sure why.

It sometimes reduces wrong zig-zagging, but only for ways with many points. In 
cities, where roads are often split into many small parts it sometimes makes 
things worse.

It probably helps for the special case contour lines and therefore I suggest to 
limit it to them.

Maybe the code to find the best place for a rounded coord should also consider 
to remove the point if that would give the best result.

Gerd


Von: mkgmap-dev  im Auftrag von Gerd 
Petermann 
Gesendet: Mittwoch, 28. April 2021 15:21
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution 23 
raster problems

Hi Felix,

I expect (more) small missing parts of complex shapes like forests or waterway 
areas (those without mkgmap:skipSizeFilter=true) and more obvious differences 
between shapes and lines, e.g. if a style renders outlines of buildings.

The maps are very different at res 22, so it is hard to say if there are more  
improvements then worsenings.

I've experimented with different orders of filters in the past. It's difficult 
to test because the changes heavily depend on the Styte AND the mapped objects 
AND the mappers preferences. For example, if landuse areas are glued to 
highways or not, if landuse areas are glued to other landuse areas or if there 
nodes are just very close.

Gerd


Von: mkgmap-dev  im Auftrag von Felix 
Hartmann 
Gesendet: Mittwoch, 28. April 2021 14:58
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution 23 
raster problems

Oh I thought it was mainly meant for contourlines. Did not know you intend it 
to be used in general. I am not really sure how and where to check for quality.

On Wed, 28 Apr 2021 at 20:13, Gerd Petermann 
mailto:gpetermann_muenc...@hotmail.com>> wrote:
Hi Felix,

your screen shots only show contour lines but the patch works on all types of 
lines and polygons. So, please also check the results with other maps.

Gerd


Von: mkgmap-dev 
mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
 im Auftrag von Felix Hartmann 
mailto:extremecar...@gmail.com>>
Gesendet: Mittwoch, 28. April 2021 04:54
An: Development list for mkgmap; Andrzej Popowski
Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution 23 
raster problems

forgot 1.3 value - that is good enough (and this location is not the most 
difficult, but there are very few places that are worse. So I feel it's good 
enough as if it's fine here - there are very very few other places that are 
still problematic.


On Wed, 28 Apr 2021 at 10:50, Felix Hartmann 
mailto:extremecar...@gmail.com>>>
 wrote:
Thanks for that patch, the improvement is not as big as from the previous patch 
- but there is some.
I analysed it a bit more - and I think there needs to be one more change - 
actually in general and not only for contourlines.

We need different values for the douglas peucker algorithm depending on 
resolution!

Right now we can only set one value, and that is multiplied for each resolution?
Based on the current state I would like to have

resolution
24= 0.0 or maybe actually have it active at 24 as well trying a value of 0.3 or 
so. Where there any problems with autorouting or why is it not possible to use 
it at resolution 24 as well?
23=1.3
22=2.6
21=3.9
20-11=5.4


Especially if we produce a map without resolution 24, then resolution 23 needs 
to have much lower DP value than the subsequent resolutions. Using 1.3 for 
resolution 23 makes the quality IMHO good enough to be used for an contourlines 
only map for GPS devices and skipping resolution 24 altogether. For Desktop use 
resolution 24 may still make sense for contourlines - but even then the 
difference is only in very steep areas.

Attached some screenshots at resolution 24, and at 23 with different DP values 
and one of patch2.

On Tue, 27 Apr 2021 at 23:16, Andrzej Popowski 
mailto:po...@poczta.onet.pl>>>
 wrote:
Hi,

some more experiments, see attached patch. I have tried to optimize
rounding of coordinates for lowest distance to line. This is not good
for polygons, because can creates gaps between adjacent polygons.

--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk>
https://www.mk

Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution 23 raster problems

[Gerd Petermann]

Hi Felix,

I expect (more) small missing parts of complex shapes like forests or waterway 
areas (those without mkgmap:skipSizeFilter=true) and more obvious differences 
between shapes and lines, e.g. if a style renders outlines of buildings.

The maps are very different at res 22, so it is hard to say if there are more  
improvements then worsenings.

I've experimented with different orders of filters in the past. It's difficult 
to test because the changes heavily depend on the Styte AND the mapped objects 
AND the mappers preferences. For example, if landuse areas are glued to 
highways or not, if landuse areas are glued to other landuse areas or if there 
nodes are just very close.

Gerd


Von: mkgmap-dev  im Auftrag von Felix 
Hartmann 
Gesendet: Mittwoch, 28. April 2021 14:58
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution 23 
raster problems

Oh I thought it was mainly meant for contourlines. Did not know you intend it 
to be used in general. I am not really sure how and where to check for quality.

On Wed, 28 Apr 2021 at 20:13, Gerd Petermann 
mailto:gpetermann_muenc...@hotmail.com>> wrote:
Hi Felix,

your screen shots only show contour lines but the patch works on all types of 
lines and polygons. So, please also check the results with other maps.

Gerd


Von: mkgmap-dev 
mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
 im Auftrag von Felix Hartmann 
mailto:extremecar...@gmail.com>>
Gesendet: Mittwoch, 28. April 2021 04:54
An: Development list for mkgmap; Andrzej Popowski
Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution 23 
raster problems

forgot 1.3 value - that is good enough (and this location is not the most 
difficult, but there are very few places that are worse. So I feel it's good 
enough as if it's fine here - there are very very few other places that are 
still problematic.


On Wed, 28 Apr 2021 at 10:50, Felix Hartmann 
mailto:extremecar...@gmail.com>>>
 wrote:
Thanks for that patch, the improvement is not as big as from the previous patch 
- but there is some.
I analysed it a bit more - and I think there needs to be one more change - 
actually in general and not only for contourlines.

We need different values for the douglas peucker algorithm depending on 
resolution!

Right now we can only set one value, and that is multiplied for each resolution?
Based on the current state I would like to have

resolution
24= 0.0 or maybe actually have it active at 24 as well trying a value of 0.3 or 
so. Where there any problems with autorouting or why is it not possible to use 
it at resolution 24 as well?
23=1.3
22=2.6
21=3.9
20-11=5.4


Especially if we produce a map without resolution 24, then resolution 23 needs 
to have much lower DP value than the subsequent resolutions. Using 1.3 for 
resolution 23 makes the quality IMHO good enough to be used for an contourlines 
only map for GPS devices and skipping resolution 24 altogether. For Desktop use 
resolution 24 may still make sense for contourlines - but even then the 
difference is only in very steep areas.

Attached some screenshots at resolution 24, and at 23 with different DP values 
and one of patch2.

On Tue, 27 Apr 2021 at 23:16, Andrzej Popowski 
mailto:po...@poczta.onet.pl>>>
 wrote:
Hi,

some more experiments, see attached patch. I have tried to optimize
rounding of coordinates for lowest distance to line. This is not good
for polygons, because can creates gaps between adjacent polygons.

--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk>
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


--
Felix Hartman - Openmtbmap.org & VeloMap.org



--
Felix Hartman - Openmtbmap.org & VeloMap.org

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


--
Felix Hartman - Openmtbmap.org & VeloMap.org

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution 23 raster problems

[Felix Hartmann]

Oh I thought it was mainly meant for contourlines. Did not know you intend
it to be used in general. I am not really sure how and where to check for
quality.

On Wed, 28 Apr 2021 at 20:13, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> Hi Felix,
>
> your screen shots only show contour lines but the patch works on all types
> of lines and polygons. So, please also check the results with other maps.
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Mittwoch, 28. April 2021 04:54
> An: Development list for mkgmap; Andrzej Popowski
> Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution
> 23 raster problems
>
> forgot 1.3 value - that is good enough (and this location is not the most
> difficult, but there are very few places that are worse. So I feel it's
> good enough as if it's fine here - there are very very few other places
> that are still problematic.
>
>
> On Wed, 28 Apr 2021 at 10:50, Felix Hartmann  > wrote:
> Thanks for that patch, the improvement is not as big as from the previous
> patch - but there is some.
> I analysed it a bit more - and I think there needs to be one more change -
> actually in general and not only for contourlines.
>
> We need different values for the douglas peucker algorithm depending on
> resolution!
>
> Right now we can only set one value, and that is multiplied for each
> resolution?
> Based on the current state I would like to have
>
> resolution
> 24= 0.0 or maybe actually have it active at 24 as well trying a value of
> 0.3 or so. Where there any problems with autorouting or why is it not
> possible to use it at resolution 24 as well?
> 23=1.3
> 22=2.6
> 21=3.9
> 20-11=5.4
>
>
> Especially if we produce a map without resolution 24, then resolution 23
> needs to have much lower DP value than the subsequent resolutions. Using
> 1.3 for resolution 23 makes the quality IMHO good enough to be used for an
> contourlines only map for GPS devices and skipping resolution 24
> altogether. For Desktop use resolution 24 may still make sense for
> contourlines - but even then the difference is only in very steep areas.
>
> Attached some screenshots at resolution 24, and at 23 with different DP
> values and one of patch2.
>
> On Tue, 27 Apr 2021 at 23:16, Andrzej Popowski  > wrote:
> Hi,
>
> some more experiments, see attached patch. I have tried to optimize
> rounding of coordinates for lowest distance to line. This is not good
> for polygons, because can creates gaps between adjacent polygons.
>
> --
> Best regards,
> Andrzej
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
> --
> Felix Hartman - Openmtbmap.org & VeloMap.org
>
>
>
> --
> Felix Hartman - Openmtbmap.org & VeloMap.org
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>


-- 
Felix Hartman - Openmtbmap.org & VeloMap.org
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Empty rectangles in map

[Gerd Petermann]

Hi Ticker,

okay, so I'll wait for your results. The v1 patch always produces larger files 
with normal maps without visual effects, so it seems to split more often than 
needed (or prohibit merging too often)

Gerd


Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Mittwoch, 28. April 2021 14:26
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Empty rectangles in map

Hi Gerd

Here is patch configured for Method 1, with more clarity about how to
change.

I think the best solution will be a super Method 4. For a 5 x 4
subdivision grid it will reduces the number of polygon cuts from 80
(5*4*4) to 19 (5-1+5*(4-1)).

It shouldn't be too difficult to implement and I'll look at it next
week.

Ticker

On Wed, 2021-04-28 at 09:14 +, Gerd Petermann wrote:
> Hi Ticker,
>
> please create two separate patches for method 1 and 2. It's not
> obvious to me what changes are needed to get method 1.
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Dienstag, 27. April 2021 13:11
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Empty rectangles in map
>
> Hi Gerd and others
>
> The cause for this unrendered area is as follows:
>
> A large multipolygon (larger than the maximum size for a level 1
> subdiv) exists, and is broken into some similar size pieces and some
> smaller pieces to expose inners/holes. The same problem can be caused
> by any polygons having these size properties.
>
> Option --order-by-decreasing-area is not in effect (with this option
> the problem goes away).
>
> At the outermost level, the large pieces are split into the grid of
> subdivs necessary to be within size limits. Small pieces that fit
> within a subdiv are allocated to the correct one. Intermediate pieces
> that extend out of the nominal subdiv bounds, but don't exceed the
> actual addressing limits, are allocated to an existing subdiv based
> on
> their centre. Larger pieces that fit in a subdiv but would cause size
> problems if added to an existing subdiv are given a subdiv of their
> own.
>
> At the next level down, each of the above subdivs will required
> splitting to fit within the addressing limits. The logic that did
> this
> used the subdiv bounds and split this into a grid. Then every element
> in the outer MapArea is processed as above (ie split, safely placed,
> placed with overlap or own subdiv)
>
> The problem is that the splitting algorithm simply goes through the
> child subdiv, clips the polygon to this size and saves the bits that
> are within the area. Polygon parts that are outside the defined outer
> level never get noticed!
>
> There are various possible solutions:
>
> Method 1: use the rigorous polygon splitting into subdivs that -
> -order
> -by-decreasing-area uses for levels above level 0. This is simple to
> implement, safe, mergeShapes might recombine more cut fragments as
> they
> are all together. Disadvantages are that, for a normal map, more
> polygons might be split, leading to larger RGN size (but not for bad
> -map-split.osm.pbf). The overall size is still less that with --order
> -by...
>
> Method 2: When the child subdiv grid is created, use any expanded
> size
> of the parent subdiv. This stops overhanging bits of polygons being
> lost. Again, simple to implement. It results in overlapping subdivs
> at
> lower levels and I don't know this causes other problems, but
> probably
> not; this used to be done and still does for some sizes of polygons
> and
> lines. Some shape-merging won't happen because the joining bits are
> in
> a different subdiv.
>
> Method 3: Allocated oversize polygons to their own subdiv. Again,
> simple to implement, but I see no advantage over Method 2. Even more
> shape-merging might not happen.
>
> Method 4: Detect when an object will have bits missed and semi-cut
> rather than clip them to continue having an oversize part in the
> child
> subdiv. This is more complicated to implement but, if done, could
> replace the clipping code and be more efficient. If a parent subDiv
> is
> divided into 2 children, it already happens like this.
>
> Although I prefer Method 1, I suspect Method 2 is what should be done
> in the short-term and so I've attached a patch that is configured for
> Method 2, but, with a couple of edits to change some flag handling,
> does Method 1.
>
> Ticker
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Empty rectangles in map

[Ticker Berkin]

Hi Gerd

Here is patch configured for Method 1, with more clarity about how to
change.

I think the best solution will be a super Method 4. For a 5 x 4
subdivision grid it will reduces the number of polygon cuts from 80
(5*4*4) to 19 (5-1+5*(4-1)). 

It shouldn't be too difficult to implement and I'll look at it next
week.

Ticker

On Wed, 2021-04-28 at 09:14 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> please create two separate patches for method 1 and 2. It's not
> obvious to me what changes are needed to get method 1.
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Dienstag, 27. April 2021 13:11
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Empty rectangles in map
> 
> Hi Gerd and others
> 
> The cause for this unrendered area is as follows:
> 
> A large multipolygon (larger than the maximum size for a level 1
> subdiv) exists, and is broken into some similar size pieces and some
> smaller pieces to expose inners/holes. The same problem can be caused
> by any polygons having these size properties.
> 
> Option --order-by-decreasing-area is not in effect (with this option
> the problem goes away).
> 
> At the outermost level, the large pieces are split into the grid of
> subdivs necessary to be within size limits. Small pieces that fit
> within a subdiv are allocated to the correct one. Intermediate pieces
> that extend out of the nominal subdiv bounds, but don't exceed the
> actual addressing limits, are allocated to an existing subdiv based
> on
> their centre. Larger pieces that fit in a subdiv but would cause size
> problems if added to an existing subdiv are given a subdiv of their
> own.
> 
> At the next level down, each of the above subdivs will required
> splitting to fit within the addressing limits. The logic that did
> this
> used the subdiv bounds and split this into a grid. Then every element
> in the outer MapArea is processed as above (ie split, safely placed,
> placed with overlap or own subdiv)
> 
> The problem is that the splitting algorithm simply goes through the
> child subdiv, clips the polygon to this size and saves the bits that
> are within the area. Polygon parts that are outside the defined outer
> level never get noticed!
> 
> There are various possible solutions:
> 
> Method 1: use the rigorous polygon splitting into subdivs that -
> -order
> -by-decreasing-area uses for levels above level 0. This is simple to
> implement, safe, mergeShapes might recombine more cut fragments as
> they
> are all together. Disadvantages are that, for a normal map, more
> polygons might be split, leading to larger RGN size (but not for bad
> -map-split.osm.pbf). The overall size is still less that with --order
> -by...
> 
> Method 2: When the child subdiv grid is created, use any expanded
> size
> of the parent subdiv. This stops overhanging bits of polygons being
> lost. Again, simple to implement. It results in overlapping subdivs
> at
> lower levels and I don't know this causes other problems, but
> probably
> not; this used to be done and still does for some sizes of polygons
> and
> lines. Some shape-merging won't happen because the joining bits are
> in
> a different subdiv.
> 
> Method 3: Allocated oversize polygons to their own subdiv. Again,
> simple to implement, but I see no advantage over Method 2. Even more
> shape-merging might not happen.
> 
> Method 4: Detect when an object will have bits missed and semi-cut
> rather than clip them to continue having an oversize part in the
> child
> subdiv. This is more complicated to implement but, if done, could
> replace the clipping code and be more efficient. If a parent subDiv
> is
> divided into 2 children, it already happens like this.
> 
> Although I prefer Method 1, I suspect Method 2 is what should be done
> in the short-term and so I've attached a patch that is configured for
> Method 2, but, with a couple of edits to change some flag handling,
> does Method 1.
> 
> Ticker
> 
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-devIndex: src/uk/me/parabola/mkgmap/build/MapArea.java
===
--- src/uk/me/parabola/mkgmap/build/MapArea.java	(revision 4687)
+++ src/uk/me/parabola/mkgmap/build/MapArea.java	(working copy)
@@ -257,14 +257,16 @@
 	continue;
 }
 int areaIndex = pickArea(mapAreas, e, xbaseHp, ybaseHp, nx, ny, dxHp, dyHp);
-if ((shapeBounds.getHeight() > maxHeight || shapeBounds.getWidth() > maxWidth) &&
-!areas[areaIndex].contains(shapeBounds)) {
+if (areas[areaIndex].contains(shapeBounds)) {
+	mapAreas[areaIndex].addShape(e);
+} else if (shapeBounds.getHeight() <= maxHeight && shapeBounds.getWidth() <= maxWidth) {
+	// this polygon is partially outside the subdivision, but won't exceed the allowable offsets
+	mapAreas[areaIndex].a

Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution 23 raster problems

[Gerd Petermann]

Hi Felix,

your screen shots only show contour lines but the patch works on all types of 
lines and polygons. So, please also check the results with other maps.

Gerd


Von: mkgmap-dev  im Auftrag von Felix 
Hartmann 
Gesendet: Mittwoch, 28. April 2021 04:54
An: Development list for mkgmap; Andrzej Popowski
Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution 23 
raster problems

forgot 1.3 value - that is good enough (and this location is not the most 
difficult, but there are very few places that are worse. So I feel it's good 
enough as if it's fine here - there are very very few other places that are 
still problematic.


On Wed, 28 Apr 2021 at 10:50, Felix Hartmann 
mailto:extremecar...@gmail.com>> wrote:
Thanks for that patch, the improvement is not as big as from the previous patch 
- but there is some.
I analysed it a bit more - and I think there needs to be one more change - 
actually in general and not only for contourlines.

We need different values for the douglas peucker algorithm depending on 
resolution!

Right now we can only set one value, and that is multiplied for each resolution?
Based on the current state I would like to have

resolution
24= 0.0 or maybe actually have it active at 24 as well trying a value of 0.3 or 
so. Where there any problems with autorouting or why is it not possible to use 
it at resolution 24 as well?
23=1.3
22=2.6
21=3.9
20-11=5.4


Especially if we produce a map without resolution 24, then resolution 23 needs 
to have much lower DP value than the subsequent resolutions. Using 1.3 for 
resolution 23 makes the quality IMHO good enough to be used for an contourlines 
only map for GPS devices and skipping resolution 24 altogether. For Desktop use 
resolution 24 may still make sense for contourlines - but even then the 
difference is only in very steep areas.

Attached some screenshots at resolution 24, and at 23 with different DP values 
and one of patch2.

On Tue, 27 Apr 2021 at 23:16, Andrzej Popowski 
mailto:po...@poczta.onet.pl>> wrote:
Hi,

some more experiments, see attached patch. I have tried to optimize
rounding of coordinates for lowest distance to line. This is not good
for polygons, because can creates gaps between adjacent polygons.

--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


--
Felix Hartman - Openmtbmap.org & VeloMap.org



--
Felix Hartman - Openmtbmap.org & VeloMap.org

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Empty rectangles in map

[Gerd Petermann]

Hi Ticker,

please create two separate patches for method 1 and 2. It's not obvious to me 
what changes are needed to get method 1.

Gerd


Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Dienstag, 27. April 2021 13:11
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Empty rectangles in map

Hi Gerd and others

The cause for this unrendered area is as follows:

A large multipolygon (larger than the maximum size for a level 1
subdiv) exists, and is broken into some similar size pieces and some
smaller pieces to expose inners/holes. The same problem can be caused
by any polygons having these size properties.

Option --order-by-decreasing-area is not in effect (with this option
the problem goes away).

At the outermost level, the large pieces are split into the grid of
subdivs necessary to be within size limits. Small pieces that fit
within a subdiv are allocated to the correct one. Intermediate pieces
that extend out of the nominal subdiv bounds, but don't exceed the
actual addressing limits, are allocated to an existing subdiv based on
their centre. Larger pieces that fit in a subdiv but would cause size
problems if added to an existing subdiv are given a subdiv of their
own.

At the next level down, each of the above subdivs will required
splitting to fit within the addressing limits. The logic that did this
used the subdiv bounds and split this into a grid. Then every element
in the outer MapArea is processed as above (ie split, safely placed,
placed with overlap or own subdiv)

The problem is that the splitting algorithm simply goes through the
child subdiv, clips the polygon to this size and saves the bits that
are within the area. Polygon parts that are outside the defined outer
level never get noticed!

There are various possible solutions:

Method 1: use the rigorous polygon splitting into subdivs that --order
-by-decreasing-area uses for levels above level 0. This is simple to
implement, safe, mergeShapes might recombine more cut fragments as they
are all together. Disadvantages are that, for a normal map, more
polygons might be split, leading to larger RGN size (but not for bad
-map-split.osm.pbf). The overall size is still less that with --order
-by...

Method 2: When the child subdiv grid is created, use any expanded size
of the parent subdiv. This stops overhanging bits of polygons being
lost. Again, simple to implement. It results in overlapping subdivs at
lower levels and I don't know this causes other problems, but probably
not; this used to be done and still does for some sizes of polygons and
lines. Some shape-merging won't happen because the joining bits are in
a different subdiv.

Method 3: Allocated oversize polygons to their own subdiv. Again,
simple to implement, but I see no advantage over Method 2. Even more
shape-merging might not happen.

Method 4: Detect when an object will have bits missed and semi-cut
rather than clip them to continue having an oversize part in the child
subdiv. This is more complicated to implement but, if done, could
replace the clipping code and be more efficient. If a parent subDiv is
divided into 2 children, it already happens like this.

Although I prefer Method 1, I suspect Method 2 is what should be done
in the short-term and so I've attached a patch that is configured for
Method 2, but, with a couple of edits to change some flag handling,
does Method 1.

Ticker

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution 23 raster problems

[Gerd Petermann]

Hi Andrzej,

thanks, looks like a good approach. I have to run some tests to understand the 
effects.

Gerd


Von: mkgmap-dev  im Auftrag von Andrzej 
Popowski 
Gesendet: Dienstag, 27. April 2021 17:16
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution 23 
raster problems

Hi,

some more experiments, see attached patch. I have tried to optimize
rounding of coordinates for lowest distance to line. This is not good
for polygons, because can creates gaps between adjacent polygons.

--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev