FW: FW: [Openstreetmap] Recent improvements to the editing applet

Matt Amos 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 
those tiles?

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

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

cya,

matt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20060104/e9afc8cd/attachment.pgp>


More information about the talk mailing list