[OSM-dev] [OSM] Informations about osmarender for Google SoC

80n 80n80n at gmail.com
Sun Mar 23 15:40:24 GMT 2008

On Sun, Mar 23, 2008 at 3:26 PM, Frederik Ramm <frederik at remote.org> wrote:

> Hi,
> > 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...

A demo file is a good approach.  This can contain samples of all the cases
that need to be considered.  Then as the user changes styles etc the
appearance of the rendered demo file will change.

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

I don't think the language that the Osmarender engine is implemented in
matters for this task.  The main file to focus on is the XML rules file.
This is an input for both the XSL and the Perl versions of Osmarender.

> Bye
> Frederik
> --
> Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"
> _______________________________________________
> dev mailing list
> dev at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20080323/ddc923c0/attachment.html>

More information about the dev mailing list