[OSM-dev] rendering: mad ideas

Ben Gimpert ben at somethingmodern.com
Fri Mar 24 10:47:38 GMT 2006


Mikel's replication suggestions are excellent, but complex.

Maybe an interim solution, assuming most edits are done with the online
applet editor.  The server should deny any that does not also come with
a rendered version of the "changed" tile attached.  Said tiled is
immediately and cheaply cached by the server.  Less problem with
conflicts, since the newest always wins.  And almost trivial to
implement, since the applet is already rendering this stuff.  Later
demand all editors do this.

Bring on the Sahara desert spam...

		Ben


On Wed, Mar 22, 2006 at 07:55:01AM -0800, Mikel Maron wrote:
> 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.
> 
> -Mikel
> 
> ----- 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
> 
> Hi
> 
> 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
> or something.
> 
> 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
> these days.
> 
> 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
> that. Right?
> 
> have fun,
> 
> SteveC steve at asklater.com http://www.asklater.com/steve/
> 
> _______________________________________________
> dev mailing list
> dev at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
> 
> 
> 
> 
> _______________________________________________
> dev mailing list
> dev at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev




More information about the dev mailing list