[mkgmap-dev] Commit r3702: sortAreas_v5.patch: Addoption--order-by-decreasing-area

Sun Nov 13 11:40:07 GMT 2016

I should have thought harder before replying last night. I imagine
these river-bank polygons are a mixture of sizes, sometimes divided up
at arbitary lines, hence they might be bigger or smaller that the
fairway and this explains result you get.

It's related to the way I handled sea where I give all sea polygons the
same, large, areaSize, overwriting the actual size of the arbitrary
polygons that make up the sea - this forces them to be output first and
other features drawn on top. 

Keeping with the --order-by, in this case it would be better to force
fairway to be consider small, hence overwriting the river. At the
moment there is no way of doing this, but I was thinking about adding
something like mkgmap:drawLevel to be used like: 

natural=sea
   {add mkgmap:skipSizeFilter=true; set mkgmap:drawLevel=9}
   [0x32 resolution 10]
seamark:type=fairway
   {name 'fairway'; set mkgmap:drawLevel=0}
   [0x10307 level 2]

where drawLevel takes a range of values from 0, being smaller than any
natural area to, say, 10 which is much larger than any natural area.
This would override the area value calculated from the polygon. Hence
allowing control of the output ordering.

In answer to some points earlier in the thread:

--order-by should work correctly on large area that cover multiple sub
-divisions and even on composite maps provided the splitter has
preserved the full polygons in all maps that it has been split into -
which I think it does.

I did intend the areaSize to be the size of each outer-polygon, without
subtracting the size of any inner polygons.

Ticker

On Sun, 2016-11-13 at 10:21 +0100, Felix Hartmann wrote:
> I still think the best solution would be cutting out smaller polygons
> from larger - however we would need to define two categories in the
> polygons style-file:
> 1. polygons that are used transparently in .typ (and will be given
> high draworder anyhow) - these can be skipped. Also usually very
> small polygons that you give high draworder (e.g. buildings) don't
> need to be cut out. It's easier if they simply appear on top.
> 2. Other polygons which usually cover large areas - here overlapping
> smaller polygons should be cut out.
> 
> Looking at area size of polygons of all polygons that fall under 2.
> will be needed of course. But because of 1. we will save time as any
> polygon that is flagged as belonging to 1. category can be skipped.
> Main problems are anyhow forest, water, island and similar where
> people are too lazy to use multipolygons. 
> 
> Even though wrong tagging - looking at the layer tag if present to
> decide which polygon should be cut out should still be done.
> 
> 
> On 13 November 2016 at 09:47, <rheinskipper1000 at gmx.de> wrote:
> > Yes, I would appreciate a draw order command for the style language
> > very much.
> >  
> >  
> >  
> > Von: Gerd Petermann
> > Gesendet: Sonntag, 13. November 2016 08:22
> > An: mkgmap-dev at lists.mkgmap.org.uk
> > Betreff: Re: [mkgmap-dev] Commit r3702: sortAreas_v5.patch:
> > Addoption--order-by-decreasing-area
> >  
> > Hi,
> >  
> > I am not sure regarding the sizes of the area. At least one of the
> > riverbank
> > polygons is a
> > multipolygon with two outer rings. The size calculation treats each
> > outer
> > ring separately, without
> > subtracting the area of inner rings.
> > @Ticker: Is that intended?
> >  
> > Besides that I think that the examples show that one needs both a
> > draw order
> > for types and size ordering to get reasonable results.
> >  
> > Gerd
> >  
> >  
> > rheinskipper1000 wrote
> > > I eagerly awaited the order-by-decreasing-area option.
> > >
> > > Results are a bit different than I expected at the moment:
> > >
> > > My style contains:
> > >
> > > waterway=riverbank [0x10302 resolution 20]
> > > seamark:type=fairway {name 'fairway'}  [0x10307 level 2]
> > >
> > > Unfortunately the smaller (white) fairway polygons are still
> > partly
> > > covered by (blue) riverbank polygons:
> > > https://mega.nz/#!NN8UWDCK!LeR_h1cJeBVDGMxFeUf48l_qARfVdKXTMzRoHj
> > y_rEw
> > > https://mega.nz/#!0B9AgZQJ!AZcQ9zHktIQ0D9Uq_nb_gRGG0eDGxCQaT0XuQJ
> > aebWc
> > >
> > >
> > >
> > > Von: svn commit
> > > Gesendet: Freitag, 11. November 2016 17:11
> > > An:
> >  
> > > mkgmap-svn at .org
> >  
> > > ;
> >  
> > > mkgmap-dev at .org
> >  
> > > Betreff: [mkgmap-dev] Commit r3702: sortAreas_v5.patch: Add
> > > option--order-by-decreasing-area
> > >
> > > Version mkgmap-r3702 was committed by gerd on Fri, 11 Nov 2016
> > >
> > > sortAreas_v5.patch: Add option --order-by-decreasing-area
> > >
> > > Patch by Ticker Berkin, slightly modifed
> > >
> > >
> > > http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3
> > 702
> > > _______________________________________________
> > > mkgmap-dev mailing list
> >  
> > > mkgmap-dev at .org
> >  
> > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> > >
> > >
> > > _______________________________________________
> > > mkgmap-dev mailing list
> >  
> > > mkgmap-dev at .org
> >  
> > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> >  
> >  
> >  
> >  
> >  
> > --
> > View this message in context: http://gis.19327.n8.nabble.com/Commit
> > -r3702-sortAreas-v5-patch-Add-option-order-by-decreasing-area
> > -tp5885761p5885809.html
> > Sent from the Mkgmap Development mailing list archive at
> > Nabble.com.
> > _______________________________________________
> > 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