[HOT] next HOT tech chat

[Heather Leson]

I'd be keen to introduce you to team brck on this once the idea is flushed
out more.

Heather

On Tue, Jul 16, 2013 at 10:39 AM, Harry Wood <mail at harrywood.co.uk> wrote:

>
>
> > So, there's a few different things you could cache.
> >
> > One is imagery/tiles. For tiles it's a well-solved problem, tile.osm.org
> > uses a bunch of squid caches and the configuration is all at
> > http://git.osm.org/chef.git/tree/HEAD:/cookbooks/tilecache
> >
>
> It would be neat if a BRCK type device could intercept requests to
> tile.openstreetmap.org while an internet connection is working, and then
> serve the same tiles from cache if the internet is down. I'm thinking of
> man-in-the-middle caching on the connection device. Is that a squid-like
> thing to do?  That type of caching may already be a generic function of
> BRCK. It would mean that if you have some tool running locally, but which
> is designed to require an internet connection for embedded maps (hitting
> tile.openstreetmap.org in the standard way) it could carry on working,
> without re-configuring tile URLs.
>
> ...but it wouldn't have all the tiles in the region. Just those which
> somebody had viewed before. To have all the tiles, the temptation is to
> request the full pyramid as a bulk tile download. That causes problems for
> the server, and is strictly disallowed on the main osm tile server, but you
> could imagine some set-up in which aid workers are allowed to bulk-download
> a pyramid of tiles from a HOT tile server before they get on a plane.
>
> Of course the smart way is to run a tile server in the field. Smart
> because it's more compact, and also because feeding in diffs is a reliable
> compact thing to do. Another "solved problem" really ...Except that the
> technology is somehow still far too complicated to give to a random
> non-technical aid worker. In fact I think even people like MapAction didn't
> get their heads around it. Rendering is still very much an OpenStreetMap
> expert skill.
>
> It think tiled vector data will be the key to lowering barriers here. You
> mentioned tiles and API data as two forms of caching, but cached *vector*
> data has huge potential. This is a bit more of a blue skies idea. But check
> out this tantalising preview from the MapBox guys:
> https://vine.co/v/b0DvTPnpPtw  That's the whole planet on USB key,
> rendering on the fly.  I think we want to get to the point where aid
> workers don't leave home without a copy of this. Then another challenge is
> allowing them to request low-bandwidth data updates when they have
> internet. Of course there are some pretty amazing mobile apps which use a
> tile vector data approach. I really love MapsWithMe, but it's closed-source
> and doesn't do low-bandwidth updates. Is AND the best open source one? I
> hope we'll see convergence on an open standard and open tools to view, and
> update vector tiles. What's the best way for HOT to push things in that
> direction?
>
> Harry Wood
>
>
>
>
>
>
>  A disadvantage is that they only cache what has been requested.
>
>
>
> I think a remote team with sporadic internet connection.
>
>
> on the topic of HOT usb stick.... https://vine.co/v/b0DvTPnpPtw <<< The
> entire word rendering on the fly!
>
>
> _______________________________________________
> HOT mailing list
> HOT at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/hot
>



-- 
Heather Leson
Director of Community Engagement
*Ushahidi*
hleson at ushahidi.com
www.ushahidi.com and https://wiki.ushahidi.com
@heatherleson / skype: heatherleson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/hot/attachments/20130716/bfb51d3c/attachment-0001.html>