[mkgmap-dev] Multipolygon-Relation checks in mkgmap

Thu Jan 26 14:53:00 GMT 2017

I'll try something like this.

On a slightly related point, a some of the filters are suppressed at
the highest res (24) - wont OSM data have a higher res. than this and
so could there be multiple adjacent points on a line/poly with the same
std mapRes coordinates?

Ticker 

On Thu, 2017-01-26 at 10:54 +0000, Gerd Petermann wrote:
> Hi Ticker,
> 
> I like the idea to do the cutting only at high-prec. Maybe some
> backtracking algo would help here?
> Something like
> "If the shape is still to complex after DouglasPeucker was applied go
> back, split, and try again."
> 
> Gerd
> 
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> Gesendet: Donnerstag, 26. Januar 2017 11:40:09
> An: mkgmap-dev at lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] Multipolygon-Relation checks in mkgmap
> 
> Hi Gerd
> 
> Ah.
> 
> I need to have a think about when the filters operate and do they
> generate new points. It is quite expensive to detect polygon self
> -intersection (and that probably quite a bit of the cost if using
> Java2D intersect) so don't think this should be added into filters as
> well.
> 
> My idea would be along the lines of always cutting at high-prec, only
> doing real filtering at the final map generation stage, but having
> pre
> -filter functions that have estimates of the number of points in
> line/poly so that splitting can be done earlier presumed necessary
> 
> Also, when a polygon is known to cover too large an area, instead of
> being split arbitrarily by PolyonSubDivSizeSplitter, it is split as
> part of MapSplitter.SplitMaxSize, forcing it into the
> MapArea.splitIntoAreas logic.
> 
> Ticker
> 
> On Thu, 2017-01-26 at 08:42 +0000, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > the overlap is produced by the RoundCoordsFilter at res 20. This is
> > quite normal and the algo should be able to handle
> > them. The alternative would be to change the the filter(s) so that
> > they don't produce self- intersecting polygons.
> > 
> > Gerd
> > 
> > ________________________________________
> > Von: Gerd Petermann
> > Gesendet: Mittwoch, 25. Januar 2017 16:22:05
> > An: Development list for mkgmap
> > Betreff: AW: [mkgmap-dev] Multipolygon-Relation checks in mkgmap
> > 
> > Hi Ticker,
> > 
> > okay, I'll have a look at the branch. The problem  in
> > http://www.openstreetmap.org/relation/2199651
> > is solved with r3773, but your case looks different.
> > 
> > Gerd
> > 
> > ________________________________________
> > Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> > von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> > Gesendet: Mittwoch, 25. Januar 2017 15:56:06
> > An: mkgmap-dev at lists.mkgmap.org.uk
> > Betreff: Re: [mkgmap-dev] Multipolygon-Relation checks in mkgmap
> > 
> > Hi Gerd
> > 
> > Using your split of germany, 63240135.osm.pbf gives me the problem
> > after I converted PolygonSplitterBase and AreaClipper to the new
> > algo
> > 
> > It is the outer way of relation/27312 at 48.94071,13.70245
> > At highest resolution, openStreetMap shows no intersection, but
> > when
> > I
> > dump the highRes points after the split complains and plot them it
> > shows an overlap.
> > 
> > Ticker
> > 
> > On Wed, 2017-01-25 at 14:29 +0000, Gerd Petermann wrote:
> > > Hi Ticker,
> > > 
> > > do you have an example for such a problem case?
> > > 
> > > Gerd
> > > 
> > > ________________________________________
> > > Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im
> > > Auftrag
> > > von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> > > Gesendet: Mittwoch, 25. Januar 2017 13:25:34
> > > An: mkgmap-dev at lists.mkgmap.org.uk
> > > Betreff: Re: [mkgmap-dev] Multipolygon-Relation checks in mkgmap
> > > 
> > > Hi Gerd
> > > 
> > > Yes - please
> > > 
> > > I started looking at MultiPolygonRelation yesterday with a view
> > > of
> > > trying to convert it to use the new ShapeSplitter algorithm.
> > > 
> > > I think that the way a self-intersecting polygon is rewritten
> > > after
> > > a
> > > split using the Java2D library causes problems for the new
> > > algorithm
> > > when it makes a later cut for points limits or subdivisions, even
> > > when
> > > the next cut isn't in the overlapped area.
> > > 
> > > All I've done so far is convert a few more places to use highPrec
> > > logic
> > > and then slightly disparaging at the complexity of the whole
> > > thing.
> > > 
> > > Ticker
> > > 
> > > On Wed, 2017-01-25 at 09:05 +0000, Gerd Petermann wrote:
> > > > Hi all,
> > > > 
> > > > I'd like to rewrite the code in MultiPolygonRelation so that it
> > > > tolerates more mp-rels.
> > > > For example, the relation
> > > > http://www.openstreetmap.org/relation/2199651
> > > > produces these warnings:
> > > > WARN: uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation
> > > >  f:\osm\rel2199651.osm: Some polygons are intersecting. This is
> > > > not
> > > > allowed in multipolygons.
> > > > WARN: uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation
> > > >  f:\osm\rel2199651.osm: -
> > > > http://www.openstreetmap.org/way/165084794
> > > > WARN: uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation
> > > >  f:\osm\rel2199651.osm: -
> > > > http://www.openstreetmap.org/way/165084810
> > > > WARN: uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation
> > > >  f:\osm\rel2199651.osm: Polygon
> > > > 4611686018427387906(8P)(165084810[8P]) carries role inner but
> > > > is
> > > > not
> > > > inside any other polygon. Potentially it does not belong to
> > > > this
> > > > multipolygon.
> > > > The inner way touches the outer way in one point. My
> > > > understanding
> > > > is
> > > > that this is correct, mkgmap should not complain about it.
> > > > 
> > > >  OK?
> > > > 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
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev