FW: FW: [Openstreetmap] Recent improvements to the editing applet
matt at matt-amos.uklinux.net
Wed Jan 4 18:02:07 GMT 2006
On Monday 02 January 2006 03:29, Robert Scott wrote:
> On Monday 02 Jan 2006 02:52, David Sheldon wrote:
> > Unfortunately this means that when you upload a new route you
> > cannot edit it/add roads until the tiles have timed out and the
> > yellow dots appear. My process is to upload a track, then draw on
> > roads. This is now not as easy as before as you don't necessarily
> > get the track on the editor straight away.
> > David
> Indeed; I would be able to edit a lot faster if I didn't have to
> stop and wait a few hours for another clump of my breadcrumbs to
> appear. Most of the time breadcrumb trails disappear in the halfway
> down a road (one tile is cached, another isn't) and I just can't go
> any further.
would it be better to request three tiles, e.g:
1) the opaque "background" tile from landsat
2) the breadcrumbs on a transparent PNG
3) the roads on a transparent PNG
that way the client could deliberately request (2) and (3) with a
special form of URL (maybe appending ?cache=no or something) which
would have the side effect of invalidating the server cache for just
an alternative idea is that the client could re-render the tiles
itself (and possibly upload them) so you'd always have the latest
information on your screen.
anybody fancy implementing a REST-ful API for the tiles? something
like http://www.openstreetmap.org/api/0.2/tile/4/2,3 gives the tile
x=2, y=3 for zoom level 4. then you could PUT the rendered tiles
there and have the server backend figure out how to invalidate the
> It's also particularly difficult if you're trying to do an area you
> don't know too well. If you're able to work on it while the trip is
> still fresh in your memory, it really helps. Especially with road
> But of course I understand how it's a tradeoff with performance
> (which seems to have stepped up in the last ~24 hours).
this is especially difficult when there is a bandwidth/cpu trade-off,
as it is sometimes not clear how server performance is scaling with
I/O or compute.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 190 bytes
Desc: not available
More information about the talk