I was not aware of this particular restriction. There is always more to learn! Thanks for letting us know about it.
The document has already been removed from the Dropbox, and we will not be documenting it in Wiki or in LearnOSM. Nama On Wed, Jul 17, 2013 at 5:11 PM, Fran Boon <francisb...@gmail.com> wrote: > Whilst it is against their Terms of Service, I agree. > However, I think this issue is important enough for us to campaign > Bing to let us have an exception for this kind of case. > > As far as I understand the documentation is the same no matter what > the imagery source? > - so we can document it for other sources without these restrictions > and then say 'Whilst the same principle could be applied to Bing > imagery, this is currently against their Terms of Service' > This allows people to make their own individual judgement calls on > whether their humanitarian imperatives outweigh a terms of service, > without incriminating HOT in any way... > > F > > On 17 July 2013 12:00, Kate Chapman <k...@maploser.com> wrote: > > Hi All, > > > > Caching the Bing tiles and then sharing them between computers is > > against Bing's Terms of Service. HOT should not be teaching people how > > to do this and we should not be documenting it on the wiki or > > LearnOSM. Bing is nice enough to let us use their imagery, it is not a > > right of OSM, it is more a privilege. I think we should respect their > > legal restrictions and not potentially spoil this great deal (Remember > > when we didn't have Bing imagery?) for everyone. > > > > -Kate > > > > On Wed, Jul 17, 2013 at 2:24 AM, Yohan Boniface > > <yohan.bonif...@hotosm.org> wrote: > >> 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 <namabudhath...@gmail.com> > >>> *To:* Vivien Deparday <vivien.depar...@gmail.com> > >>> *Cc:* "hot@openstreetmap.org" <hot@openstreetmap.org> > >>> *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 > >>> <vivien.depar...@gmail.com <mailto:vivien.depar...@gmail.com>> > 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 > >>> <pierz...@yahoo.fr <mailto:pierz...@yahoo.fr>> 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 <m...@harrywood.co.uk > >>> <mailto:m...@harrywood.co.uk>> > >>> *À :* Paul Norman <penor...@mac.com > >>> <mailto:penor...@mac.com>>; 'Yantisa Akhadi' > >>> <yant...@gmail.com <mailto:yant...@gmail.com>>; 'Mikel > >>> Maron' <mikel_ma...@yahoo.com <mailto: > mikel_ma...@yahoo.com>> > >>> *Cc :* "hot@openstreetmap.org > >>> <mailto:hot@openstreetmap.org>" <hot@openstreetmap.org > >>> <mailto:hot@openstreetmap.org>> > >>> *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 > >>> HOT@openstreetmap.org <mailto:HOT@openstreetmap.org> > >>> > >>> http://lists.openstreetmap.org/listinfo/hot > >>> > >>> > >>> _______________________________________________ > >>> HOT mailing list > >>> HOT@openstreetmap.org <mailto:HOT@openstreetmap.org> > >>> > >>> http://lists.openstreetmap.org/listinfo/hot > >>> > >>> > >>> > >>> _______________________________________________ > >>> HOT mailing list > >>> HOT@openstreetmap.org <mailto:HOT@openstreetmap.org> > >>> > >>> 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 > >>> HOT@openstreetmap.org <mailto:HOT@openstreetmap.org> > >>> > >>> http://lists.openstreetmap.org/listinfo/hot > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> HOT mailing list > >>> HOT@openstreetmap.org > >>> http://lists.openstreetmap.org/listinfo/hot > >>> > >> > >> _______________________________________________ > >> HOT mailing list > >> HOT@openstreetmap.org > >> http://lists.openstreetmap.org/listinfo/hot > > > > _______________________________________________ > > HOT mailing list > > HOT@openstreetmap.org > > http://lists.openstreetmap.org/listinfo/hot > > _______________________________________________ > HOT mailing list > HOT@openstreetmap.org > http://lists.openstreetmap.org/listinfo/hot >
_______________________________________________ HOT mailing list HOT@openstreetmap.org http://lists.openstreetmap.org/listinfo/hot
