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 <[email protected]> im Auftrag
> von Ticker Berkin <[email protected]>
> Gesendet: Dienstag, 7. Februar 2017 14:34:36
> An: [email protected]
> 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 <[email protected]> im Auftrag
> > von Ticker Berkin <[email protected]>
> > Gesendet: Dienstag, 7. Februar 2017 13:45:25
> > An: [email protected]
> > 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
> > [email protected]
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> > _______________________________________________
> > mkgmap-dev mailing list
> > [email protected]
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> [email protected]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> [email protected]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
