Hi Pierre, Vivian, and others, We frequently experience the same problem here in Nepal due to low Internet bandwidth. We have developed a guide to use offline imagery in JOSM. Here is the link:
https://www.dropbox.com/s/3wwpgorjubmp0nc/Using%20offline%20Bing%20Imagery%20in%20JOSM.pdf Nama On Wed, Jul 17, 2013 at 10:31 AM, Vivien Deparday <[email protected] > wrote: > Hi Pierre, > if you are doing your workshop with JOSM, a short term and low-tech > solution is to use the caching feature of JOSM. As Paul mentioned, you > have to check the terms of use of the imagery you are using to make sure > you are allowed to cache it. You can find the feature in JOSM in > Edit->Preferences->WMS/TMS > tab->Settings. There is a path at the bottom. When you browse around an > area, the tiles are cached in this folder, once you have covered the area > you want (for each zoom level) then you can copy this folder to the other > computers in the right place (check the path in the preferences or you can > set the path to where you copied the files). Also, I don't remember exactly > but you may also need to do what is written under the section "Caching" on > this page http://josm.openstreetmap.de/wiki/Help/Menu/Imagery to make > sure the cache isn't deleted. > > Cheers, > > Vivien > > > On Tue, Jul 16, 2013 at 12:31 PM, Pierre Béland <[email protected]> wrote: > >> 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 >> >> > > _______________________________________________ > HOT mailing list > [email protected] > http://lists.openstreetmap.org/listinfo/hot > > -- ________________________________________________________________________ Nama R. Budhathoki, PhD Nepal Lead The World Bank's Open Data for Resilience Initiative (OpenDRI) *Web: http://budhathoki.wordpress.com Skype: namabudhathoki Twitter: https://twitter.com/Nama_Budhathoki*
_______________________________________________ HOT mailing list [email protected] http://lists.openstreetmap.org/listinfo/hot
