[OSM-dev] [OSM] Informations about osmarender for Google SoC
frederik at remote.org
Sun Mar 23 15:26:55 GMT 2008
> So, if we want to mantain XSLT, there should be a way to display
> only a subset of the SVG, with a sort of global preview and the
> classical "rectangle", which could be used to zoom only single
> parts of the map. When you use the rectangle, the program should
> take only the points that are contained in those lat/lon
> coordinates and show them. But I don't know how difficult this
> could be to achieve. I see issues such as full OSM file searching
> (I don't know if the OSM file has some kind of internal ordering)
> and cutting away the way/areas lines (even if this could be
> workarounded by not displaying those parts :)).
Currently all clipping in Osmarender is done through SVG, i.e.
Osmarender always renders the full input even if you request to see
only a small rectangle, and then it is left to the SVG renderer to
cut out that rectangle. For top-quality maps this is probably
unavoidable as there might be nods outside the rectangle that still
influence what is seen inside the rectangle (think a node
representing "place=city name=London" just outside your box; the text
would stretch into the box). But for a quick preview you could
probably do filtering.
> Also, if I'm not wrong, there is a way to select osmarender's
> zoom... so if the user select a low zoom, the map has to be
> displayed as a whole, and I see no way to workaround this.
Keep in mind that you are not writing a WYSIWYG map editor; your aim
is to allow the user to edit the rules file! You'd probably have to
pre-filter the data according to what is rendered at all, or just
create a fixed demo file. This is perhaps the simpler way for your
task: Manually create a "demo" file that contains a lot of rendering
cases and use this to let the user determine what he wants...
>> 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 be seen.
> I've a problem with this, because I've never studied Perl.
I'm not saying you should use Perl, just that you should not assume
that XSLT is here to stay. It would be really easy to convert the
Perl stuff to Java, or if you're uncomfortable with that, convert the
XSLT stuff to Java just as I converted it to Perl. But if that is too
much of a detraction for you, it's perfectly fine to use the XSLT
stuff for your task.
Frederik Ramm ## eMail frederik at remote.org ## N49°00'09" E008°23'33"
More information about the dev