osdir.com
mailing list archive

Subject: Re: Cache the whole world. - msg#00043

List: gis.openstreetmap.devel

Date: Prev Next Index Thread: Prev Next Index
Erik Johansson wrote:

> Yes squid has an API and the track number is #121 as you discovered. ;-)

(I'm moving this thread back to the dev mailing list, if you don't
mind.)

Yes, I was fooled at first that the title talks about new tracks
being added. This applies to edit mode tiles (with yellow marks).
But the body text of ticket 121 also mentions view mode tiles
(with white roads).

(I personally believe that tracks should be drawn as lines, not as
dots or crosses, and that this should be done by the edit applet
and not by the tile server. The edit applet also needs a way to
color different tracks differently, or only draw select tracks.
This would remove the need for edit mode tiles all together.)

> The biggest problem is that no one has written a "this lat/lon
> belongs to these tiles" tool.

This computation surely is part of both the viewer and the edit
applet. But with tile URLs ending in e.g.
BBOX=14.23818,57.84534447446815,14.282125,57.857036747911096
one might raise questions about rounding errors. There is no
point in invalidating the cache for a URL where the last decimal
differs, because that is a different URL. Perhaps a %.5f format
should be used for the URLs? Or something even smarter?

> The other problem with invalidating is that there are lots of zoom
> levels. Why not disabling the Landsat for zoom 16,17,18, or completly?
> I'm not even sure you need landsat for zoom 15.
>
> Do we really need zoom level 16,17,18? Zoom 16 is a about the same as
> the best from other maping services in Sweden. E.g. moving half a

There are cases where zoom=16 is more useful than zoom=15 in the
edit applet, e.g. where a bike path runs close to a road. But I
have never found any use for zoom=17 or 18.

Editing is only allowed from zoom=14 and up, and we currently draw
roads only from zoom=11 and up, so there aren't so many levels.
But one would have to consider that some map updates will touch
more than one tile at each zoom level. I have no idea if the
Squid API allows more than one URL to be invalidated in each call.
Perhaps one can invalidate the cache for entire areas at once,
e.g. by specifying wildcard patterns for the tile URLs:
BBOX=14.3*,57.4*,14.3*,57.5* ? That would take care of all zoom
levels too. Does anybody know? Google hits indicate that "Squid
wildcard purge" is a much desired functionality.


--
Lars Aronsson (lars@xxxxxxxxxxx)
Aronsson Datateknik - http://aronsson.se


Was this page helpful?
Yes No
Thread at a glance:

Previous Message by Date: click to view message preview

Cache the whole world.

Hi moved to dev again.. > The biggest problem is that no one has written a "this lat/lon belongs > to these tiles" tool. I don't understand the problem... Aren't the tiles given by lat/lon boundaries? Almost every WMS map server take this as url parameter (in fact, OSM seems to be the only I've seen using something like center+zoom). Ciao, Imi.

Next Message by Date: click to view message preview

Re: Cache the whole world.

Tiles are requested by geographic extent .. look at the BBOX parameter on any tile url. ----- Original Message ---- From: Immanuel Scholz <immanuel.scholz@xxxxxx> To: openstreetmap-dev@xxxxxxxxxxxx Sent: Thursday, February 16, 2006 8:54:10 AM Subject: [Openstreetmap-dev] Cache the whole world. Hi moved to dev again.. > The biggest problem is that no one has written a "this lat/lon belongs > to these tiles" tool. I don't understand the problem... Aren't the tiles given by lat/lon boundaries? Almost every WMS map server take this as url parameter (in fact, OSM seems to be the only I've seen using something like center+zoom). Ciao, Imi. _______________________________________________ Openstreetmap-dev mailing list Openstreetmap-dev@xxxxxxxxxxxx http://bat.vr.ucl.ac.uk/cgi-bin/mailman/listinfo/openstreetmap-dev

Previous Message by Thread: click to view message preview

Re: Cache the whole world.

Tiles are requested by geographic extent .. look at the BBOX parameter on any tile url. ----- Original Message ---- From: Immanuel Scholz <immanuel.scholz@xxxxxx> To: openstreetmap-dev@xxxxxxxxxxxx Sent: Thursday, February 16, 2006 8:54:10 AM Subject: [Openstreetmap-dev] Cache the whole world. Hi moved to dev again.. > The biggest problem is that no one has written a "this lat/lon belongs > to these tiles" tool. I don't understand the problem... Aren't the tiles given by lat/lon boundaries? Almost every WMS map server take this as url parameter (in fact, OSM seems to be the only I've seen using something like center+zoom). Ciao, Imi. _______________________________________________ Openstreetmap-dev mailing list Openstreetmap-dev@xxxxxxxxxxxx http://bat.vr.ucl.ac.uk/cgi-bin/mailman/listinfo/openstreetmap-dev

Next Message by Thread: click to view message preview

Re: Cache the whole world.

> Erik Johansson wrote: > >> Yes squid has an API and the track number is #121 as you discovered. ;-) > > (I'm moving this thread back to the dev mailing list, if you don't > mind.) > > Yes, I was fooled at first that the title talks about new tracks > being added. This applies to edit mode tiles (with yellow marks). > But the body text of ticket 121 also mentions view mode tiles > (with white roads). > > (I personally believe that tracks should be drawn as lines, not as > dots or crosses, and that this should be done by the edit applet > and not by the tile server. The edit applet also needs a way to > color different tracks differently, or only draw select tracks. > This would remove the need for edit mode tiles all together.) > We used to do this... Remember that we used to do it and it's difficult to draw that many lines/points at interactive rates, and it's also quite a heavy bandwidth hit. It's my personal OpenStreetMap flip-flop tracker ticket #312 ;) If you do it server side, you can cache it. If you cache it, it's inflexible and outdated. If you do it client side, then you have to move a lot of data, and so the API needs to be more flexible. I imagine we'll do a combination of both (as disk space allows, cache more variations of transparent-tiles-with-gps) because the client-side experience will be the same across all areas. Without a server-side gps image, the client experience with be very different in cities to countryside. That said, moving GPS track drawing to the applet is desirable so that the tracks can be manipulated and redrawn (by age, contributor, speed, etc) and drawn with lines/dots/stars/rainbows as you wish, but needs to be generalised enough to work for areas with lots of tracks as well as areas with just one. Perhaps the API needs to be modified to take a couple of parameters as well as a bounding box - an initial query could be made to see what things are available for a given area and then things could be returned on request. That way there's the possiblity of cacheing older datasets. Tom. PS this reply is a combination of two things, so I might repeat myself a bit, sorry.
Sign up for updates to this mailing list. email:
Loading Comments...
Home | News | Patents | Sitemap | FAQ | advertise

Advertising by