shape merger in high-prec-coord branch
Hi all, today I've finished the work on the shape merger. The algo works quite simple: 1) if two similar shapes (same type, name, min+max resolution) share one or more identical points, both are combined. In the combined shape, the longest sequence of identical points is removed. This reduces the number of points and the number of shapes. On the other hand, it makes shapes larger, so that it is more likely that many smaller landuse=forest shapes are combined and appear at lower resolution levels. 2) After merging, all points on (almost) straight lines are removed. This reduces again the img size and has a very nice side effect: Connected buildings look much better. Two screen shots show what I mean: Area in OSM: http://www.openstreetmap.org/node/21030850#map=17/53.06636/8.79033 Screenshots: http://files.mkgmap.org.uk/download/170/r2961.png http://files.mkgmap.org.uk/download/171/r2966_mergeshapes.png I see no big change in the runtime , I guess the additional cpu time that is needed for the merged is gained back because less data is written, the img size is 2-3% smaller compared to trunk. Any feedback is welcome. Gerd
Hi Gerd
Connected buildings look much better. Two screen shots show what I mean: Area in OSM: http://www.openstreetmap.org/node/21030850#map=17/53.06636/8.79033 Screenshots: |http://files.mkgmap.org.uk/download/170/r2961.png| |http://files.mkgmap.org.uk/download/171/r2966_mergeshapes.png|
Yes indeed, the merge shapes screen shot looks very nice. Cheers, ..Steve
Hi Gerd, that sounds great!! The description of the algorithm sounds quite easy. I like it! Maybe it could also be used to improve cutting in the Multipolygon class? How do you avoid that two shapes connected with two edges and that surround a hole are merged? I think many shapes cut by the MultipolygonRelation have this characteristic. WanMil
Hi all,
today I've finished the work on the shape merger. The algo works quite simple: 1) if two similar shapes (same type, name, min+max resolution) share one or more identical points, both are combined. In the combined shape, the longest sequence of identical points is removed. This reduces the number of points and the number of shapes. On the other hand, it makes shapes larger, so that it is more likely that many smaller landuse=forest shapes are combined and appear at lower resolution levels.
2) After merging, all points on (almost) straight lines are removed. This reduces again the img size and has a very nice side effect: Connected buildings look much better. Two screen shots show what I mean: Area in OSM: http://www.openstreetmap.org/node/21030850#map=17/53.06636/8.79033 Screenshots: |http://files.mkgmap.org.uk/download/170/r2961.png| |http://files.mkgmap.org.uk/download/171/r2966_mergeshapes.png|
I see no big change in the runtime , I guess the additional cpu time that is needed for the merged is gained back because less data is written, the img size is 2-3% smaller compared to trunk.
Any feedback is welcome.
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi WanMil, WanMil wrote
The description of the algorithm sounds quite easy. I like it! Maybe it could also be used to improve cutting in the Multipolygon class? How do you avoid that two shapes connected with two edges and that surround a hole are merged? I think many shapes cut by the MultipolygonRelation have this characteristic.
the trick is that the merge is done for one sub division. That means that I just have to make sure that the number of points < 250 so that no further routine splits the shape. It might be possible to move the merge higher up in the chain, for example after the clipping. In that case I have to make sure that I don't create shapes that PolygonSubdivSizeSplitterFilter would split. I know that this is a bit risky, but maybe I can get rid of all Java2DConverter methods that convert to double and back to int. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/shape-merger-in-high-prec-coord-branch-tp5793... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd, I tested mkgmap-high-prec-coord-r2966 on a few tiles but 3 tiles from 5 were not processed. This is the errorlog: java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 at java.util.ArrayList.rangeCheck(Unknown Source) at java.util.ArrayList.get(Unknown Source) at uk.me.parabola.mkgmap.osmstyle.WrongAngleFixer.fixAnglesInShape(WrongAngleFixer.java:1260) at uk.me.parabola.mkgmap.filters.ShapeMergeFilter.merge(ShapeMergeFilter.java:117) at uk.me.parabola.mkgmap.build.MapBuilder.processShapes(MapBuilder.java:1077) at uk.me.parabola.mkgmap.build.MapBuilder.makeSubdivision(MapBuilder.java:742) at uk.me.parabola.mkgmap.build.MapBuilder.makeMapAreas(MapBuilder.java:676) at uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:218) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:120) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:82) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:220) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:216) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) SEVERE (MapBuilder): splitter\10010044.o5m: Non-routable way with routable type 0x08 starting at http://www.openstreetmap.org/?mlat=51.801064&mlon=4.786823&zoom=17 is used for a routable map. This leads to routing errors. Try --check-styles to check the style. java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 at java.util.ArrayList.rangeCheck(Unknown Source) at java.util.ArrayList.get(Unknown Source) at uk.me.parabola.mkgmap.osmstyle.WrongAngleFixer.fixAnglesInShape(WrongAngleFixer.java:1260) at uk.me.parabola.mkgmap.filters.ShapeMergeFilter.merge(ShapeMergeFilter.java:117) at uk.me.parabola.mkgmap.build.MapBuilder.processShapes(MapBuilder.java:1077) at uk.me.parabola.mkgmap.build.MapBuilder.makeSubdivision(MapBuilder.java:742) at uk.me.parabola.mkgmap.build.MapBuilder.makeMapAreas(MapBuilder.java:676) at uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:218) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:120) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:82) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:220) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:216) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) SEVERE (MapBuilder): splitter\10010045.o5m: Non-routable way with routable type 0x08 starting at http://www.openstreetmap.org/?mlat=51.966065&mlon=4.925107&zoom=17 is used for a routable map. This leads to routing errors. Try --check-styles to check the style.
Hi Minko, -- View this message in context: http://gis.19327.n5.nabble.com/shape-merger-in-high-prec-coord-branch-tp5793... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Minko, I think this can happen when two overlapping shapes are merged. In this case the result can be an empty list of points. I'll add a check for this tomorrow. Gerd ligfietser wrote
Hi Gerd, I tested mkgmap-high-prec-coord-r2966 on a few tiles but 3 tiles from 5 were not processed. This is the errorlog:
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 at java.util.ArrayList.rangeCheck(Unknown Source) at java.util.ArrayList.get(Unknown Source) at uk.me.parabola.mkgmap.osmstyle.WrongAngleFixer.fixAnglesInShape(WrongAngleFixer.java:1260) at uk.me.parabola.mkgmap.filters.ShapeMergeFilter.merge(ShapeMergeFilter.java:117) at uk.me.parabola.mkgmap.build.MapBuilder.processShapes(MapBuilder.java:1077) at uk.me.parabola.mkgmap.build.MapBuilder.makeSubdivision(MapBuilder.java:742) at uk.me.parabola.mkgmap.build.MapBuilder.makeMapAreas(MapBuilder.java:676) at uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:218) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:120) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:82) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:220) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:216) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) SEVERE (MapBuilder): splitter\10010044.o5m: Non-routable way with routable type 0x08 starting at http://www.openstreetmap.org/?mlat=51.801064&mlon=4.786823&zoom=17 is used for a routable map. This leads to routing errors. Try --check-styles to check the style. java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 at java.util.ArrayList.rangeCheck(Unknown Source) at java.util.ArrayList.get(Unknown Source) at uk.me.parabola.mkgmap.osmstyle.WrongAngleFixer.fixAnglesInShape(WrongAngleFixer.java:1260) at uk.me.parabola.mkgmap.filters.ShapeMergeFilter.merge(ShapeMergeFilter.java:117) at uk.me.parabola.mkgmap.build.MapBuilder.processShapes(MapBuilder.java:1077) at uk.me.parabola.mkgmap.build.MapBuilder.makeSubdivision(MapBuilder.java:742) at uk.me.parabola.mkgmap.build.MapBuilder.makeMapAreas(MapBuilder.java:676) at uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:218) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:120) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:82) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:220) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:216) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) SEVERE (MapBuilder): splitter\10010045.o5m: Non-routable way with routable type 0x08 starting at http://www.openstreetmap.org/?mlat=51.966065&mlon=4.925107&zoom=17 is used for a routable map. This leads to routing errors. Try --check-styles to check the style. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/shape-merger-in-high-prec-coord-branch-tp5793... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Minko, I fixed a stupid bug with r2699, please try again. It was not related to your style or options. Quite funny that my test data did not show this obvious bug :-( Gerd
Date: Tue, 14 Jan 2014 22:23:09 +0100 From: ligfietser@online.nl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] shape merger in high-prec-coord branch
Hi Gerd, I tested mkgmap-high-prec-coord-r2966 on a few tiles but 3 tiles from 5 were not processed. This is the errorlog:
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 at java.util.ArrayList.rangeCheck(Unknown Source) at java.util.ArrayList.get(Unknown Source) at uk.me.parabola.mkgmap.osmstyle.WrongAngleFixer.fixAnglesInShape(WrongAngleFixer.java:1260) at uk.me.parabola.mkgmap.filters.ShapeMergeFilter.merge(ShapeMergeFilter.java:117) at uk.me.parabola.mkgmap.build.MapBuilder.processShapes(MapBuilder.java:1077) at uk.me.parabola.mkgmap.build.MapBuilder.makeSubdivision(MapBuilder.java:742) at uk.me.parabola.mkgmap.build.MapBuilder.makeMapAreas(MapBuilder.java:676) at uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:218) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:120) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:82) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:220) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:216) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) SEVERE (MapBuilder): splitter\10010044.o5m: Non-routable way with routable type 0x08 starting at http://www.openstreetmap.org/?mlat=51.801064&mlon=4.786823&zoom=17 is used for a routable map. This leads to routing errors. Try --check-styles to check the style. java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 at java.util.ArrayList.rangeCheck(Unknown Source) at java.util.ArrayList.get(Unknown Source) at uk.me.parabola.mkgmap.osmstyle.WrongAngleFixer.fixAnglesInShape(WrongAngleFixer.java:1260) at uk.me.parabola.mkgmap.filters.ShapeMergeFilter.merge(ShapeMergeFilter.java:117) at uk.me.parabola.mkgmap.build.MapBuilder.processShapes(MapBuilder.java:1077) at uk.me.parabola.mkgmap.build.MapBuilder.makeSubdivision(MapBuilder.java:742) at uk.me.parabola.mkgmap.build.MapBuilder.makeMapAreas(MapBuilder.java:676) at uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:218) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:120) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:82) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:220) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:216) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) SEVERE (MapBuilder): splitter\10010045.o5m: Non-routable way with routable type 0x08 starting at http://www.openstreetmap.org/?mlat=51.966065&mlon=4.925107&zoom=17 is used for a routable map. This leads to routing errors. Try --check-styles to check the style. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Well done Gerd, r2969 works fine. See the differences between 2969 vs 2946 here: https://www.dropbox.com/sc/l68prcoxs4pnqb8/2Eo8xEfliX Differences are small but noticeable, files are 5% smaller.
I fixed a stupid bug with r2699, please try again. It was not related to your style or options. Quite funny that my test data did not show this obvious bug :-(
Gerd
Maybe test the Netherlands, because of the many imports there are plenty of complex mp relations.
Hi Minko, that's good news :-) yes, I used Netherlands to reproduce the bug. It was related to extremely small shapes which seem to appear more often in this area, on the other hand they are also caused by clipping to the tile boundaries, so it was bad luck that my test data did not contain the bug. Your screenshot shows a roundabout. I did not change that part of the code for a while, but the branch also contains the routines to optimize wrong angles in roads. I think the 5% reduction is also related to the fact that the branch removes many obsolete points from roads, and your style creates more of them compared to default. Gerd
Date: Wed, 15 Jan 2014 15:07:58 +0100 From: ligfietser@online.nl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] shape merger in high-prec-coord branch
Well done Gerd, r2969 works fine. See the differences between 2969 vs 2946 here: https://www.dropbox.com/sc/l68prcoxs4pnqb8/2Eo8xEfliX
Differences are small but noticeable, files are 5% smaller.
I fixed a stupid bug with r2699, please try again. It was not related to your style or options. Quite funny that my test data did not show this obvious bug :-(
Gerd
Maybe test the Netherlands, because of the many imports there are plenty of complex mp relations. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi WanMil, forgot to mention that my algo simply doesn't merge when the result is not plausible. You can see that in the unit tests. The idea: If the area of the merged polygon is not equaul to the sum of the areas of the original polygons there was an overlap and I don't know how to handle that. One open problem is the presumption that OSM data doesn't contains self intersecting polygons, because for those the routine that calculates the area is not working. Assume this simple case: A B C D A polygon CABDC will work fine, the self intersecting polygon ABCDA will not. I plan to add a test for that and split those polygons in the beginning. Wikipedia says that the Bentley-Ottmann algo should work for this: http://en.wikipedia.org/wiki/Bentley%E2%80%93Ottmann_algorithm I think that might also help in the MultiPolygonRelation code, but I found no copyright free java implementation until now. Gerd
Date: Tue, 14 Jan 2014 13:17:13 -0800 From: gpetermann_muenchen@hotmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] shape merger in high-prec-coord branch
Hi WanMil,
WanMil wrote
The description of the algorithm sounds quite easy. I like it! Maybe it could also be used to improve cutting in the Multipolygon class? How do you avoid that two shapes connected with two edges and that surround a hole are merged? I think many shapes cut by the MultipolygonRelation have this characteristic.
the trick is that the merge is done for one sub division. That means that I just have to make sure that the number of points < 250 so that no further routine splits the shape.
It might be possible to move the merge higher up in the chain, for example after the clipping. In that case I have to make sure that I don't create shapes that PolygonSubdivSizeSplitterFilter would split.
I know that this is a bit risky, but maybe I can get rid of all Java2DConverter methods that convert to double and back to int.
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/shape-merger-in-high-prec-coord-branch-tp5793... 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
Hi WanMil,
WanMil wrote
The description of the algorithm sounds quite easy. I like it! Maybe it could also be used to improve cutting in the Multipolygon class? How do you avoid that two shapes connected with two edges and that surround a hole are merged? I think many shapes cut by the MultipolygonRelation have this characteristic.
the trick is that the merge is done for one sub division. That means that I just have to make sure that the number of points < 250 so that no further routine splits the shape.
Ah, that's the trick! Well done!
It might be possible to move the merge higher up in the chain, for example after the clipping. In that case I have to make sure that I don't create shapes that PolygonSubdivSizeSplitterFilter would split.
I know that this is a bit risky, but maybe I can get rid of all Java2DConverter methods that convert to double and back to int.
Gerd
I am thinking about if it makes sense to add a kind of sudden merging in the multipolygon cut routines. The idea is as follows: If the cut of an area returns more than 2 areas, two of the areas can safely be merged if their common edges (1 edge is the connection of two points) are all connected. This would result in less cut artifacts. Maybe it is also possible to remove points synthetically added by the cut. What do you think? WanMil
Hi WanMil, I am thinking about if it makes sense to add a kind of sudden merging in the multipolygon cut routines. The idea is as follows: If the cut of an area returns more than 2 areas, two of the areas can safely be merged if their common edges (1 edge is the connection of two points) are all connected. This would result in less cut artifacts. Maybe it is also possible to remove points synthetically added by the cut. What do you think? WanMil Well, my algo will probably not merge these polygons because they share no identical points when they were created with Java2DConverter.areaToShapes(). Maybe we can change that when we maintain a map of all the coords in the path so that we don't create different Coord instances for equal (or highPrecEqual) points, but that will slow down these routines. I think you coded this in PrecompSeaSaver. I think the artifacts are created by the rounding that happens when we convert from or to java.awt.geom.Area. -- View this message in context: http://gis.19327.n5.nabble.com/shape-merger-in-high-prec-coord-branch-tp5793... Sent from the Mkgmap Development mailing list archive at Nabble.com.
I think the artifacts are created by the rounding that happens when we convert from or to java.awt.geom.Area.
Yes. After the multipolygon splitting only the first and the last point of a common edge of two polygons can be a point that is added artificially. It sounds possible to detect if it ca be removed. WanMil
Hi WanMil, ahh, I think now I understand. You just want to re-combine those parts that have a small number of points? That should be easy. I thought you suggest to parse the shapes created by Java2DConverter.areaToShapes() and replace the rounded values by the original coord instances so that the ShapeMergeFilter is again able to merge them. That would be more complex but might save a few more bytes. BTW: I tried the effect of an earlier merge. The effect is rather small, means, the img size did not decrease much, but without additional logic the merge takes much longer. Gerd
Date: Wed, 15 Jan 2014 21:55:17 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] shape merger in high-prec-coord branch
I think the artifacts are created by the rounding that happens when we convert from or to java.awt.geom.Area.
Yes. After the multipolygon splitting only the first and the last point of a common edge of two polygons can be a point that is added artificially. It sounds possible to detect if it ca be removed.
WanMil _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi WanMil, please check the changes in r2970 reg. MultiPolygonRelation. Is this the change you had in mind? Gerd
Date: Wed, 15 Jan 2014 21:55:17 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] shape merger in high-prec-coord branch
I think the artifacts are created by the rounding that happens when we convert from or to java.awt.geom.Area.
Yes. After the multipolygon splitting only the first and the last point of a common edge of two polygons can be a point that is added artificially. It sounds possible to detect if it ca be removed.
WanMil _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, good! This is the first part of my idea. Additionally I thought about what you have written as TODO: maybe better merge here? I think when cutting multipolygons it often happens that there are parts cut off that needn't be cut. I have attached a screenshot of a sea tile where I have colored some polygons in blue that could be merged to one big polygon. Maybe there is an advantage that some of the small cuts do not disappear on lower zoom levels because they belong to a bigger polygon. But I am not sure if that isn't already solved by your changes. WanMil
Hi WanMil,
please check the changes in r2970 reg. MultiPolygonRelation. Is this the change you had in mind?
Gerd
Date: Wed, 15 Jan 2014 21:55:17 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] shape merger in high-prec-coord branch
I think the artifacts are created by the rounding that happens when we convert from or to java.awt.geom.Area.
Yes. After the multipolygon splitting only the first and the last point of a common edge of two polygons can be a point that is added artificially. It sounds possible to detect if it ca be removed.
WanMil _______________________________________________ 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 WanMil, yes, a few more shapes were be merged because of this change. Only if the parts go into different sub divisions they are not merged. I am not sure if that works for precompiled sea data, I'll verify that tomorrow. Gerd WanMil wrote
Hi Gerd,
good! This is the first part of my idea. Additionally I thought about what you have written as TODO: maybe better merge here? I think when cutting multipolygons it often happens that there are parts cut off that needn't be cut. I have attached a screenshot of a sea tile where I have colored some polygons in blue that could be merged to one big polygon. Maybe there is an advantage that some of the small cuts do not disappear on lower zoom levels because they belong to a bigger polygon.
But I am not sure if that isn't already solved by your changes.
WanMil
Hi WanMil,
please check the changes in r2970 reg. MultiPolygonRelation. Is this the change you had in mind?
Gerd
Date: Wed, 15 Jan 2014 21:55:17 +0100 From:
wmgcnfg@
To:
mkgmap-dev@.org
Subject: Re: [mkgmap-dev] shape merger in high-prec-coord branch
I think the artifacts are created by the rounding that happens when we convert from or to java.awt.geom.Area.
Yes. After the multipolygon splitting only the first and the last point of a common edge of two polygons can be a point that is added artificially. It sounds possible to detect if it ca be removed.
WanMil _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mp_merge.png (16K) <http://gis.19327.n5.nabble.com/attachment/5793366/0/mp_merge.png>;
-- View this message in context: http://gis.19327.n5.nabble.com/shape-merger-in-high-prec-coord-branch-tp5793... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi WanMil, I see that shapes created from precompiled sea are merged, so it works in general. The problem remains that for low resolutions I have to merge the shapes before the coords are rounded. So, for low resolutions the shape merger stops too early, because it will not create shapes with > 250 points as long as we use the java.awt.geom.area to split those shapes, and the merger doesn't know the result of the RoundCoordsFilter which typically reduces the number of points drastically for low res. Gerd
Date: Thu, 16 Jan 2014 12:09:17 -0800 From: gpetermann_muenchen@hotmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] shape merger in high-prec-coord branch
Hi WanMil,
yes, a few more shapes were be merged because of this change. Only if the parts go into different sub divisions they are not merged. I am not sure if that works for precompiled sea data, I'll verify that tomorrow.
Gerd
WanMil wrote
Hi Gerd,
good! This is the first part of my idea. Additionally I thought about what you have written as TODO: maybe better merge here? I think when cutting multipolygons it often happens that there are parts cut off that needn't be cut. I have attached a screenshot of a sea tile where I have colored some polygons in blue that could be merged to one big polygon. Maybe there is an advantage that some of the small cuts do not disappear on lower zoom levels because they belong to a bigger polygon.
But I am not sure if that isn't already solved by your changes.
WanMil
Hi WanMil,
please check the changes in r2970 reg. MultiPolygonRelation. Is this the change you had in mind?
Gerd
Date: Wed, 15 Jan 2014 21:55:17 +0100 From:
wmgcnfg@
To:
mkgmap-dev@.org
Subject: Re: [mkgmap-dev] shape merger in high-prec-coord branch
I think the artifacts are created by the rounding that happens when we convert from or to java.awt.geom.Area.
Yes. After the multipolygon splitting only the first and the last point of a common edge of two polygons can be a point that is added artificially. It sounds possible to detect if it ca be removed.
WanMil _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mp_merge.png (16K) <http://gis.19327.n5.nabble.com/attachment/5793366/0/mp_merge.png>;
-- View this message in context: http://gis.19327.n5.nabble.com/shape-merger-in-high-prec-coord-branch-tp5793... 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
participants (5)
-
Gerd Petermann -
GerdP
-
Minko -
Steve Ratcliffe -
WanMil