Re: [mkgmap-dev] Commit r3702: sortAreas_v5.patch: Addoption--order-by-decreasing-area
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-mkg...@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, <rheinskipper1...@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@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
> > >
Re: [mkgmap-dev] Commit r3702: sortAreas_v5.patch: Addoption--order-by-decreasing-area
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, <rheinskipper1...@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@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@.org
> >
> > > ;
> >
> > > mkgmap-dev@.org
> >
> > > Betreff: [mkgmap-dev] Commit r3702: sortAreas_v5.patch: Add
> > > option--order-by-decreasing-area
> > >
> > > Version mkgmap-r3702 was committed by gerd on Fri
Re: [mkgmap-dev] Commit r3702: sortAreas_v5.patch: Addoption--order-by-decreasing-area
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, <rheinskipper1...@gmx.de> wrote:
> Yes, I would appreciate a draw order command for the style language very
> much.
>
>
>
>
>
>
>
> *Von: *Gerd Petermann <gpetermann_muenc...@hotmail.com>
> *Gesendet: *Sonntag, 13. November 2016 08:22
> *An: *mkgmap-dev@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_qARfVdKXTMzRoHjy_rEw
>
> > https://mega.nz/#!0B9AgZQJ!AZcQ9zHktIQ0D9Uq_nb_gRGG0eDGxCQaT0XuQJaebWc
>
> >
>
> >
>
> >
>
> > Von: svn commit
>
> > Gesendet: Freitag, 11. November 2016 17:11
>
> > An:
>
>
>
> > mkgmap-svn@.org
>
>
>
> > ;
>
>
>
> > mkgmap-dev@.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=3702
>
> > ___
>
> > mkgmap-dev mailing list
>
>
>
> > mkgmap-dev@.org
>
>
>
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
> >
>
> >
>
> > ___
>
> > mkgmap-dev mailing list
>
>
>
> > mkgmap-dev@.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@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
>
--
Felix Hartman - Openmtbmap.org & VeloMap.org
Schusterbergweg 32/8
6020 Innsbruck
Austria - Österreich
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit r3702: sortAreas_v5.patch: Addoption--order-by-decreasing-area
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@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_qARfVdKXTMzRoHjy_rEw
> https://mega.nz/#!0B9AgZQJ!AZcQ9zHktIQ0D9Uq_nb_gRGG0eDGxCQaT0XuQJaebWc
>
>
>
> Von: svn commit
> Gesendet: Freitag, 11. November 2016 17:11
> An:
> mkgmap-svn@.org
> ;
> mkgmap-dev@.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=3702
> ___
> mkgmap-dev mailing list
> mkgmap-dev@.org
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@.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@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
Re: [mkgmap-dev] Commit r3702: sortAreas_v5.patch: Addoption--order-by-decreasing-area
I know there is a built in draw order between some types. But I am sure that
those extended types I use for depth areas have the same draw order.
A few years ago I did some testing and learned that I can influence which
polygon is drawn on top by sorting the input. But this method only worked for
types with the same built in draw order and it only worked for very small maps
that fit in a single Garmin sub file.
Obviously trying to control draw order with the new order-by-decreasing-area
option can only be successful among types with same built in draw order. But I
expected it will function on maps covering multiple Garmin sub files.
Unfortunately it does not.
Von: Ticker Berkin
Gesendet: Sonntag, 13. November 2016 00:12
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Commit r3702: sortAreas_v5.patch:
Addoption--order-by-decreasing-area
On my device I have to override the inbuilt _draworder, which gives a
higher priority to Ocean/Sea 0x32, to stop the sea areas hiding
everything - I just give polygon types 0x01 to 0x55 level 1 except for
background 0x4b which I give level 0. I don't have any extended types.
Is this on a device that doesn't support TYP/_draworder? Maybe it has
inbuild _draworder that can't be overridden or there is some subtlety
about what is shown.
Ticker Berkin
On Sat, 2016-11-12 at 20:48 +0100, rheinskipper1...@gmx.de 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_qARfVdKXTMzRoHjy_rE
> w
> https://mega.nz/#!0B9AgZQJ!AZcQ9zHktIQ0D9Uq_nb_gRGG0eDGxCQaT0XuQJaebW
> c
>
>
>
> Von: svn commit
> Gesendet: Freitag, 11. November 2016 17:11
> An: mkgmap-...@lists.mkgmap.org.uk; mkgmap-dev@lists.mkgmap.org.uk
> 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=3702
> ___
> 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
