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=3702
Thanks for writing the patch Ticker Quite an impact on file size here: 3.872.456.704Byte to 4.431.544.320Byte in a Central European region with the default style So did I read correctly that the only benefit on a device with typ that has draworder is * Small Polygons on Polygons of the same type (like two buildings) are drawn on top now * The point simplification algorithm treats previously merged areas (like two buildings with common nodes) as separate and shapes might be more correct So probably makes sense to deactivate it on devices with typ draworder? Best Jakob Am 11.11.2016 um 17:11 schrieb svn commit:
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=3702 _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
This is a much higher increase in size than I was seeing; 14% rather than around 3%. This might be due to lots of buildings being merged; I suppress buildings in my style. If you are happy with TYP/_draworder then use that. I didn't like the idea of it at all. Shape merging could be implemented in combination --order-by-decreasing -area, but it would have to be done early in the process, probably before style processing, so the area_size that governs the scheme is well defined. It would have to be under the control of another option because it can effect the final look of the map. Ticker On Sat, 2016-11-12 at 18:40 +0100, Jakob Mühldorfer wrote:
Thanks for writing the patch Ticker Quite an impact on file size here: 3.872.456.704Byte to 4.431.544.320Byte in a Central European region with the default style So did I read correctly that the only benefit on a device with typ that has draworder is Small Polygons on Polygons of the same type (like two buildings) are drawn on top now The point simplification algorithm treats previously merged areas (like two buildings with common nodes) as separate and shapes might be more correct So probably makes sense to deactivate it on devices with typ draworder? Best Jakob Am 11.11.2016 um 17:11 schrieb svn commit:
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=370 2 _______________________________________________ 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
Hi Jakob, Jakob Mühldorfer-2 wrote
* The point simplification algorithm treats previously merged areas (like two buildings with common nodes) as separate and shapes might be more correct
Not really. The effect is that the ShapeMergeFilter is more or less disabled. The screenshots in this old post showed the effects on buildings, but they were removed since: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2014q1/019737.html @Steve: Do they still exist? Gerd -- View this message in context: http://gis.19327.n8.nabble.com/Commit-r3702-sortAreas-v5-patch-Add-option-or... Sent from the Mkgmap Development mailing list archive at Nabble.com.
On 13/11/16 07:16, Gerd Petermann wrote:
Not really. The effect is that the ShapeMergeFilter is more or less disabled. The screenshots in this old post showed the effects on buildings, but they were removed since: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2014q1/019737.html
@Steve: Do they still exist?
I'm afraid that those images have really gone by now. ..Steve
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@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&rev=3702 _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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, rheinskipper1000@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-svn@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&rev=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
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, rheinskipper1000@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-svn@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&rev=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
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&rev=3702 _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n8.nabble.com/Commit-r3702-sortAreas-v5-patch-Add-option-or... Sent from the Mkgmap Development mailing list archive at Nabble.com.
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&rev=3702 _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n8.nabble.com/Commit-r3702-sortAreas-v5-patch-Add-option-or... 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
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@gmx.de> wrote:
Yes, I would appreciate a draw order command for the style language very much.
*Von: *Gerd Petermann <gpetermann_muenchen@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&rev=3702
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@.org
--
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
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@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, 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@.org
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- 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
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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@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@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, 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@.org
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- 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
_______________________________________________ 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
Yes, mkgmap:drawLevel is our Christmas wish this year! Von: Alexandre Loss Gesendet: Sonntag, 13. November 2016 12:49 An: Development list for mkgmap Betreff: 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-mkgmap@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@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, 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@.org
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- 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
_______________________________________________ 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
participants (9)
-
Alexandre Loss -
Felix Hartmann -
Gerd Petermann -
Jakob Mühldorfer -
Markus Bärlocher -
rheinskipper1000＠gmx.de -
Steve Ratcliffe -
svn commit -
Ticker Berkin