<div dir="ltr"><div>Thanks for the links. Most of this information is also available at [1]. </div><div><br></div><div>I am preparing a simple plugin to load these layers as raster layers, will keep you updated on this.</div>
<div><br></div><div>[1] <a href="http://www.gdal.org/frmt_wms.html">http://www.gdal.org/frmt_wms.html</a></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 7, 2014 at 2:32 PM, kimaidou <span dir="ltr"><<a href="mailto:kimaidou@gmail.com" target="_blank">kimaidou@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi List<br>
<br>
For the record, here is an old blog post about using gdal driver to<br>
use external layers such as OSM<br>
<a href="http://www.3liz.com/blog/rldhont/index.php?post/2012/07/17/OpenStreetMap-Tiles-in-QGIS" target="_blank">http://www.3liz.com/blog/rldhont/index.php?post/2012/07/17/OpenStreetMap-Tiles-in-QGIS</a><br>
<br>
The problem is that with this method, it seems GDAL does not alway use<br>
the right tiles for the rigth scale. There must be an additionnal<br>
parameter wich can control this behaviour.<br>
<br>
I totally agree with the concerns about licence violation. Easing the<br>
use of Google layers is kind of encouraging people to use it, for<br>
example for digitization purpose. Users must be warned about the terms<br>
of service.<br>
<br>
Michael<br>
<br>
PS : someone has gathered a list of XML for GDAL for some providers :<br>
<a href="http://libreavous.teledetection.fr/geomatique/28-sig/58-afficher-des-couches-issues-de-services-en-ligne-dans-un-sig" target="_blank">http://libreavous.teledetection.fr/geomatique/28-sig/58-afficher-des-couches-issues-de-services-en-ligne-dans-un-sig</a><br>
<br>
Click on the button called "Fichiers de configuration ...."<br>
Michael<br>
<br>
2014-04-07 16:48 UTC+02:00, Etienne Tourigny <<a href="mailto:etourigny.dev@gmail.com">etourigny.dev@gmail.com</a>>:<br>
<div class="HOEnZb"><div class="h5">> Since the OpenLayers plugin does not (currently) work with master, perhaps<br>
> we can replace it with TMS-based layers, either through a plugin or as a<br>
> native (GDAL-based) provider?<br>
><br>
> Is there anything in OpenLayers plugin that could not work with GDAL TMS<br>
> mini-driver [1] ?<br>
><br>
> [1] <a href="http://www.gdal.org/frmt_wms.html" target="_blank">http://www.gdal.org/frmt_wms.html</a><br>
><br>
><br>
> On Mon, Apr 7, 2014 at 11:42 AM, Etienne Tourigny<br>
> <<a href="mailto:etourigny.dev@gmail.com">etourigny.dev@gmail.com</a>>wrote:<br>
><br>
>> Since the OpenLayers plugin does not (currently) work with master,<br>
>> perhaps<br>
>> we can replace it with TMS-based layers, wither through a plugin or as a<br>
>> native (GDAL-based) provider?<br>
>><br>
>> Is there anything in OpenLayers that could not work with GDAL TMS<br>
>> mini-driver [1] ?<br>
>><br>
>><br>
>><br>
>> On Mon, Apr 7, 2014 at 7:22 AM, Vincent Picavet<br>
>> <<a href="mailto:vincent.ml@oslandia.com">vincent.ml@oslandia.com</a>>wrote:<br>
>><br>
>>> Hello,<br>
>>><br>
>>> Le lundi 7 avril 2014 12:05:05, Nyall Dawson a écrit :<br>
>>> > On 7 April 2014 18:15, Vincent Picavet <<a href="mailto:vincent.ml@oslandia.com">vincent.ml@oslandia.com</a>><br>
>>> > wrote:<br>
>>> > > A good solution though would be to remove google layers and only use<br>
>>> OSM<br>
>>> > > and mapbox layers, which begin to be on par in terms of quality.<br>
>>> ><br>
>>> > I'm pretty sure this is against MapBox's terms of service too, unless<br>
>>> > users were made to sign up for a MapBox account and had to add their<br>
>>> > individual API key to QGIS to unlock MapBox layers:<br>
>>> > "You must have a Mapbox account to use Mapbox. You are required to<br>
>>> > register for an account before using the Service. Each request to the<br>
>>> > API must include your account's unique API identifier. Unauthorized<br>
>>> > use of any API identifier is prohibited." [1]<br>
>>><br>
>>> Right, I had not read this through. It would probably be much easier to<br>
>>> get a<br>
>>> specific authorization from MapBox than from Google though, given their<br>
>>> open-<br>
>>> source orientation.<br>
>>><br>
>>> > > Or let the user a<br>
>>> > > deliberate way to add google layers (indicating a URL or something<br>
>>> like<br>
>>> > > this), warning him about the licence.<br>
>>> ><br>
>>> > Hmm... while this may be a workable solution to the licensing issue,<br>
>>> > wouldn't it be a step back in functionality anyway? We'd be trading<br>
>>> > having a good, working off-the-shelf third-party plugin for a crippled<br>
>>> > core version which takes user intervention to unlock the same<br>
>>> > features.<br>
>>><br>
>>> In any case, there are quite a lot of OSM based layers which can be used<br>
>>> (HOT,<br>
>>> OSM.fr, OpenCycleMap...). We can still enhance the plugin with those.<br>
>>> It would lack an aerial imagery layer though.<br>
>>><br>
>>> > I'm totally for adding essential plugins to core (or merging the<br>
>>> > functionality with reimplemented c++ versions), but I honestly don't<br>
>>> > know if it's workable to do this for the OpenLayers plugin.<br>
>>><br>
>>> Right, if we remove everything from the plugin except the TMS YXZ<br>
>>> layers,<br>
>>> we<br>
>>> could also just have a better ergonomy for opening this kind of layers<br>
>>> through<br>
>>> GDAL, and have a predefined list of layers accessible on internet (even<br>
>>> auto-<br>
>>> updatable by downloading the list).<br>
>>><br>
>>> Vincent<br>
>>> _______________________________________________<br>
>>> Qgis-developer mailing list<br>
>>> <a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
>>> <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
>>><br>
>><br>
>><br>
><br>
</div></div></blockquote></div><br></div>