[mkgmap-dev] Minimum resolution in polygons style

Fri Dec 23 10:35:53 GMT 2016

Hi Ticker,

yes, I also came to the conclusion that the current implementation is not that bad.

I played with different kinds of implementations and found quite confusing results for most styles so far.
For some input files the map size increases, for others it decreases. Runtime also changes
in both directions. I think the reason is that we get more or less sub divisions and the
current implementation of ShapeMergeFilter performs not so well when a sub division contains
many shapes.
Of course, for a map created with Arndts style both run time and map size go down a lot.
BTW: That style also seems to be a good stress test for the --order-by-decreasing-area option.

Attached is a patch with my simple approach. I am now trying to use a quad tree in ShapeMergeFilter
so that it can handle larger lists.

Gerd
________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
Gesendet: Freitag, 23. Dezember 2016 11:05:23
An: mkgmap-dev at lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Minimum resolution in polygons style

Hi Gerd

Although the simplification filters will change the size of polygons a
bit, depending on the resolution, this can't be significant within the
distortion error at that resolution. I think it would be perfectly
justifiable use the highPrecisionArea as a basis for increasing the
shape minResolution so that it is more than a point at that resolution
and obeys --polygon-size-limits.

Is this a lot more work? In StyledConverter.java:addShape we have the
polgon area just before it might get clobbered by mkgmap:drawLevel. If
skipSizeFilter is set it should be left alone, otherwise
just reduce minResolution here.

The size filter then seems to be redundant. However, after all the
MapBuilder filters have been run, something should chuck single point
areas and lines.

When --order-by-decreasing-area, there might be very small polygons
generated during the split process. I feel that they should be not be
deleted at this point in case the ShapeMergeFilter joins them to
another shape. If this doesn't happen they will get chucked later by
the output filter chain.

Best wishes
Ticker

On Thu, 2016-12-22 at 10:11 +0000, Gerd Petermann wrote:
> Hi Ticker,
>
> using --polygon-size-limits option sounds reasonable, but requires a
> lot more changes.
>
> While thinking about it I wondered if the current implementation of
> the size filter makes any sense.
> This is what happens now:
> - for each element (point,line.shape) the style sets the values for
> minRes and maxRes and adds it to a list
> - a lot of calculations are done to find out the needed sub divisions
> (MapSplitter). For lines and shapes the
> calculation are based  on the (worst case) assumption that the shape
> will not be simplified or discarded by
> any filter.
>  -  finally for resolutions < 24 we use the filters (in this order):
>  + RoundCoordsFilter makes sure that all points are on the raster for
> the given resolution. This may enlarge a line or polygon
> if its points are located far from any raster points (one point may
> be moved to next left raster point, another to the next right.
> Of course this may also shrink the object if points are rounded
> towards the center of the object.
>  + SizeFilter checks this -- possibly enlarged -- object against the
> minimum value from --polygon-size-limits or --min-size-polygon
> option.
>
> I think this is actually wrong. SizeFilter should use something like
> size = Math.min(sizeAtRes24,sizeAtCurrentRes);
> if (size < minSizeForRes)
>  drop the element
>
> If this is correct we can save a lot of calculations if we check the
> sizeAtRes24 much earlier.
>
> Gerd
>
>
>
>
>
>
>
>
>
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> Gesendet: Mittwoch, 21. Dezember 2016 13:23:17
> An: mkgmap-dev at lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] Minimum resolution in polygons style
>
> Seems like a good idea - It should use the --polygon-size-limits
> option
> in an inverted sort of way.
>
> Ticker
>
> On Wed, 2016-12-21 at 07:48 +0000, Gerd Petermann wrote:
> > Hi all,
> >
> > while debugging the problem reported by Arndt Röhrig
> > http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2016q4/025471.html
> >
> > I noticed that his style adds all polygons with "min resolution 10"
> > like this:
> > landuse=basin [0x53 resolution 10]
> >
> > Up to now I thought this is just causing more CPU load :
> > The polygon is processed for each (low) resolution  and after many
> > calculations it is typically "thrown away" because it
> > is reduced to a single point in the
> >
> > I think we can easily change mkgmap to calculate a proper "min res"
> > value
> > for shapes depending on the actual size at resolution 24.
> > Probably that would also be useful for lines.
> >
> > Any thoughts?
> >
> > 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
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: filter-early-v1.patch
Type: application/x-download
Size: 1933 bytes
Desc: filter-early-v1.patch
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20161223/949d55eb/attachment-0001.bin>