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-boun...@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkg...@jagit.co.uk> Gesendet: Freitag, 23. Dezember 2016 11:05:23 An: mkgmap-dev@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-boun...@lists.mkgmap.org.uk> im Auftrag > von Ticker Berkin <rwb-mkg...@jagit.co.uk> > Gesendet: Mittwoch, 21. Dezember 2016 13:23:17 > An: mkgmap-dev@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@lists.mkgmap.org.uk > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
filter-early-v1.patch
Description: filter-early-v1.patch
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
