On 10/26/06, <b class="gmail_sendername">Dave</b> <<a href="mailto:osm@randomjunk.co.uk">osm@randomjunk.co.uk</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div 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. </div></blockquote><div><br>FYI Xalan used to be included in Java 1.4 but is not part of Java 1.5, it has to be dowloaded separately.<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">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><span class="sg">
<br>
Dave</span><div><span class="e" id="q_10e8474b56bf615e_2"><br>
<br>
<br>
Nick Whitelegg wrote:
<blockquote cite="http://midOF7787522D.0EBFC59B-ON80257213.003C470C-80257213.003D39EA@solent-university.ac.uk" type="cite">
<blockquote type="cite">
<pre>see my comments towards the end ;D<br> </pre>
</blockquote>
<pre> </pre>
<blockquote type="cite">
<pre>The librsvg approach looks interesting, as ideally what is needed is a<br>lightweight SVG to PNG converter (command line based and easily<br>installable without a long dependency list). Does librsvg have many<br>
dependencies?<br> </pre>
</blockquote>
<pre>Just a few ideas - not all might be 100% feasible/sensible - but thinking <br>out loud.<br><br>Apologies for following up my own post but I got an answer to this one... <br>it does seem it has quite a long list of dependencies. In the absence of a
<br>server machine powerful enough to serve SVG to clients, and browsers which <br>can render SVG nicely (the ideal solution) an automated, distributed <br>rendering process sounds ideal. However participants ideally shouldn't
<br>need to download a lot of dependencies to run it. Maybe (and this needs <br>more research) a Java solution (xalan/batik) would be better, as once you <br>have the JRE installed it's easy to run Java stuff. Also it would be easy
<br>on both Linux and Windows. *However* I haven't experimented with batik so <br>am not sure how good it is at rendering tiles. <br><br>The other approach that could be taken is something of a departure and <br>wouldn't go via SVG at all. Some GUI toolkits (
e.g. qt) apparently do nice <br>rendering. Even the JOSM mappaint rendering with a few tweaks could <br>perhaps be good enough. So one option could be a standalone OSM browser <br>(based on JOSM???) which downloads the data, renders it then uploads it to
<br>a central server.<br><br>Comments?<br><br>Nick<br><br><br><br><br>_______________________________________________<br>dev mailing list<br><a href="mailto:dev@openstreetmap.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
dev@openstreetmap.org</a>
<a href="http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev</a>
</pre>
</blockquote>
</span></div></div>
<br>_______________________________________________<br>dev mailing list<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:dev@openstreetmap.org">dev@openstreetmap.org</a><br><a onclick="return top.js.OpenExtLink(window,event,this)" href="http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev" target="_blank">
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev</a><br><br><br></blockquote></div><br>