[Qgis-developer] Adding plugins to core?

Victor Olaya volayaf at gmail.com
Mon Apr 7 12:43:54 PDT 2014


I actually do not see the difference between a core plugin a something
implemented directly in the core c++ code. Other than the extra time
it might take to develop it. The user doesn't have to know it is a
plugin, and it should be easy to actually remove a core plugin from
the plugin manager (like black-listing it), so it doesn't appear
there.



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


More information about the Qgis-developer mailing list