Hi Frederik, > I think this is not clear to many
Great! :) > I could imagine that for a simple raw preview > functionality, one could take the procedural variant of Osmarender and > 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 could > 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? :( ). 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. Another thing to consider is about batik's licensing, don't know if it's "compatible" with OSM's. Bye! Mario _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
