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

Sun Nov 13 11:49:07 GMT 2016

Hi Ticker,

I think that create mkgmap:drawLevel is a great idea!
This will give developers more autonomy to decide the order of the polygons
on their maps.

Alexandre

2016-11-13 9:40 GMT-02:00 Ticker Berkin <rwb-mkgmap at jagit.co.uk>:

> 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
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20161113/acea45c3/attachment-0001.html>