> >
>
> 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