[OSM-dev] rendering: mad ideas
mikel_maron at yahoo.com
Wed Mar 22 15:55:01 GMT 2006
Many types of Distributed and Federated infrastructures could make a big impact on tile generation.
Embedding an OSM at Home renderer directly in the Java editor is neat, since most of the infrastructure is already present; in contrast to BOINC, which would require a lot of setup on the server, custom compilations and testing to even get started. If this ever made it into the Java editor, running the generator should be optional. I wouldn't think the code itself would be that substantial in size, but if it was so it's easy enough to serve up two different versions.
Even with distributed rendering, this leaves a lot for the OSM api to do. Presently, navigating in the editor and rerequesting OSM data for the new bounding box has a very noticeable delay. The tile server still has limited disk space to store tiles.
Nick and Richard have expressed a need copies of the OSM database, to perform intensive custom rendering. Others have offered hosting and machines, in other locales from the UCL installation. Utilising this hasn't been feasible with the current architecture, but it's worth another look.
The majority of database operations are Reads, not Writes. It's fairly simple to setup mysql slave replications, while keeping edits flowing through the single master db. These replicants could field GET api requests, and tile requests. It's sensible to restrict the "domain" of each replicant to a particular geographic area, roughly defined by a bounding box. Slippy map and editor requests would lookup the appropriate server for the wms or api request; any requests overlapping multiple areas or not served by a replicant get picked up by the master install. On the downside, Federation requires a whole lot more tinkering and setup than an adaptable distributed system.
----- Original Message ----
From: SteveC <steve at asklater.com>
To: dev at openstreetmap.org
Sent: Tuesday, March 21, 2006 3:45:32 PM
Subject: [OSM-dev] rendering: mad ideas
So there's excellent work going on XSLT and SVG wise and the main map
remains horrible and without features below level 11 or whatever it is.
Whetever happens, we're probably not going to be able to sustain on the
fly rendering and mad ideas should be considered.
Over the pond, Schuyler wrote something and put it somewhere on
mappinghacks.com about distributed WMS but I was thinking of something a
bit more limited to kick off.
Hows about a low priority thread in the applet which grabs landsat tiles
and data and renders them, shipping completed static jpegs back to the
server? Thus whilst editing, people are helping. A home version could
easily be made which people could run in the background as a screensaver
We can call it OpenStreetMap at home
It is almost trivial to write the first incantation which does nothing
more than the the current tiles (just white lines). Slightly more
difficult is the server side of logging what tiles need to be rendered
and shipping them.
Later on it can be expanded to do things like grabbing large tiles and
splitting them up and generalising itself, and as many cartographic
extensions as you like.
Why Java I hear you cry? Well, I couldn't care less what other versions
of it may be written in but the applet having it as a thread is an
attractive idea and Java runs on just about anything. We can make it run
in free VM's without too much hassle, too which nails whatever
performace problems may be perceived. Anyway, java isn't _that_ slow
Oh and Imi might help if it's in Java.
Sound like fun?
Yeah, yeah people could submit spam tiles but we can figure a way out of
SteveC steve at asklater.com http://www.asklater.com/steve/
dev mailing list
dev at openstreetmap.org
More information about the dev