Re: [mkgmap-dev] patch to write polygons in decreasing order
Hi Ticker, okay, I will try on my own later. Please review the patch: 1) log messages esp. those with log.warn. I think most are debug messages ? This one looks wrong to me: ""Area single pixel shifted so can't split at " What does it mean? 2) Comments / javadoc : Please remove commented code and add javadoc without jokes like @return An area containing xsplit*ysplit areas (hopefully). Instead try to explain in what case the result will be null. BTW: It seems that this change in the code no longer depends on the new option. Is that intended? Gerd Ticker Berkin wrote > Hi Gerd > > I've been looking at ShapeSplitter and clipping to a rectangle > algorithms generally. I don't feel I know enough about how to use the > java.awt.geom package to implement this effectively, and so I'd rather > keep to using Java2DConverter and .intersect(), even though it is most > likely much less efficient. > > Ticker > > On Sat, 2016-11-05 at 23:33 -0700, Gerd Petermann wrote: >> Hi Ticker, >> >> Gerd Petermann wrote >> > Alternative would be to implement a clipper which doesn't need >> > area.intersect(). I've once coded the "Sutherland-Hodgman >> > algorithm" but >> > ways or concave shapes producing spikes, but I still think this >> > would be a >> > great improvement. See attached (out-aged) patch and the wiki >> > https://en.wikipedia.org/wiki/Sutherland%E2%80%93Hodgman_algorithm >> > for further details. >> >> I just noticed that the algo is already used in >> ShapeSplitter.clipSinglePathWithSutherlandHodgman(), >> the comment says >> "Clip a single path with a given rectangle using the Sutherland >> -Hodgman >> algorithm. This is much faster compared to the area.intersect method, >> but >> may create dangling edges." >> I think these danling edges are now removed in the >> RemoveObsoletePointsFilter, so maybe it is worth >> trying. >> >> Gerd >> >> >> >> >> -- >> View this message in context: http://gis.19327.n8.nabble.com/patch-to >> -write-polygons-in-decreasing-order-tp5884038p5885439.html >> Sent from the Mkgmap Development mailing list archive at Nabble.com. >> ___ >> mkgmap-dev mailing list >> > mkgmap-dev@.org >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > ___ > mkgmap-dev mailing list > mkgmap-dev@.org > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- View this message in context: http://gis.19327.n8.nabble.com/patch-to-write-polygons-in-decreasing-order-tp5884038p5885541.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] patch to write polygons in decreasing order
Hi Gerd I've been looking at ShapeSplitter and clipping to a rectangle algorithms generally. I don't feel I know enough about how to use the java.awt.geom package to implement this effectively, and so I'd rather keep to using Java2DConverter and .intersect(), even though it is most likely much less efficient. Ticker On Sat, 2016-11-05 at 23:33 -0700, Gerd Petermann wrote: > Hi Ticker, > > Gerd Petermann wrote > > Alternative would be to implement a clipper which doesn't need > > area.intersect(). I've once coded the "Sutherland-Hodgman > > algorithm" but > > ways or concave shapes producing spikes, but I still think this > > would be a > > great improvement. See attached (out-aged) patch and the wiki > > https://en.wikipedia.org/wiki/Sutherland%E2%80%93Hodgman_algorithm > > for further details. > > I just noticed that the algo is already used in > ShapeSplitter.clipSinglePathWithSutherlandHodgman(), > the comment says > "Clip a single path with a given rectangle using the Sutherland > -Hodgman > algorithm. This is much faster compared to the area.intersect method, > but > may create dangling edges." > I think these danling edges are now removed in the > RemoveObsoletePointsFilter, so maybe it is worth > trying. > > Gerd > > > > > -- > View this message in context: http://gis.19327.n8.nabble.com/patch-to > -write-polygons-in-decreasing-order-tp5884038p5885439.html > Sent from the Mkgmap Development mailing list archive at Nabble.com. > ___ > 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
Re: [mkgmap-dev] Spurious points & Basecamp blank tiles
7.11.2016, 20:59, nwillink kirjoitti: This is not a mkgmap error but clearly points to a type number Basecamp objects to. Perhaps your 0x30 in lines? -- View this message in context: http://gis.19327.n8.nabble.com/Spurious-points-Basecamp-blank-tiles-tp5885434p5885528.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev 0x30 types were problematic, but I tested that these artifacts are created without 0x30 lines. It looks like artifacts appear after I merge original OSM data to pbf files. Original custom pbf files converted from National Topographic Database GML has node/way/relations ids starting from 50. Merged OSM data naturally has much smaller ids. I'm thinking this could have something to do with this problem. -Teemu ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Spurious points & Basecamp blank tiles
This is not a mkgmap error but clearly points to a type number Basecamp objects to. Perhaps your 0x30 in lines? -- View this message in context: http://gis.19327.n8.nabble.com/Spurious-points-Basecamp-blank-tiles-tp5885434p5885528.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
