Re: [Qgis-developer] Adding plugins to core?
On 7 April 2014 18:15, Vincent Picavet vincent...@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] 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. 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. Nyall [1] https://www.mapbox.com/tos/ ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Adding plugins to core?
Also, when it comes to OSM, IMO proper TMS support should be what is (eventually) offered as implemented feature to users. That'd allow for OSM basemaps to also export properly in qgis composer. OpenLayer' layers not exporting well in qgis composer is a pretty big limitation. Maybe a simple UI to wrap around GDAL's internal TMS support? M On Mon, Apr 7, 2014 at 5:05 PM, Nyall Dawson nyall.daw...@gmail.com wrote: On 7 April 2014 18:15, Vincent Picavet vincent...@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] 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. 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. Nyall [1] https://www.mapbox.com/tos/ ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Adding plugins to core?
Hello, Le lundi 7 avril 2014 12:05:05, Nyall Dawson a écrit : On 7 April 2014 18:15, Vincent Picavet vincent...@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@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Adding plugins to core?
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...@oslandia.comwrote: Hello, Le lundi 7 avril 2014 12:05:05, Nyall Dawson a écrit : On 7 April 2014 18:15, Vincent Picavet vincent...@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@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Adding plugins to core?
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@gmail.comwrote: 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...@oslandia.comwrote: Hello, Le lundi 7 avril 2014 12:05:05, Nyall Dawson a écrit : On 7 April 2014 18:15, Vincent Picavet vincent...@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@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Adding plugins to core?
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 kimai...@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@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@gmail.comwrote: 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...@oslandia.comwrote: Hello, Le lundi 7 avril 2014 12:05:05, Nyall Dawson a écrit : On 7 April 2014 18:15, Vincent Picavet vincent...@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@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Adding plugins to core?
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@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 kimai...@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@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@gmail.comwrote: 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...@oslandia.comwrote: Hello, Le lundi 7 avril 2014 12:05:05, Nyall Dawson a écrit : On 7 April 2014 18:15, Vincent Picavet vincent...@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
Re: [Qgis-developer] Adding plugins to core?
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.dal...@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@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 kimai...@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@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@gmail.comwrote: 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...@oslandia.comwrote: Hello, Le lundi 7 avril 2014 12:05:05, Nyall Dawson a écrit : On 7 April 2014 18:15, Vincent Picavet vincent...@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
Re: [Qgis-developer] Adding plugins to core?
Hi Victor For me, core features (and not core plugins) are much more integrated into QGIS ui and dialogs. For example, tablemanager plugins adds some nice features , but they should be integrated in the Fields tab of the vector layer properties. Having the features separated in a plugin (core or not core) adds complexity for users. For other plugins like mmqgis, which brings a list of algorithms , I agree there is no big difference between plugin and feature. I think we won't find a common rule for all the plugins. We should have a look plugin by plugin, otherwise our discussion will go in every direction. Michael 2014-04-07 21:43 GMT+02:00 Victor Olaya vola...@gmail.com: 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.dal...@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@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 kimai...@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@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@gmail.comwrote: 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...@oslandia.comwrote: Hello, Le lundi 7 avril 2014 12:05:05, Nyall Dawson a écrit : On 7 April 2014 18:15, Vincent Picavet vincent...@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.
Re: [Qgis-developer] Adding plugins to core?
I agree, each plugin is a different world. It's true that core development can bring further integration, but maybe moving plugins to core is a good moment to rethink how plugins can integrate in the QGIS interface and allow new ways of interacting (for instance, making it easy for a plugin to add elements to the properties window, or new context menus when right-clicking in an element, etc). That's currently limited (or maybe not well documented), and most plugin developers tend to do the most tipical thing and add a menu entry in the plugins menu. That is most of the time not the best thing to do...and clearly not the way to go for a core plugin. 2014-04-07 22:41 GMT+02:00 kimaidou kimai...@gmail.com: Hi Victor For me, core features (and not core plugins) are much more integrated into QGIS ui and dialogs. For example, tablemanager plugins adds some nice features , but they should be integrated in the Fields tab of the vector layer properties. Having the features separated in a plugin (core or not core) adds complexity for users. For other plugins like mmqgis, which brings a list of algorithms , I agree there is no big difference between plugin and feature. I think we won't find a common rule for all the plugins. We should have a look plugin by plugin, otherwise our discussion will go in every direction. Michael 2014-04-07 21:43 GMT+02:00 Victor Olaya vola...@gmail.com: 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.dal...@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@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 kimai...@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@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@gmail.comwrote: 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
Re: [Qgis-developer] Adding plugins to core?
Il 05/04/2014 18:59, Alex Mandel ha scritto: Perhaps the proposal is really, which plugins to ship by default? Which sounds the same but is slightly different or could be interpreted differently as add the plugins to core. right, thanks for clarifying. I'm +1 for adding a few more default plugins to the distribution, especially if they are very common in usage. Remember though, there is a trade-off, putting too many things in the default interface is overwhelming for some levels of users. It makes GIS more daunting than it needs to be. Agreed, that's why I was calling for a common decision. My suggestion is to disable by default those with a complex interface (e.g. CAD Tools). I suggest to do it for 2.4, at least for the three most popular: http://plugins.qgis.org/plugins/openlayers_plugin/ http://plugins.qgis.org/plugins/tablemanager/ http://plugins.qgis.org/plugins/mmqgis/ In my experience, these are effectively hidden features for many QGIS users. All the best. -- Paolo Cavallini - www.faunalia.eu QGIS PostGIS courses: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Adding plugins to core?
Hi, I agree there are some plugin which could be added by default, whenever QGIS has no approaching feature like Openlayers plugin. For some plugins such as tablemanager, I think we would better add the features in core, to let the user modify the fields in the Fields tab of the layer properties, and not in an other plugin dialog. 2014-04-06 8:36 GMT+02:00 Paolo Cavallini cavall...@faunalia.it: Il 05/04/2014 18:59, Alex Mandel ha scritto: Perhaps the proposal is really, which plugins to ship by default? Which sounds the same but is slightly different or could be interpreted differently as add the plugins to core. right, thanks for clarifying. I'm +1 for adding a few more default plugins to the distribution, especially if they are very common in usage. Remember though, there is a trade-off, putting too many things in the default interface is overwhelming for some levels of users. It makes GIS more daunting than it needs to be. Agreed, that's why I was calling for a common decision. My suggestion is to disable by default those with a complex interface (e.g. CAD Tools). I suggest to do it for 2.4, at least for the three most popular: http://plugins.qgis.org/plugins/openlayers_plugin/ http://plugins.qgis.org/plugins/tablemanager/ http://plugins.qgis.org/plugins/mmqgis/ In my experience, these are effectively hidden features for many QGIS users. All the best. -- Paolo Cavallini - www.faunalia.eu QGIS PostGIS courses: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Adding plugins to core?
Paolo Don't you think that adding mmqgis plugin into core will cause a lot of confusion, considering that its algorithms are already integrated in Processing (even with bug fixes in some cases)? I agree that it would be a great thing to have the OpenLayers plugin (or at least a similalar functionality) available by default in core 2014-04-06 16:10 GMT+02:00 kimaidou kimai...@gmail.com: Hi, I agree there are some plugin which could be added by default, whenever QGIS has no approaching feature like Openlayers plugin. For some plugins such as tablemanager, I think we would better add the features in core, to let the user modify the fields in the Fields tab of the layer properties, and not in an other plugin dialog. 2014-04-06 8:36 GMT+02:00 Paolo Cavallini cavall...@faunalia.it: Il 05/04/2014 18:59, Alex Mandel ha scritto: Perhaps the proposal is really, which plugins to ship by default? Which sounds the same but is slightly different or could be interpreted differently as add the plugins to core. right, thanks for clarifying. I'm +1 for adding a few more default plugins to the distribution, especially if they are very common in usage. Remember though, there is a trade-off, putting too many things in the default interface is overwhelming for some levels of users. It makes GIS more daunting than it needs to be. Agreed, that's why I was calling for a common decision. My suggestion is to disable by default those with a complex interface (e.g. CAD Tools). I suggest to do it for 2.4, at least for the three most popular: http://plugins.qgis.org/plugins/openlayers_plugin/ http://plugins.qgis.org/plugins/tablemanager/ http://plugins.qgis.org/plugins/mmqgis/ In my experience, these are effectively hidden features for many QGIS users. All the best. -- Paolo Cavallini - www.faunalia.eu QGIS PostGIS courses: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Adding plugins to core?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 06/04/2014 16:40, Victor Olaya ha scritto: Don't you think that adding mmqgis plugin into core will cause a lot of confusion, considering that its algorithms are already integrated in Processing (even with bug fixes in some cases)? oh. right. why then keeping it also separated? could the author be asked to merge his job in Processing? I think keeping both may be confusing. I agree that it would be a great thing to have the OpenLayers plugin (or at least a similalar functionality) available by default in core It seems that we all agree on this could you write the list, so we'll ask Pirmin? All the best. - -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlNCL10ACgkQ/NedwLUzIr5Q0wCfXcLVKlCujzZLoj7RN6wtYvAR pmwAoJTOQNEVjanuGmTVGYNjoyKjbVUJ =at1A -END PGP SIGNATURE- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Adding plugins to core?
On 7 April 2014 14:53, Paolo Cavallini cavall...@faunalia.it wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I agree that it would be a great thing to have the OpenLayers plugin (or at least a similalar functionality) available by default in core It seems that we all agree on this could you write the list, so we'll ask Pirmin? All the best. I'm not 100% sure on this, but isn't the OpenLayers plugin a bit legally murky? I'm pretty sure that it's either violating the Google maps terms of service or if not, it's cutting it pretty close. I know the Viking GPS program ran into issues back in 2008 with their in-built support for google maps layers [1][2] and were forced to remove this support. Having OpenLayers as a non-official plugin gives us some distance from issues like this - if we make this a core feature then we are effectively endorsing this functionality and may be opening ourselves to potential legal issues. Nyall [1] http://sourceforge.net/p/viking/mailman/viking-devel/thread/492ffe74.6060...@gmail.com/ [2] http://sourceforge.net/p/viking/mailman/message/20797817/ ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Adding plugins to core?
On Sat, Apr 5, 2014 at 1:00 AM, Nathan Woodrow madman...@gmail.com wrote: I agree that adding the plugins to core would be a good idea however I don't feel that we should just add them in their current state. The plugin repository has the benefit of of being able to update things faster then the release of QGIS itself if you find bugs, etc, you can also add features for older QGIS versions. the processing/sextante plugin is both in core and also can be updated. Same thing for ftools and gdaltools. I think these features in the plugins are great but we should really integrate them into the core project itself as new features rather then just a plugin. Having Python plugins in core can also raise issue for users because they still look like normal plugins but you can't update them because they are no longer in the repository. Having to enable handy features also feels a bit hap hazard to me. Something like the value tool could easily be integrated into the identify tool for instance. I agree, more or less - I thought about integrating it into the main identify tool, but as it works with raster layers only, how would you display raster and vector layers? There are also some other concepts floating around the idea of bring CAD functions into core so I think it's best to just focus on making those stronger. So +1 for adding the functions but -1 for just bringing the plugins into core. Not sure they would make it into core then, as development cost fof integrating into core is much higher than adding them as core python modules. For instance, the openlayer plugin would probably need quite a lot of work to be ported to c++. On the other hand, anything that relies on qwt would be better handled. Butanthing that uses python plotting libraries would obviously not work. cheers Etienne - Nathan On Sat, Apr 5, 2014 at 1:22 PM, AntonioLocandro antoniolocan...@hotmail.com wrote: I think it's a great idea, I was actually thinking about this the other day and glad you brought the topic. Although we can install plugins certainly it becomes evident when a plugin should really become a core feature, example the Openlayers Plugin, I bet almost all people using QGIS downloads it before doing anything with QGIS. Plugins extend QGIS functionality beyond what initially was thought but in many cases plugins become a must to be able to work efficiently If the plugins are added to core I would vote for blending the functions coherently with the rest of the interface in the appropriate menus. A good example would be CAD tools which I would say be called Advanced Editing or something. I would add http://plugins.qgis.org/plugins/zoomtocoordinates/ http://plugins.qgis.org/plugins/numericalDigitize/ - needs to add case for geographic coordinates -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Adding-plugins-to-core-tp5133202p5133245.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Adding plugins to core?
Perhaps the proposal is really, which plugins to ship by default? Which sounds the same but is slightly different or could be interpreted differently as add the plugins to core. I'm +1 for adding a few more default plugins to the distribution, especially if they are very common in usage. Remember though, there is a trade-off, putting too many things in the default interface is overwhelming for some levels of users. It makes GIS more daunting than it needs to be. Thanks, Alex PS: Hotmail is known to reject osgeo mailing lists. Wondering if that magically got fixed. On 04/05/2014 09:13 AM, Etienne Tourigny wrote: On Sat, Apr 5, 2014 at 1:00 AM, Nathan Woodrow madman...@gmail.com wrote: I agree that adding the plugins to core would be a good idea however I don't feel that we should just add them in their current state. The plugin repository has the benefit of of being able to update things faster then the release of QGIS itself if you find bugs, etc, you can also add features for older QGIS versions. the processing/sextante plugin is both in core and also can be updated. Same thing for ftools and gdaltools. I think these features in the plugins are great but we should really integrate them into the core project itself as new features rather then just a plugin. Having Python plugins in core can also raise issue for users because they still look like normal plugins but you can't update them because they are no longer in the repository. Having to enable handy features also feels a bit hap hazard to me. Something like the value tool could easily be integrated into the identify tool for instance. I agree, more or less - I thought about integrating it into the main identify tool, but as it works with raster layers only, how would you display raster and vector layers? There are also some other concepts floating around the idea of bring CAD functions into core so I think it's best to just focus on making those stronger. So +1 for adding the functions but -1 for just bringing the plugins into core. Not sure they would make it into core then, as development cost fof integrating into core is much higher than adding them as core python modules. For instance, the openlayer plugin would probably need quite a lot of work to be ported to c++. On the other hand, anything that relies on qwt would be better handled. Butanthing that uses python plotting libraries would obviously not work. cheers Etienne - Nathan On Sat, Apr 5, 2014 at 1:22 PM, AntonioLocandro antoniolocan...@hotmail.com wrote: I think it's a great idea, I was actually thinking about this the other day and glad you brought the topic. Although we can install plugins certainly it becomes evident when a plugin should really become a core feature, example the Openlayers Plugin, I bet almost all people using QGIS downloads it before doing anything with QGIS. Plugins extend QGIS functionality beyond what initially was thought but in many cases plugins become a must to be able to work efficiently If the plugins are added to core I would vote for blending the functions coherently with the rest of the interface in the appropriate menus. A good example would be CAD tools which I would say be called Advanced Editing or something. I would add http://plugins.qgis.org/plugins/zoomtocoordinates/ http://plugins.qgis.org/plugins/numericalDigitize/ - needs to add case for geographic coordinates ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Adding plugins to core?
I think most users would have to download a few plugins before even considering using QGIS, which ones I certainly don't know since that would require community input via a poll or something but I would imagine a few should be installed by default like Processing e.g. Openlayers plugin once it's fixed Maybe another thing to consider is that bugs that affect shipped by default plugins could become blockers? For example the very popular Openlayers plugin is still broken in master P.S. I haven't had issues with Hotmail until now -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Adding-plugins-to-core-tp5133202p5133304.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Adding plugins to core?
On Sat, Apr 5, 2014 at 1:13 PM, Etienne Tourigny etourigny@gmail.comwrote: On Sat, Apr 5, 2014 at 1:00 AM, Nathan Woodrow madman...@gmail.comwrote: I agree that adding the plugins to core would be a good idea however I don't feel that we should just add them in their current state. The plugin repository has the benefit of of being able to update things faster then the release of QGIS itself if you find bugs, etc, you can also add features for older QGIS versions. the processing/sextante plugin is both in core and also can be updated. Same thing for ftools and gdaltools. I think these features in the plugins are great but we should really integrate them into the core project itself as new features rather then just a plugin. Having Python plugins in core can also raise issue for users because they still look like normal plugins but you can't update them because they are no longer in the repository. Having to enable handy features also feels a bit hap hazard to me. Something like the value tool could easily be integrated into the identify tool for instance. I agree, more or less - I thought about integrating it into the main identify tool, but as it works with raster layers only, how would you display raster and vector layers? I have implemented most features of the Identify Tool plugin to the main identify map tool in master, here is the pull request. https://github.com/qgis/QGIS/pull/1293 There are also some other concepts floating around the idea of bring CAD functions into core so I think it's best to just focus on making those stronger. So +1 for adding the functions but -1 for just bringing the plugins into core. Not sure they would make it into core then, as development cost fof integrating into core is much higher than adding them as core python modules. For instance, the openlayer plugin would probably need quite a lot of work to be ported to c++. On the other hand, anything that relies on qwt would be better handled. Butanthing that uses python plotting libraries would obviously not work. cheers Etienne - Nathan On Sat, Apr 5, 2014 at 1:22 PM, AntonioLocandro antoniolocan...@hotmail.com wrote: I think it's a great idea, I was actually thinking about this the other day and glad you brought the topic. Although we can install plugins certainly it becomes evident when a plugin should really become a core feature, example the Openlayers Plugin, I bet almost all people using QGIS downloads it before doing anything with QGIS. Plugins extend QGIS functionality beyond what initially was thought but in many cases plugins become a must to be able to work efficiently If the plugins are added to core I would vote for blending the functions coherently with the rest of the interface in the appropriate menus. A good example would be CAD tools which I would say be called Advanced Editing or something. I would add http://plugins.qgis.org/plugins/zoomtocoordinates/ http://plugins.qgis.org/plugins/numericalDigitize/ - needs to add case for geographic coordinates -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Adding-plugins-to-core-tp5133202p5133245.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Adding plugins to core?
I think it's a great idea. +1 for openlayers, once it works with master (I don't use the others) how about adding value tool? http://plugins.qgis.org/plugins/valuetool/ But we need to fix the pyqwt bug with debian before including it in main QGIS. http://hub.qgis.org/issues/7450 On Fri, Apr 4, 2014 at 2:26 PM, Paolo Cavallini cavall...@faunalia.itwrote: Hi all. How about adding some popular, well tested plugin of general usage to main QGIS? We have done this in the past, e.g. for fTools, GDALTools, DB Manager etc., and they were good additions to QGIS. Currently the most downloaded (DESC) are: http://plugins.qgis.org/plugins/openlayers_plugin/ http://plugins.qgis.org/plugins/tablemanager/ http://plugins.qgis.org/plugins/mmqgis/ http://plugins.qgis.org/plugins/GeoCoding/ http://plugins.qgis.org/plugins/cadtools/ http://plugins.qgis.org/plugins/xytools/ I believe they are all good candidates, plus possibly more. Opinions? All the best. -- Paolo Cavallini - www.faunalia.eu QGIS PostGIS courses: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Adding plugins to core?
I think it's a great idea, I was actually thinking about this the other day and glad you brought the topic. Although we can install plugins certainly it becomes evident when a plugin should really become a core feature, example the Openlayers Plugin, I bet almost all people using QGIS downloads it before doing anything with QGIS. Plugins extend QGIS functionality beyond what initially was thought but in many cases plugins become a must to be able to work efficiently If the plugins are added to core I would vote for blending the functions coherently with the rest of the interface in the appropriate menus. A good example would be CAD tools which I would say be called Advanced Editing or something. I would add http://plugins.qgis.org/plugins/zoomtocoordinates/ http://plugins.qgis.org/plugins/numericalDigitize/ - needs to add case for geographic coordinates -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Adding-plugins-to-core-tp5133202p5133245.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Adding plugins to core?
I agree that adding the plugins to core would be a good idea however I don't feel that we should just add them in their current state. The plugin repository has the benefit of of being able to update things faster then the release of QGIS itself if you find bugs, etc, you can also add features for older QGIS versions. I think these features in the plugins are great but we should really integrate them into the core project itself as new features rather then just a plugin. Having Python plugins in core can also raise issue for users because they still look like normal plugins but you can't update them because they are no longer in the repository. Having to enable handy features also feels a bit hap hazard to me. Something like the value tool could easily be integrated into the identify tool for instance. There are also some other concepts floating around the idea of bring CAD functions into core so I think it's best to just focus on making those stronger. So +1 for adding the functions but -1 for just bringing the plugins into core. - Nathan On Sat, Apr 5, 2014 at 1:22 PM, AntonioLocandro antoniolocan...@hotmail.com wrote: I think it's a great idea, I was actually thinking about this the other day and glad you brought the topic. Although we can install plugins certainly it becomes evident when a plugin should really become a core feature, example the Openlayers Plugin, I bet almost all people using QGIS downloads it before doing anything with QGIS. Plugins extend QGIS functionality beyond what initially was thought but in many cases plugins become a must to be able to work efficiently If the plugins are added to core I would vote for blending the functions coherently with the rest of the interface in the appropriate menus. A good example would be CAD tools which I would say be called Advanced Editing or something. I would add http://plugins.qgis.org/plugins/zoomtocoordinates/ http://plugins.qgis.org/plugins/numericalDigitize/ - needs to add case for geographic coordinates -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Adding-plugins-to-core-tp5133202p5133245.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Adding plugins to core?
I agree completely with what you have written specially +1 for adding the functions but -1 for just bringing the plugins into core. Maybe start with some of the easier ones like the value tool you mention From: madman...@gmail.com Date: Sat, 5 Apr 2014 14:00:41 +1000 Subject: Re: [Qgis-developer] Adding plugins to core? To: antoniolocan...@hotmail.com CC: qgis-developer@lists.osgeo.org I agree that adding the plugins to core would be a good idea however I don't feel that we should just add them in their current state. The plugin repository has the benefit of of being able to update things faster then the release of QGIS itself if you find bugs, etc, you can also add features for older QGIS versions. I think these features in the plugins are great but we should really integrate them into the core project itself as new features rather then just a plugin. Having Python plugins in core can also raise issue for users because they still look like normal plugins but you can't update them because they are no longer in the repository. Having to enable handy features also feels a bit hap hazard to me. Something like the value tool could easily be integrated into the identify tool for instance. There are also some other concepts floating around the idea of bring CAD functions into core so I think it's best to just focus on making those stronger. So +1 for adding the functions but -1 for just bringing the plugins into core. - Nathan On Sat, Apr 5, 2014 at 1:22 PM, AntonioLocandro antoniolocan...@hotmail.com wrote: I think it's a great idea, I was actually thinking about this the other day and glad you brought the topic. Although we can install plugins certainly it becomes evident when a plugin should really become a core feature, example the Openlayers Plugin, I bet almost all people using QGIS downloads it before doing anything with QGIS. Plugins extend QGIS functionality beyond what initially was thought but in many cases plugins become a must to be able to work efficiently If the plugins are added to core I would vote for blending the functions coherently with the rest of the interface in the appropriate menus. A good example would be CAD tools which I would say be called Advanced Editing or something. I would add http://plugins.qgis.org/plugins/zoomtocoordinates/ http://plugins.qgis.org/plugins/numericalDigitize/ - needs to add case for geographic coordinates -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Adding-plugins-to-core-tp5133202p5133245.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
