Hi WanMil,
Reducing the img file size is a nice subeffect. As long as I don't know for sure that spikes are not an error I would avoid to leave them in the img.
I agree.
Sometimes the result of the RoundCoordsFilter is an invalid polygons, which means the polygon might be self intersecting and/or contains spikes and holes as it could be seen in my example. These invalid polygons are forwarded to other filters.
To be honest: I haven't checked if my example polygon looks bad in the map. But checking the code I see the following might happen: 1. RoundCoordsFilter creates an invalid polygon with hole 2. PolygonSplitterFilter might split the polygon because it is too large. It converts the polygon to a java.awt.geom.Area object, splits it into two halves and converts it back in the method PolygonSplitterBase.areaToShapes(..) method. This method does not check the orientation of the returned polygons and therefore converts the hole to same type the polygon has - in other words the hole is removed.
Of course we could say this is an error of the PolygonSplitterBase.areaToShapes(..) method (and we can fix it) but I think it would be worthy to check and optimize the whole chain a polygon goes through. Maybe we find needless steps we can remove, maybe we find other errors we can fix and maybe we can improve some steps which will improve the overall results. At the moment I guess nobody can say for sure what really happens in the long chain.
Yes, I got the same impression. I started to add some createGPX calls to be able to compare the input coming from StyledConverter and the output that is written to the img (if at all). I think the most obvious problem is the cutOutInnerPolygons() method that creates the thin areas which are later deformed by the filters. I will focus on that. Ciao, Gerd