<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
I've been thinking about this.<br>
Dependency wise Java is probably the easiest solution as all the tools
are probably already out there as Java, so it's one download of a few
MB. Xalan is included in Java 1.5, so you don't even have to download
that. The rendering part of batik isn't that big; I have no idea what
quality it's output is in general, but the demos look quite nice.
There's always Java2D for rendering stuff too, that can look quite nice.<br>
<br>
Making a tile server work efficiently is another issue though.
Prerendering the entire planet isn't really an option, as you'd have to
do it constantly and there's a lot of it, so render on request with
caching is needed. The problem here is that squid caching isn't really
adequate: a tile remains good forever until the OSM data changes --
more intelligent caching is needed.<br>
<br>
What I was thinking was ave a java servlet (or whatever) which checks
the tile state on request, vends the current rendering if it exists and
hasn't been marked invalid, and otherwise sends off a request to get
the tile rendered. It can wait for the result, or on a timeout return
the old version, or an apology marked nocache.<br>
The tile renderer can be a separate process/machine and be responsible
for farming out the render, or do it itself. You could use some RMI (or
again whatever) to allow client renderers to register and get given
work. This process can periodically examine the RSS feed of changes and
mark tiles invalid if a change occurs. These invalid tiles can be
queued as low priority render requests for updating, whereas tile
request from the UI are high priority.<br>
I'll maybe try to get this clearer, some pseudo code maybe.<br>
<br>
Does anybody have any thoughts on this?<br>
<br>
As for the actual rendering, there's a couple of things about
osmarenderer:<br>
a) The label plotting isn't very good. Labels are often too big/too
small, they follow the road path exactly even when segments don't order
properly, they go upside down if the way is defined right to left, but
they should always be left to right (in English at least), they go
round corners in ways when they could easily have been plotted on a
straight bit, and they don't merge when multiple ways have the same
name (look at dual carriageway primary roads where the carriageways are
close together for how nasty this can be). What worries me here is
whether it's actually possible to do anything about any of this in
XSLT? I don't know too much about XSLT (other than some basics), but it
doesn't strike me as being very easy to implement label heuristics in.<br>
b) incomplete ways aren't plotted (at least they're not when I do View
-> Osmarender in JOSM). This would make tiling very difficult.<br>
Are these things fixable?<br>
I do like the zoomed out osmarender maps though, I think they look
quite cool.<br>
<br>
Dave<br>
<br>
<br>
Nick Whitelegg wrote:
<blockquote
cite="midOF7787522D.0EBFC59B-ON80257213.003C470C-80257213.003D39EA@solent-university.ac.uk"
type="cite">
<blockquote type="cite">
<pre wrap="">see my comments towards the end ;D
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
<blockquote type="cite">
<pre wrap="">The librsvg approach looks interesting, as ideally what is needed is a
lightweight SVG to PNG converter (command line based and easily
installable without a long dependency list). Does librsvg have many
dependencies?
</pre>
</blockquote>
<pre wrap=""><!---->
Just a few ideas - not all might be 100% feasible/sensible - but thinking
out loud.
Apologies for following up my own post but I got an answer to this one...
it does seem it has quite a long list of dependencies. In the absence of a
server machine powerful enough to serve SVG to clients, and browsers which
can render SVG nicely (the ideal solution) an automated, distributed
rendering process sounds ideal. However participants ideally shouldn't
need to download a lot of dependencies to run it. Maybe (and this needs
more research) a Java solution (xalan/batik) would be better, as once you
have the JRE installed it's easy to run Java stuff. Also it would be easy
on both Linux and Windows. *However* I haven't experimented with batik so
am not sure how good it is at rendering tiles.
The other approach that could be taken is something of a departure and
wouldn't go via SVG at all. Some GUI toolkits (e.g. qt) apparently do nice
rendering. Even the JOSM mappaint rendering with a few tweaks could
perhaps be good enough. So one option could be a standalone OSM browser
(based on JOSM???) which downloads the data, renders it then uploads it to
a central server.
Comments?
Nick
_______________________________________________
dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dev@openstreetmap.org">dev@openstreetmap.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev">http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev</a>
</pre>
</blockquote>
</body>
</html>