[OSM-dev] rendering: mad ideas

Mikel Maron mikel_maron at yahoo.com
Fri Mar 24 11:28:41 GMT 2006


I like this idea, but  there are a few complexities here as well

- It's not just a single tile, but a pyramid of tiles at different zoom levels. An way edit in any particular area could require a large number of renders.

- Ideally the tiles would be transmitted at the completion of the edit session .. wouldn't want every single edit resulting in a PNG render and upload. With the applet, we never know when the session is completed, since the editor can simply close the browser window. This leaves the option of rendering and transmitting periodically, every minute perhaps.

I don't think we want enforce rendering of tiles. If it's implemented correctly, it shouldn't be much of a resource drain at all on desktop cpus, but there's the possibility of other devices or platforms. For example, a Flash based editor would not be able to produce and transmit image files. If the idea proves useful, then editor developers, where it's reasonable, would likely be happy to implement this to benefit the whole platform.


Aside, any stats on editor usage (% of edits / editor)?

----- Original Message ----
From: Ben Gimpert <ben at somethingmodern.com>
To: dev at openstreetmap.org
Sent: Friday, March 24, 2006 10:51:43 AM
Subject: Re: [OSM-dev] rendering: mad ideas

Let's try that again in English:

Maybe implement an interim solution that assumes most changes are made
with the online applet editor.  The server should deny any edit that
does not also come with an attached, rendered version of the "changed"
tile (a PNG).  The uploaded tile image is immediately and cheaply cached
by the server.  Fewer problems 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.


On Fri, Mar 24, 2006 at 10:47:38AM +0000, Ben Gimpert wrote:
> 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
> 
> _______________________________________________
> 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