Hi WanMil,
After I added switch so that your change did not handle roads the effect was near zero.
What do you mean with effect? I think that you cannot measure the effect just by checking the img file sizes.
I know that the img file size changes do not increase in steps of one byte. Well, your special case did not occur in my test data. Maybe that was bad luck, I try with some more tiles. I thought the change is meant to reduce the *.img size? Or do you think that it is an error to have such spikes in the *.img?
Ciao, Gerd
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. 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. WanMil