[OSM-dev] Nestoria Tiles Write Up

[Etienne]

On 10/26/06, Dave <osm at randomjunk.co.uk> wrote:
>
>  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.
>

FYI Xalan used to be included in Java 1.4 but is not part of Java 1.5, it
has to be dowloaded separately.


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.orghttp://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
>
>
> _______________________________________________
> 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/c0bed433/attachment.html>