[OSM-dev] [OSM] Informations about osmarender for Google SoC
frederik at remote.org
Sun Mar 23 14:15:42 GMT 2008
>> I could imagine that for a simple raw preview
>> functionality, one could take the procedural variant of Osmarender
>> replace the SVG generator bit by writing directly to a Cairo or GD
>> canvas (or generationg Java2D graphics instructions). This would
>> perhaps not give you the 100% true result, but should definitely be
>> good enough to fine-tune a rule file. If you chose that way, you
>> achieve near-realtime turnaround times, ideal for a WYSIWYG editor.
> Unfortunately, I didn't yet used osmarender nor batik so I don't
> know what is the average processing time (is it so high? :( )
Of course the processing time depends highly on what you want to
render. Rendering the city of Karlsruhe takes about 30 seconds for
the XSLT part and another 60 seconds to display the resulting SVG, on
a fast machine; but if you work with a reasonable sub-section then it
will be faster.
> Because if it's reasonable, we could use Java XSLT processor to do
> the conversion internally and then send to batik viewer the
> resulting SVG. IMHO (if possible!) this could give us two advantages:
> 1) It's simpler to implement (I've seen that Osmarender's XSLT uses
> also CSS internally, this is a little bit more of complexity to
> handle, but you can tell me :))), so we can focus the attention on
> the rules algorithm and, most of all, plugin usability.
> 2) It will be more modular. If something is changed in Osmarender
> XSLT for some reason, we don't have to change the whole "Java2D
> generator" algorithm, but we can focus on the rules changed. So, in
> the future, we have not to support two "branches" that do the
> "same" thing.
All true. But the XSLT part of Osmarender has become complex to the
point of being un-manageable (about 3k lines of XSLT code, with
Taylor series to compute trigonometric formulae and stuff), or let's
say manageable only by a select minority. That's why I did the Perl
implemenentation, hoping to open up development to more people. We'll
see how well this is received. I'd say that the rules files will
certainly stay, but whehter or not the XSLT part will stay remains to
Frederik Ramm ## eMail frederik at remote.org ## N49°00'09" E008°23'33"
More information about the dev