Hi WanMil, makeSplittable is called very seldom, and the number of points is typically also small, so performance really doesn't matter here (at least not with my test cases). I did not want to modify the points of the original MapLine object to avoid side effects. I did also want to avoid complex calculations for the new points, so I simply always add one new point in the middle of the existing ones. Adding the calculated points to the List coords that is used to create the new MapLine objects might be an option, but I did not find a simple way to handle the loop control for cases where we have to add multiple points. So, in short, I didn't find a better solution. Regarding the other changes in the patch: I agree that the code is complex, but I did not see a reason for a complete rework. Gerd WanMil wrote
Hi Gerd,
the LineSizeSplitterFilter patch is a good idea. After reading the code I am not sure if the other changes work for all situations (just because the things are quite complex there). I think I will wait for at least one week if someone complains...
Anyhow I want you as our performance guy to have a look on the LineSizeSplitterFilter :-) makeSplittable always copies all points although it changes them in very rare cases. Can you check (and implement) the following approach? ListIterator<Coord> iter = points.listIterator(); Check all subsequent points. If maxWidth or maxHeight is exceeded calculate the number of points that must be added (something like int split = Math.max(realWith/maxWidth, realHeigh/maxHeight)) Go back one point in the list iterator and add the additional points to the list iterator.
WanMil
Hi all,
attached is a corrected version of the patch. Please note the change in the logger initialisation for LineSizeSplitterFilter. I guess the old code was not intended.
Gerd http://gis.19327.n5.nabble.com/file/n5680163/subdivision_width_v2.patch subdivision_width_v2.patch
GerdP wrote
Hi Marko,
unfortunately it produces new errors for a tile in south-america which wasn't in my test data yesterday, so it should not be used yet :-(
Gerd
Marko Mäkelä wrote
Hi Gerd,
http://gis.19327.n5.nabble.com/file/n5672934/subdivision_width_v1.patch
Thanks, this removed the message. I did not test the resulting map yet, but I will do that when downloading and compiling the next map extract.
Marko _______________________________________________ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- View this message in context: http://gis.19327.n5.nabble.com/Patch-V1-Subdivision-width-is-36627-at-323091... 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.n5.nabble.com/Patch-V1-Subdivision-width-is-36627-at-323091... Sent from the Mkgmap Development mailing list archive at Nabble.com.