[mkgmap-dev] r3784 produces large img files than r3773
From Gerd Petermann GPetermann_muenchen at hotmail.com on Tue Feb 7 18:17:35 GMT 2017
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 at lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap at jagit.co.uk> Gesendet: Dienstag, 7. Februar 2017 18:43:43 An: mkgmap-dev at 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 at lists.mkgmap.org.uk> im Auftrag > von Ticker Berkin <rwb-mkgmap at jagit.co.uk> > Gesendet: Dienstag, 7. Februar 2017 14:34:36 > An: mkgmap-dev at 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 at lists.mkgmap.org.uk> im Auftrag > > von Ticker Berkin <rwb-mkgmap at jagit.co.uk> > > Gesendet: Dienstag, 7. Februar 2017 13:45:25 > > An: mkgmap-dev at 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 at lists.mkgmap.org.uk > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > _______________________________________________ > > mkgmap-dev mailing list > > mkgmap-dev at lists.mkgmap.org.uk > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev at lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev at lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev at lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
- Previous message: [mkgmap-dev] r3784 produces large img files than r3773
- Next message: [mkgmap-dev] r3784 produces large img files than r3773
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the mkgmap-dev mailing list