[mkgmap-dev] r3784 produces large img files than r3773

Tue Feb 7 17:43:43 GMT 2017

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