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 <[email protected]> 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 > [email protected] > http://lists.openstreetmap.org/listinfo/hot > -- Heather Leson Director of Community Engagement *Ushahidi* [email protected] www.ushahidi.com and https://wiki.ushahidi.com @heatherleson / skype: heatherleson
_______________________________________________ HOT mailing list [email protected] http://lists.openstreetmap.org/listinfo/hot
