HOT is presently deploying four field teams in Burkina Faso, Chad, Togo and
Senegal. As it is often the case in these countries, internet bandwith is a
significant problem. We are already experimenting problems in Togo.
What type of "not too techy" solution could be implemented immediately to
respond to internet communication problems of a classroom with up to 20
computers ?
As we said yesterday at the Tech WG, the most significative improvement for
field teams would probably be to cache the Imagery.
What short term solution would you propose for this?
Pierre
________________________________
De : Harry Wood <[email protected]>
À : Paul Norman <[email protected]>; 'Yantisa Akhadi' <[email protected]>;
'Mikel Maron' <[email protected]>
Cc : "[email protected]" <[email protected]>
Envoyé le : Mardi 16 juillet 2013 10h39
Objet : Re: [HOT] next HOT tech chat
> 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
_______________________________________________
HOT mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/hot
