r3784 produces large img files than r3773
Hi Ticker, I compared the sizes for a map of spain with and without option --order-by-decreasing-area, I always see larger files with r3784. With r3777 and r3778 the files are typically a bit smaller than with r3773. Is there a good reason for that ? Gerd
Hi Gerd Most of the changes that will make a difference to size are related to MapArea/SubDivision contents and splitting hence ShapeMergeFilter activity. As far as changes in size between the versions: 3782-3784 should be similar and a little bit worse than 3781 because of a fix to stop a large subdivision being extended on both sides 3781 should be quite a lot better than 3780 because it stops irrelevant items being added to the MapArea data usage count, triggering more splitting than necessary 3779 should be better than 3778 because it should stop a lot of splitting at lower resolution 3778-3774 should be broadly similar Relating to a given version with and without OrderByDecreasingArea: I've always found images a bit bigger - sometimes up to 4% for areas with large numbers of adjacent buildings that shapeMergeFilter joins. I haven't done anything intentional that would change this in any of the recent revisions. I'm not sure if this answers your question Ticker On Fri, 2017-02-03 at 16:32 +0000, Gerd Petermann wrote:
Hi Ticker,
I compared the sizes for a map of spain with and without option - -order-by-decreasing-area, I always see larger files with r3784. With r3777 and r3778 the files are typically a bit smaller than with r3773. Is there a good reason for that ?
Gerd _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Ticker, my impression is that the new algos are more likely to place nearby objects into different sub divs, that would be bad for ShapeMergeFilter, esp. without --order-by-decreasing-area. I'll try to find out more tomorrow if you have no simple fix for that. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 3. Februar 2017 18:56:06 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773 Hi Gerd Most of the changes that will make a difference to size are related to MapArea/SubDivision contents and splitting hence ShapeMergeFilter activity. As far as changes in size between the versions: 3782-3784 should be similar and a little bit worse than 3781 because of a fix to stop a large subdivision being extended on both sides 3781 should be quite a lot better than 3780 because it stops irrelevant items being added to the MapArea data usage count, triggering more splitting than necessary 3779 should be better than 3778 because it should stop a lot of splitting at lower resolution 3778-3774 should be broadly similar Relating to a given version with and without OrderByDecreasingArea: I've always found images a bit bigger - sometimes up to 4% for areas with large numbers of adjacent buildings that shapeMergeFilter joins. I haven't done anything intentional that would change this in any of the recent revisions. I'm not sure if this answers your question Ticker On Fri, 2017-02-03 at 16:32 +0000, Gerd Petermann wrote:
Hi Ticker,
I compared the sizes for a map of spain with and without option - -order-by-decreasing-area, I always see larger files with r3784. With r3777 and r3778 the files are typically a bit smaller than with r3773. Is there a good reason for that ?
Gerd _______________________________________________ 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 the problem is that PredictFilterPoints ignores the fact that the DouglasPeuckerFilter typically reduces the number of nodes. The result is that many shapes are split although they would not have too many points after DouglasPeuckerFilter. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen@hotmail.com> Gesendet: Freitag, 3. Februar 2017 19:28:13 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773 Hi Ticker, my impression is that the new algos are more likely to place nearby objects into different sub divs, that would be bad for ShapeMergeFilter, esp. without --order-by-decreasing-area. I'll try to find out more tomorrow if you have no simple fix for that. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 3. Februar 2017 18:56:06 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773 Hi Gerd Most of the changes that will make a difference to size are related to MapArea/SubDivision contents and splitting hence ShapeMergeFilter activity. As far as changes in size between the versions: 3782-3784 should be similar and a little bit worse than 3781 because of a fix to stop a large subdivision being extended on both sides 3781 should be quite a lot better than 3780 because it stops irrelevant items being added to the MapArea data usage count, triggering more splitting than necessary 3779 should be better than 3778 because it should stop a lot of splitting at lower resolution 3778-3774 should be broadly similar Relating to a given version with and without OrderByDecreasingArea: I've always found images a bit bigger - sometimes up to 4% for areas with large numbers of adjacent buildings that shapeMergeFilter joins. I haven't done anything intentional that would change this in any of the recent revisions. I'm not sure if this answers your question Ticker On Fri, 2017-02-03 at 16:32 +0000, Gerd Petermann wrote:
Hi Ticker,
I compared the sizes for a map of spain with and without option - -order-by-decreasing-area, I always see larger files with r3784. With r3777 and r3778 the files are typically a bit smaller than with r3773. Is there a good reason for that ?
Gerd _______________________________________________ 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, attached is a patch based on r3777 which implements my idea of backtracking, see gis.19327.n8.nabble.com/Multipolygon-Relation-checks-in-mkgmap-tt5889908.html I think this is the better way to implement the split at high prec. It's based on r3777 because that was the last version without the PredictFilterPoints. I did not try to implement the other improvements done in later releases. What do you think about this approach? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen@hotmail.com> Gesendet: Samstag, 4. Februar 2017 09:18:38 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773 Hi Ticker, I think the problem is that PredictFilterPoints ignores the fact that the DouglasPeuckerFilter typically reduces the number of nodes. The result is that many shapes are split although they would not have too many points after DouglasPeuckerFilter. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen@hotmail.com> Gesendet: Freitag, 3. Februar 2017 19:28:13 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773 Hi Ticker, my impression is that the new algos are more likely to place nearby objects into different sub divs, that would be bad for ShapeMergeFilter, esp. without --order-by-decreasing-area. I'll try to find out more tomorrow if you have no simple fix for that. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 3. Februar 2017 18:56:06 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773 Hi Gerd Most of the changes that will make a difference to size are related to MapArea/SubDivision contents and splitting hence ShapeMergeFilter activity. As far as changes in size between the versions: 3782-3784 should be similar and a little bit worse than 3781 because of a fix to stop a large subdivision being extended on both sides 3781 should be quite a lot better than 3780 because it stops irrelevant items being added to the MapArea data usage count, triggering more splitting than necessary 3779 should be better than 3778 because it should stop a lot of splitting at lower resolution 3778-3774 should be broadly similar Relating to a given version with and without OrderByDecreasingArea: I've always found images a bit bigger - sometimes up to 4% for areas with large numbers of adjacent buildings that shapeMergeFilter joins. I haven't done anything intentional that would change this in any of the recent revisions. I'm not sure if this answers your question Ticker On Fri, 2017-02-03 at 16:32 +0000, Gerd Petermann wrote:
Hi Ticker,
I compared the sizes for a map of spain with and without option - -order-by-decreasing-area, I always see larger files with r3784. With r3777 and r3778 the files are typically a bit smaller than with r3773. Is there a good reason for that ?
Gerd _______________________________________________ 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
Hi Gerd One of the reasons I went along the PredictPoints route is that MapArea was calculating the subDivision usage (number of items, amount of data) based on totally unfiltered lines/polygons, regardless of the resolution, so this was forcing splits where no need whatsoever. I didn't want to add additional complexity to it (ie DouglasPeuker). Even without that it makes a big improvement, mainly at lower resolution levels. It must never underestimate the number of points, but slight overestimation is still masses better than previous behavior. Generally subdivisions are much fuller, hence there should be more scope for ShapeMergeFilter. Having backtracking to do the points-limit splitting will be better than doing it earlier based on PredictPoints I don't think this the full reason for the change in images size behaviour that you see; I need to think a bit more about grouping items during splitting. I can't do anything for a couple of days but I'd like to combine the methods. Ticker
Hi Ticker, Ticker Berkin wrote
I can't do anything for a couple of days but I'd like to combine the methods.
sounds good to me. I once analysed why sub divs were split and found that most times it was because of "too many points" or "too many lines", not because of "too much data in rgn", but that might depend on style. Gerd -- View this message in context: http://gis.19327.n8.nabble.com/r3784-produces-large-img-files-than-r3773-tp5... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd I've done this and committed. In the examples I found, using backtracking to split the polygon gave very slight size improvements (best was about 0.05%) Ticker On Sat, 2017-02-04 at 06:10 -0700, Gerd Petermann wrote:
Hi Ticker,
Ticker Berkin wrote
I can't do anything for a couple of days but I'd like to combine the methods.
sounds good to me. I once analysed why sub divs were split and found that most times it was because of "too many points" or "too many lines", not because of "too much data in rgn", but that might depend on style.
Gerd
-- View this message in context: http://gis.19327.n8.nabble.com/r3784-pr oduces-large-img-files-than-r3773-tp5890509p5890561.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
Hi Ticker, that's what I expected. Most shapes do not have too many points after line simplification. If I got that right most of the code in PolygonSplitterFilter is now obsolete. I think it would be better to move the functionality of PolygonSplitIfNeededFilter into it so that the history is kept. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 7. Februar 2017 12:49:02 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773 Hi Gerd I've done this and committed. In the examples I found, using backtracking to split the polygon gave very slight size improvements (best was about 0.05%) Ticker On Sat, 2017-02-04 at 06:10 -0700, Gerd Petermann wrote:
Hi Ticker,
Ticker Berkin wrote
I can't do anything for a couple of days but I'd like to combine the methods.
sounds good to me. I once analysed why sub divs were split and found that most times it was because of "too many points" or "too many lines", not because of "too much data in rgn", but that might depend on style.
Gerd
-- View this message in context: http://gis.19327.n8.nabble.com/r3784-pr oduces-large-img-files-than-r3773-tp5890509p5890561.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
Done On Tue, 2017-02-07 at 12:17 +0000, Gerd Petermann wrote:
Hi Ticker,
that's what I expected. Most shapes do not have too many points after line simplification. If I got that right most of the code in PolygonSplitterFilter is now obsolete. I think it would be better to move the functionality of PolygonSplitIfNeededFilter into it so that the history is kept.
Gerd
Hi Ticker, thanks, I am still working a new algos to replace parts of the existing code in MultipolygonRelation, esp. that for createContainsMatrix(). I hope to finish the first patch tomorrow. If that takes much longer I plan to merge the branch into trunk first. Reg. refactoring: What do you think about adding orderByDecreasingArea as a (final) field in MapSplitter? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 7. Februar 2017 13:45:25 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773 Done On Tue, 2017-02-07 at 12:17 +0000, Gerd Petermann wrote:
Hi Ticker,
that's what I expected. Most shapes do not have too many points after line simplification. If I got that right most of the code in PolygonSplitterFilter is now obsolete. I think it would be better to move the functionality of PolygonSplitIfNeededFilter into it so that the history is kept.
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd orderByDecreasingArea only has a param declaration and single use in MapSplitter and its value transforms to MapArea.splitPolygonsIntoArea so I think it is better as it is. I had some thoughts on a simple/efficient algo for MultiPolygonRelation hole cutting - It won't produce the optimized cuts that yours is aiming for. If you are interested, I'll formulate some pseudo-code. Merge the branch whenever is best for you. Ticker On Tue, 2017-02-07 at 13:12 +0000, Gerd Petermann wrote:
Hi Ticker,
thanks, I am still working a new algos to replace parts of the existing code in MultipolygonRelation, esp. that for createContainsMatrix(). I hope to finish the first patch tomorrow. If that takes much longer I plan to merge the branch into trunk first. Reg. refactoring: What do you think about adding orderByDecreasingArea as a (final) field in MapSplitter?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 7. Februar 2017 13:45:25 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773
Done
On Tue, 2017-02-07 at 12:17 +0000, Gerd Petermann wrote:
Hi Ticker,
that's what I expected. Most shapes do not have too many points after line simplification. If I got that right most of the code in PolygonSplitterFilter is now obsolete. I think it would be better to move the functionality of PolygonSplitIfNeededFilter into it so that the history is kept.
Gerd
_______________________________________________ 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'd prefer to get a patch for MultipolygonCutter ;-) I guess the problems are similar to those in the split algo. Pseudo-Code for an alternative solution is also welcomed. FYI: I am implementing an index that allows to quickly find nearby way segments , I will use that to find intersections in mp-rels in the same way as I've implemented it with some patches for JOSM. The index might be useful for my cut algo as well. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 7. Februar 2017 14:34:36 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773 Hi Gerd orderByDecreasingArea only has a param declaration and single use in MapSplitter and its value transforms to MapArea.splitPolygonsIntoArea so I think it is better as it is. I had some thoughts on a simple/efficient algo for MultiPolygonRelation hole cutting - It won't produce the optimized cuts that yours is aiming for. If you are interested, I'll formulate some pseudo-code. Merge the branch whenever is best for you. Ticker On Tue, 2017-02-07 at 13:12 +0000, Gerd Petermann wrote:
Hi Ticker,
thanks, I am still working a new algos to replace parts of the existing code in MultipolygonRelation, esp. that for createContainsMatrix(). I hope to finish the first patch tomorrow. If that takes much longer I plan to merge the branch into trunk first. Reg. refactoring: What do you think about adding orderByDecreasingArea as a (final) field in MapSplitter?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 7. Februar 2017 13:45:25 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773
Done
On Tue, 2017-02-07 at 12:17 +0000, Gerd Petermann wrote:
Hi Ticker,
that's what I expected. Most shapes do not have too many points after line simplification. If I got that right most of the code in PolygonSplitterFilter is now obsolete. I think it would be better to move the functionality of PolygonSplitIfNeededFilter into it so that the history is kept.
Gerd
_______________________________________________ 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 Gerd Algo: Assumes list of outer polygons and list of inner ones; Which inners go in each outer unknown. No additional layers of nesting. Best not to clipToBounds at start - complicates logic a lot. Also assumed that this hasn't happened from map generation/splitting - ie don't expect edge of inner to run along edge out outer. Sort inners into order of top most point. Note this point (if more than 1 equal top point, remember L&R outermost) For each inner: For each outer: Make a test cut of outer across the line of inner top If resulted in >1 piece look through lower pieces for segment that follows cut line and encompasses the top of the inner if found note l&r distances from inner to ends of cut segment choose shorter and note end coord=x and 1 away from the cut=y go back to orig outer, find coord y depending on the outer direction and side make y prev coord // Now can insert the cut and inner after y: unclose inner reverse if same area/sign as outer rotate so that start is at top (l/r if appropriate) add these coords to orig outer after coord y: x, all inner, inner first coord, x break end for each outer error - didn't find outer for inner end for each inner That's it. Slight adjustments need to be made if x happens to be an original coordinate rather than one invented by ShapeSplitter Ticker On Tue, 2017-02-07 at 16:44 +0000, Gerd Petermann wrote:
Hi Ticker,
I'd prefer to get a patch for MultipolygonCutter ;-) I guess the problems are similar to those in the split algo. Pseudo-Code for an alternative solution is also welcomed.
FYI: I am implementing an index that allows to quickly find nearby way segments , I will use that to find intersections in mp-rels in the same way as I've implemented it with some patches for JOSM. The index might be useful for my cut algo as well.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 7. Februar 2017 14:34:36 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773
Hi Gerd
orderByDecreasingArea only has a param declaration and single use in MapSplitter and its value transforms to MapArea.splitPolygonsIntoArea so I think it is better as it is.
I had some thoughts on a simple/efficient algo for MultiPolygonRelation hole cutting - It won't produce the optimized cuts that yours is aiming for. If you are interested, I'll formulate some pseudo-code.
Merge the branch whenever is best for you.
Ticker
On Tue, 2017-02-07 at 13:12 +0000, Gerd Petermann wrote:
Hi Ticker,
thanks, I am still working a new algos to replace parts of the existing code in MultipolygonRelation, esp. that for createContainsMatrix(). I hope to finish the first patch tomorrow. If that takes much longer I plan to merge the branch into trunk first. Reg. refactoring: What do you think about adding orderByDecreasingArea as a (final) field in MapSplitter?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 7. Februar 2017 13:45:25 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773
Done
On Tue, 2017-02-07 at 12:17 +0000, Gerd Petermann wrote:
Hi Ticker,
that's what I expected. Most shapes do not have too many points after line simplification. If I got that right most of the code in PolygonSplitterFilter is now obsolete. I think it would be better to move the functionality of PolygonSplitIfNeededFilter into it so that the history is kept.
Gerd
_______________________________________________ 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
Hi Ticker, sounds to me as if this would produce only horizontal cut lines, possibly quite long and maybe very close to each other. That would be correct but not good for further processing. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 7. Februar 2017 18:43:43 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773 Hi Gerd Algo: Assumes list of outer polygons and list of inner ones; Which inners go in each outer unknown. No additional layers of nesting. Best not to clipToBounds at start - complicates logic a lot. Also assumed that this hasn't happened from map generation/splitting - ie don't expect edge of inner to run along edge out outer. Sort inners into order of top most point. Note this point (if more than 1 equal top point, remember L&R outermost) For each inner: For each outer: Make a test cut of outer across the line of inner top If resulted in >1 piece look through lower pieces for segment that follows cut line and encompasses the top of the inner if found note l&r distances from inner to ends of cut segment choose shorter and note end coord=x and 1 away from the cut=y go back to orig outer, find coord y depending on the outer direction and side make y prev coord // Now can insert the cut and inner after y: unclose inner reverse if same area/sign as outer rotate so that start is at top (l/r if appropriate) add these coords to orig outer after coord y: x, all inner, inner first coord, x break end for each outer error - didn't find outer for inner end for each inner That's it. Slight adjustments need to be made if x happens to be an original coordinate rather than one invented by ShapeSplitter Ticker On Tue, 2017-02-07 at 16:44 +0000, Gerd Petermann wrote:
Hi Ticker,
I'd prefer to get a patch for MultipolygonCutter ;-) I guess the problems are similar to those in the split algo. Pseudo-Code for an alternative solution is also welcomed.
FYI: I am implementing an index that allows to quickly find nearby way segments , I will use that to find intersections in mp-rels in the same way as I've implemented it with some patches for JOSM. The index might be useful for my cut algo as well.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 7. Februar 2017 14:34:36 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773
Hi Gerd
orderByDecreasingArea only has a param declaration and single use in MapSplitter and its value transforms to MapArea.splitPolygonsIntoArea so I think it is better as it is.
I had some thoughts on a simple/efficient algo for MultiPolygonRelation hole cutting - It won't produce the optimized cuts that yours is aiming for. If you are interested, I'll formulate some pseudo-code.
Merge the branch whenever is best for you.
Ticker
On Tue, 2017-02-07 at 13:12 +0000, Gerd Petermann wrote:
Hi Ticker,
thanks, I am still working a new algos to replace parts of the existing code in MultipolygonRelation, esp. that for createContainsMatrix(). I hope to finish the first patch tomorrow. If that takes much longer I plan to merge the branch into trunk first. Reg. refactoring: What do you think about adding orderByDecreasingArea as a (final) field in MapSplitter?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 7. Februar 2017 13:45:25 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773
Done
On Tue, 2017-02-07 at 12:17 +0000, Gerd Petermann wrote:
Hi Ticker,
that's what I expected. Most shapes do not have too many points after line simplification. If I got that right most of the code in PolygonSplitterFilter is now obsolete. I think it would be better to move the functionality of PolygonSplitIfNeededFilter into it so that the history is kept.
Gerd
_______________________________________________ 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
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd Yes - only horizontal lines (or all could be flipped to vertical). Maybe quite long, but each the shortest distance from top of inner to edge of outer (or earlier inner, which has now become part of the outer). Not sure why this would be bad for further processing. I was aiming for simplicity and efficiency. It was just a thought - please ignore. Ticker On Tue, 2017-02-07 at 18:17 +0000, Gerd Petermann wrote:
Hi Ticker,
sounds to me as if this would produce only horizontal cut lines, possibly quite long and maybe very close to each other. That would be correct but not good for further processing.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 7. Februar 2017 18:43:43 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773
Hi Gerd
Algo:
Assumes list of outer polygons and list of inner ones; Which inners go in each outer unknown. No additional layers of nesting.
Best not to clipToBounds at start - complicates logic a lot. Also assumed that this hasn't happened from map generation/splitting - ie don't expect edge of inner to run along edge out outer.
Sort inners into order of top most point. Note this point (if more than 1 equal top point, remember L&R outermost) For each inner: For each outer: Make a test cut of outer across the line of inner top If resulted in >1 piece look through lower pieces for segment that follows cut line and encompasses the top of the inner if found note l&r distances from inner to ends of cut segment choose shorter and note end coord=x and 1 away from the cut=y go back to orig outer, find coord y depending on the outer direction and side make y prev coord // Now can insert the cut and inner after y: unclose inner reverse if same area/sign as outer rotate so that start is at top (l/r if appropriate) add these coords to orig outer after coord y: x, all inner, inner first coord, x break end for each outer error - didn't find outer for inner end for each inner
That's it. Slight adjustments need to be made if x happens to be an original coordinate rather than one invented by ShapeSplitter
Ticker
On Tue, 2017-02-07 at 16:44 +0000, Gerd Petermann wrote:
Hi Ticker,
I'd prefer to get a patch for MultipolygonCutter ;-) I guess the problems are similar to those in the split algo. Pseudo-Code for an alternative solution is also welcomed.
FYI: I am implementing an index that allows to quickly find nearby way segments , I will use that to find intersections in mp-rels in the same way as I've implemented it with some patches for JOSM. The index might be useful for my cut algo as well.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 7. Februar 2017 14:34:36 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773
Hi Gerd
orderByDecreasingArea only has a param declaration and single use in MapSplitter and its value transforms to MapArea.splitPolygonsIntoArea so I think it is better as it is.
I had some thoughts on a simple/efficient algo for MultiPolygonRelation hole cutting - It won't produce the optimized cuts that yours is aiming for. If you are interested, I'll formulate some pseudo-code.
Merge the branch whenever is best for you.
Ticker
On Tue, 2017-02-07 at 13:12 +0000, Gerd Petermann wrote:
Hi Ticker,
thanks, I am still working a new algos to replace parts of the existing code in MultipolygonRelation, esp. that for createContainsMatrix(). I hope to finish the first patch tomorrow. If that takes much longer I plan to merge the branch into trunk first. Reg. refactoring: What do you think about adding orderByDecreasingArea as a (final) field in MapSplitter?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 7. Februar 2017 13:45:25 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773
Done
On Tue, 2017-02-07 at 12:17 +0000, Gerd Petermann wrote:
Hi Ticker,
that's what I expected. Most shapes do not have too many points after line simplification. If I got that right most of the code in PolygonSplitterFilter is now obsolete. I think it would be better to move the functionality of PolygonSplitIfNeededFilter into it so that the history is kept.
Gerd
_______________________________________________ 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
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 may be wrong but I think that WanMil (the initial author) also tried something like that. My understanding is that a shape with a very high aspect ratio is likely to "disappear" in the RoundCoordFilter, giving white stripes or triangles in the sea. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Mittwoch, 8. Februar 2017 00:34:01 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773 Hi Gerd Yes - only horizontal lines (or all could be flipped to vertical). Maybe quite long, but each the shortest distance from top of inner to edge of outer (or earlier inner, which has now become part of the outer). Not sure why this would be bad for further processing. I was aiming for simplicity and efficiency. It was just a thought - please ignore. Ticker On Tue, 2017-02-07 at 18:17 +0000, Gerd Petermann wrote:
Hi Ticker,
sounds to me as if this would produce only horizontal cut lines, possibly quite long and maybe very close to each other. That would be correct but not good for further processing.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 7. Februar 2017 18:43:43 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773
Hi Gerd
Algo:
Assumes list of outer polygons and list of inner ones; Which inners go in each outer unknown. No additional layers of nesting.
Best not to clipToBounds at start - complicates logic a lot. Also assumed that this hasn't happened from map generation/splitting - ie don't expect edge of inner to run along edge out outer.
Sort inners into order of top most point. Note this point (if more than 1 equal top point, remember L&R outermost) For each inner: For each outer: Make a test cut of outer across the line of inner top If resulted in >1 piece look through lower pieces for segment that follows cut line and encompasses the top of the inner if found note l&r distances from inner to ends of cut segment choose shorter and note end coord=x and 1 away from the cut=y go back to orig outer, find coord y depending on the outer direction and side make y prev coord // Now can insert the cut and inner after y: unclose inner reverse if same area/sign as outer rotate so that start is at top (l/r if appropriate) add these coords to orig outer after coord y: x, all inner, inner first coord, x break end for each outer error - didn't find outer for inner end for each inner
That's it. Slight adjustments need to be made if x happens to be an original coordinate rather than one invented by ShapeSplitter
Ticker
On Tue, 2017-02-07 at 16:44 +0000, Gerd Petermann wrote:
Hi Ticker,
I'd prefer to get a patch for MultipolygonCutter ;-) I guess the problems are similar to those in the split algo. Pseudo-Code for an alternative solution is also welcomed.
FYI: I am implementing an index that allows to quickly find nearby way segments , I will use that to find intersections in mp-rels in the same way as I've implemented it with some patches for JOSM. The index might be useful for my cut algo as well.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 7. Februar 2017 14:34:36 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773
Hi Gerd
orderByDecreasingArea only has a param declaration and single use in MapSplitter and its value transforms to MapArea.splitPolygonsIntoArea so I think it is better as it is.
I had some thoughts on a simple/efficient algo for MultiPolygonRelation hole cutting - It won't produce the optimized cuts that yours is aiming for. If you are interested, I'll formulate some pseudo-code.
Merge the branch whenever is best for you.
Ticker
On Tue, 2017-02-07 at 13:12 +0000, Gerd Petermann wrote:
Hi Ticker,
thanks, I am still working a new algos to replace parts of the existing code in MultipolygonRelation, esp. that for createContainsMatrix(). I hope to finish the first patch tomorrow. If that takes much longer I plan to merge the branch into trunk first. Reg. refactoring: What do you think about adding orderByDecreasingArea as a (final) field in MapSplitter?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 7. Februar 2017 13:45:25 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773
Done
On Tue, 2017-02-07 at 12:17 +0000, Gerd Petermann wrote:
Hi Ticker,
that's what I expected. Most shapes do not have too many points after line simplification. If I got that right most of the code in PolygonSplitterFilter is now obsolete. I think it would be better to move the functionality of PolygonSplitIfNeededFilter into it so that the history is kept.
Gerd
_______________________________________________ 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
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 (3)
-
Gerd Petermann -
Gerd Petermann
-
Ticker Berkin