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

Tue Feb 7 23:34:01 GMT 2017

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 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
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev