[mkgmap-dev] Multipolygon-Relation checks in mkgmap
From Ticker Berkin rwb-mkgmap at jagit.co.uk on 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
- Previous message: [mkgmap-dev] Multipolygon-Relation checks in mkgmap
- Next message: [mkgmap-dev] Multipolygon-Relation checks in mkgmap
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the mkgmap-dev mailing list