[Qgis-developer] Future of OpenLayers plugin - time to deprecate?
Tim Sutton
tim at qgis.org
Wed Jun 15 15:06:11 PDT 2016
Hi Pirmin
> On 15 Jun 2016, at 18:58, Pirmin Kalberer <pi_ml at sourcepole.com> wrote:
>
> Hi all,
>
> Am Mittwoch, 15. Juni 2016, 08.20:13 schrieb Richard Duivenvoorde:
>> Maybe first discuss with Author (in cc)?
>
> Thanks Richard. Today was the 7th annual Swiss QGIS User meeting and therefore
> no time to answer to this second shit storm wave earlier.
>
> First some history for QGIS newbies:
> The OpenLayers plugin was presented at the first QGIS User meeting six years
> ago [1]. It was built to integrate Google Maps layers using the Google API via
> OpenLayers. At this time only the illegal (but well known) way using a GDAL
> VRT supported this functionality. In the meantime there have been at least
> three plugins reimplementing this illegal TMS access method, the latest (and
> best) is QuickMapServices. The OpenLayers plugin got the first major breakage
> with the QGIS 2.0 API change. The multithreaded rendering in QGIS 2.4 caused a
> complete rewrite of the plugin. Between and after that other QGIS or Google
> Maps changes have broken the OpenLayers plugin from time to time and it was a
> matter of course that we "fix" it to adapt these (usually paid) changes.
>
> I personally don't think that the name of this or another plugin is the main
> reason for more than 700'000 downloads of the OpenLayers plugin. I know of
> quite a few users staying with old QGIS version (even 1.x) just to be able to
> display and print Google Maps base layers. For some of them the plugin was
> important enough, to pay a few hundred Swiss Francs for another "bug fix".
> Apart of this, OpenLayers was always done in my limited spare time at home or
> at hackfests (travelling sponsored by Sourcepole). Even when I pointed at a
> possible breakages of PluginLayers, like before merging the map rotation
> feature, it seemed never to have any priority to test a change with the OL
> plugin or even preventing to break it. This attitude and the destructive
> Trump-syle tone with the +1 frency in this community mailing list are
> definitely not the motivation I would need for another bug fix. And regarding
> the reputation of QGIS, I find promoting a plugin for doing illegal things
> worse than not fixing printing problems.
>
> Enough of getting my frustration out - I have also a constructive proposal:
> Please pass a customRenderFlag during composer rendering to give PluginLayers
> a chance to handle this case without adventurous workarounds (and besides make
> it possible to fix WMTS printing with more than 90dpi's). I would then at least
> turn off OL layers and display a message.
I’m wondering what the first storm was? The OpenLayers Plugin is a great tool for QGIS and I agree we could have approached this discussion more sensitively - e.g. by first approaching you and Maxim and other devs building similar tools to look for a way to reduce duplication of effort and solve the issues that users experience with printing etc. So please do accept our apologies.
I do think it is worth discussing this though because we want to try to tidy up the plugin repository and make things clearer for users (for example by not having multiple plugins which ostensibly do the same thing). In the situation where we do have multiple plugins which do the same or similar things, then it would be nice to a) encourage the developers to work together on one version if possible and b) make it easier for the user to figure out which is the best one to install.
Specifically with reference to the legalities, is it really the case that OpenLayers plugin is on firm legal footing and the others are not?
I’m reading here:
https://developers.google.com/maps/faq#getting-started
and here:
https://developers.google.com/maps/terms
Things that may apply here:
• "No access to APIs or Content except through the Service. You will not access the Maps API(s) or the Content except through the Service. For example, you must not access map tiles or imagery through interfaces or channels (including undocumented Google interfaces) other than the Maps API(s)."
So my understanding for this is: OpenLayers Plugin uses the API so its fine, TMS wrappers in GDAL do not so it probably contravenes the license.
• "No use of Content with a non-Google map. You must not use the Content in a Maps API Implementation that contains a non-Google map."
This is a bit harder as it seems to impact all plugins using Google Maps - it pretty much excludes any typical use case a QGIS user might have - combining google maps as a backdrop layer with your own data? Or do I interpret this incorrectly?
But yes, I agree with you that having plugins which do illegal things in our repo is not good. Admittedly QuickMapServices does not ship with the potentially illegal services out of the box, but it does make it very easy to add them. @Paolo it would probably be good to add a clause to the plugin upload policy page indicating that plugins should not do illegal things (though this itself is subject to regional interpretation).
We also have the case that we get many reports from people trying to print with OpenLayers plugins and having problems. In our context in South Africa, users with slow internet often get map prints with missing tiles when using OpenLayers plugin. That kind of leaves people with a choice between ‘be legal and don’t print’ and ‘be illegal and you can print’. That doesn’t seem to be an optimal set of choices either. I am not sure if your proposed solution above will address the ‘holes in print maps’ issue?
Again my apology for my participation in the ‘+1 frenzy’ but I do think it is good to try to find a way to remove duplication of effort, support only legal plugins and give users an experience where they can reliably print their map compositions. So I do think this is a discussion worth having but just approached in a more constructive way ...
Regards
Tim
>
> Regards
> Pirmin
>
> --
> Pirmin Kalberer - @PirminKalberer
> Sourcepole - http://www.sourcepole.com
>
> [1] http://blog.sourcepole.com/2010/04/23/folien-qgis-user-meeting-bern/
>
>>
>> As the maintainers used to put a lot of work into the plugin. In my view
>> it is not very polite to retract/depricate a plugin.
>>
>> Best I think would be (if Pirmin and Matthias are ok with it), to
>> temporarily depricate it, AND show with a message in the description
>> that there is a working alternative.
>> This would give SP time to fix, without time pressure.
>>
>> Unless off course the Plugin is being depricated by the authors too....
>> Then it could just be removed.
>>
>> Maybe we should have a mechanisme in the plugins to do such messages?
>> For example: "This plugins is not working properly because.... (eg
>> Webkit/Debian)" or "This plugin is deprecated in favour of ..."?
>>
>> Regards,
>>
>> Richard Duivenvoorde
>>
>> On 14-06-16 23:04, Paolo Cavallini wrote:
>>> Makes sense to me. Going to deprecate it tomorrow if nobody objects.
>>> Thanks Nyall.
>>>
>>> Il 14 giugno 2016 22:25:06 CEST, Anita Graser <anitagraser at gmx.at> ha
>>>
>>> scritto:
>>> On Tue, Jun 14, 2016 at 9:57 PM, Nyall Dawson
>>>
>>> <nyall.dawson at gmail.com <mailto:nyall.dawson at gmail.com>> wrote:
>>> On 31 Dec 2015 7:33 AM, "Nyall Dawson" <nyall.dawson at gmail.com
>>>
>>> <mailto:nyall.dawson at gmail.com>> wrote:
>>>> Hi all,
>>>>
>>>> The email chain below is just one example of a user who has
>>>> issues
>>>> with QGIS after installing the OpenLayers plugin. Stackexchange
>>>> is
>>>> filled with similar examples (See
>>>> http://gis.stackexchange.com/questions/tagged/qgis-openlayers-pl
>>>> ugin).
>>>>
>>>> I'm wondering if it's time we discussed the future of this
>>>> plugin. Now
>>>> that we have a viable replacement (Quick Map Services) which
>>>> doesn't
>>>> demonstrate these issues, should we deprecate the OpenLayers
>>>> plugin
>>>> and remove it from the plugin repo?
>>>
>>> Can we revisit this discussion again?
>>>
>>> I'm very much in favour of:
>>> 1. Removing openlayers plugin from the repo asap. This plugin is
>>> broken and unfortunately is harming the reputation of the
>>> project, as many users cannot distinguish the difference between
>>> the plugin's issues and problems with QGIS itself (eg see
>>> https://twitter.com/thatkindofplace/status/742543174573260800?s=03
>>> )
>>>
>>> 2. Rename QuickMapServices as "QuickMapServices (OpenLayers
>>> replacement)" on the plugin repo, so users looking for
>>> openlayers are nicely directed to the new plugin
>>>
>>> +1 for all the reasons above.
>>>
>>> Thanks for reviving this Nyall!
>>>
>>> Best wishes,
>>> Anita
>>>
>>>
>>> ----------------------------------------------------------------------
>>> --
>>>
>>> Qgis-developer mailing list
>>> Qgis-developer at lists.osgeo.org
>>> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>> _______________________________________________
>> Qgis-developer mailing list
>> Qgis-developer at lists.osgeo.org
>> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
---
Tim Sutton
QGIS Project Steering Committee Chair
tim at qgis.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20160616/491de47a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: qgis_icon.jpg
Type: image/jpeg
Size: 4642 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20160616/491de47a/attachment-0001.jpg>
More information about the Qgis-developer
mailing list