Why not the OSM wiki itself?
It seems to me that it's the place to store shared knowledge about OSM :)
On 07/17/2013 09:50 AM, Mikel Maron wrote:
Looks perfect addition to LearnOSM
* Mikel Maron * +14152835207 @mikel s:mikelmaron
------------------------------------------------------------------------
*From:* Nama Budhathoki <[email protected]>
*To:* Vivien Deparday <[email protected]>
*Cc:* "[email protected]" <[email protected]>
*Sent:* Wednesday, July 17, 2013 9:48 AM
*Subject:* Re: [HOT] next HOT tech chat
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] <mailto:[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] <mailto:[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]
<mailto:[email protected]>>
*À :* Paul Norman <[email protected]
<mailto:[email protected]>>; 'Yantisa Akhadi'
<[email protected] <mailto:[email protected]>>; 'Mikel
Maron' <[email protected] <mailto:[email protected]>>
*Cc :* "[email protected]
<mailto:[email protected]>" <[email protected]
<mailto:[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 <http://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
<http://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 <http://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
<https://vine.co/v/b0DvTPnpPtw%C2%A0>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
<https://vine.co/v/b0DvTPnpPtw%C2%A0><<< The entire word
rendering on the fly!
_______________________________________________
HOT mailing list
[email protected] <mailto:[email protected]>
http://lists.openstreetmap.org/listinfo/hot
_______________________________________________
HOT mailing list
[email protected] <mailto:[email protected]>
http://lists.openstreetmap.org/listinfo/hot
_______________________________________________
HOT mailing list
[email protected] <mailto:[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 <http://budhathoki.wordpress.com/>
Skype: namabudhathoki
Twitter: https://twitter.com/Nama_Budhathoki/
_______________________________________________
HOT mailing list
[email protected] <mailto:[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
