[OSM-dev] Nestoria Tiles Write Up

[Dave]

I've been thinking about this.
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.

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.

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.
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.
I'll maybe try to get this clearer, some pseudo code maybe.

Does anybody have any thoughts on this?

As for the actual rendering, there's a couple of things about osmarenderer:
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.
b) incomplete ways aren't plotted (at least they're not when I do View 
-> Osmarender in JOSM). This would make tiling very difficult.
Are these things fixable?
I do like the zoomed out osmarender maps though, I think they look quite 
cool.

Dave


Nick Whitelegg wrote:
>> see my comments towards the end ;D
>>     
>
>   
>> 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?
>>     
>
> 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
> 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/20061026/7db90acc/attachment.html>