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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 26. Januar 2017 11:40:09 An: mkgmap-dev@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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Mittwoch, 25. Januar 2017 15:56:06 An: mkgmap-dev@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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Mittwoch, 25. Januar 2017 13:25:34 An: mkgmap-dev@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@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev