[Tilesathome] New preprocessor - area center

[Jiri Klement]

> Right now we can easily switch between osma (XSLT)/orp and inkscape/batik
> because the output of these alternatives is identical.

Actually it is not. XSLT and orp use different algorithm for icon
placing. You can see it in images from the first mail (*). The images
have extra symbol - bus in the middle of woods - to show how
xslt/orp/areacenter deal with different shapes.

> Imagine 2 neghboring z12 tiles with an overlapping caption. If they use
> different algorithms to place their labels the result looks.. interesting
> (this is a problem with the current lowzoom captions already).
>
> I have no strong feelings about these issues, though, and refer to deelkar
> as client lead developers to make calls like this.

Well I didn't think about neighbouring tiles. Anyway those issues has
always been here and nobody complained yet. So I guess it doesn't
happen that often.

I should clarify that I didn't make the area center preprocessor to
make XSLT faster. It's just side product. I've made it because
somebody at Czech mailing list complained about how icon and text are
placed in osmarender layer. This involves mainly orp which use just
simple bbox center algorithm. Anyway I think that in the end is area
center preproccesor doing even better work than XSLT.

The area center preprocessor can be rewritten in perl. It will make it
harder to manage, but it's possible. Anyway I think Java dependency is
worth including because you can do nice tricks with osmosis and batik.
Look at close-area.pl. It's currently broken because it use home
brewed code to read xml. Writing the same thing as osmosis plugin
would be a piece of cake. Batik is not just svg renderer. I'm pretty
sure you can use it to get styled size of captions, so it would be
possible to make collision detection based on real caption size.

* http://lists.openstreetmap.org/pipermail/tilesathome/2008-September/003678.html

--
Jiri