[OSM-dev] rendering: mad ideas

Ben Gimpert ben at somethingmodern.com
Fri Mar 24 14:41:23 GMT 2006


On Fri, Mar 24, 2006 at 03:28:41AM -0800, Mikel Maron wrote:
> 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.

Good point.  Maybe just upload the tile at "this" zoom level, and mark
the ones higher in the hierarchy as dirty?

> - 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.

Nah, I wouldn't mess around with threads and session tracking and all
that complicated stuff.  Why shouldn't every single edit result in the
upload of a tiny image that the client has already (effectively)
rendered?  A 20k PNG for every edit is probably not a big deal,
especially if clients are good about drag-n'-drop.

> 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.

Yeah, I retract the suggestion to make the tile rendering mandatory.
Should be optional and turn-off-able, like chosing to run an OSM at Home
screensaver.

		Ben


> ----- 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