Re: [Qgis-developer] Future of spatialite provider?

[Even Rouault]

On mardi 14 mars 2017 09:38:10 CET Nyall Dawson wrote:
> > This thread was about the spatialite driver ;-) Support for spatial and
> > non-spatial layers has always existed in OGR core, but what is available
> > for a given format is driver specific.
> 
> Even - I'm interested to hear your thoughts here. Do you think there's
> any good reason for a dedicated spatialite provider?

I've not necessarily all the functionalities of the spatialite provider in 
mind. I think some 
specialized logic in the spatialite case (there's already some for GPKG) might 
be needed to be 
ported into the OGR provider, so as to get feature parity. For example things 
like 
QgsSpatiaLiteProvider::pkAttributeIndexes() or 
QgsSpatiaLiteProvider::discoverRelations() 
(non exhaustive list)

There's the question of the provider UI and connection strings.

> 
> The *only* reason I can see (would need to be tested) is that
> potentially there's a cost to the spatialite -> OGR -> QgsFeature
> translation, vs just spatialite -> QgsFeature. But my hunch is that
> this would be offset by optimisations present in the OGR driver which
> aren't in the QGIS provider.

In practice waiting for I/O to be completed is probably the major bottleneck.

Even


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Future of spatialite provider?

[Nyall Dawson]

> This thread was about the spatialite driver ;-) Support for spatial and
> non-spatial layers has always existed in OGR core, but what is available for
> a given format is driver specific.
>

Even - I'm interested to hear your thoughts here. Do you think there's
any good reason for a dedicated spatialite provider?

The *only* reason I can see (would need to be tested) is that
potentially there's a cost to the spatialite -> OGR -> QgsFeature
translation, vs just spatialite -> QgsFeature. But my hunch is that
this would be offset by optimisations present in the OGR driver which
aren't in the QGIS provider.

Nyall
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Future of spatialite provider?

[Even Rouault]

On lundi 13 mars 2017 21:25:54 CET Andreas Neumann wrote:
> Hi Josef,
> 
>  From http://www.gdal.org/drv_geopackage.html
> 
> "The core GeoPackage specification does not currently support
> non-spatial tables, but starting with GDAL 2.0, the driver allows
> creating and reading such tables via the Aspatial Support
> (gdal_aspatial) extension. Note: starting with GDAL 2.2, the driver will
> also, by default, list non spatial tables that are not registered
> through the gdal_aspatial extension."
> 
> So with newer GDAL versions it is possible to create and read
> non-spatial tables.

Andreas,

This thread was about the spatialite driver ;-) Support for spatial and 
non-spatial layers has 
always existed in OGR core, but what is available for a given format is driver 
specific.

Regarding GeoPackage the doc was a bit out of date. I've just updated it :

"""
Non-spatial tables

The core GeoPackage specification of GeoPackage 1.0 and 1.1 did not support 
non-spatial 
tables. This was added in GeoPackage 1.2 as the "attributes" data type.

Starting with GDAL 2.0, the driver allows creating and reading non-spatial 
tables with the 
Aspatial Support (gdal_aspatial) extension.

Starting with GDAL 2.2, the driver will also, by default, list non spatial 
tables that are not 
registered through the gdal_aspatial extension, and support the GeoPackage 1.2 
"attributes" 
data type as well. Starting with GDAL 2.2, non spatial tables are by default 
created following 
the GeoPackage 1.2 "attributes" data type (can be controlled with the 
ASPATIAL_VARIANT 
layer creation option)
"""

Regarding the SQLite/Spatialite driver, there is an opening option, 
LIST_ALL_TABLES=YES, 
that can be set so as to list all tables, and not only those registered in the 
geometry_columns 
table. 
http://gdal.org/drv_sqlite.html

Even

> 
> Andreas
> 
> On 13.03.2017 17:13, josef k wrote:
> > Here is just a reminder from a user/plugin maintainer, please ignore
> > if not relevant.
> > 
> > If the spatialite data provider is to be removed then we will have to
> > update some plugins to reflect that which is ok, not a big deal. But
> > it is important that the current features of the spatialite data
> > provider are included into the OGR provider before changing.
> > 
> > E.g. we are using the spatalite data provider in plugins to add
> > non-spatial spatialite tables. I could not achieve this by using the
> > OGR provider (although it was a couple of years ago I was looking into
> > this and it may have changed by now).
> > 
> > regards
> > Josef
> > 
> > On Mon, 13 Mar 2017 11:28:45 +1000, Nyall Dawson wrote:
> > I'm wondering what the future of the spatialite provider
> > should be. I
> > find it odd that spatialite layers utilise the dedicated
> > spatialite
> > provider, but geopackage layers use the OGR provider.
> > 
> > I think there's potential value in removing the spatialite
> > provider
> > and always reading these layers via OGR.
> > 
> > ___
> > Qgis-developer mailing list
> > Qgis-developer@lists.osgeo.org
> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Future of spatialite provider?

[Andreas Neumann]

Hi Josef,

From http://www.gdal.org/drv_geopackage.html

"The core GeoPackage specification does not currently support 
non-spatial tables, but starting with GDAL 2.0, the driver allows 
creating and reading such tables via the Aspatial Support 
(gdal_aspatial) extension. Note: starting with GDAL 2.2, the driver will 
also, by default, list non spatial tables that are not registered 
through the gdal_aspatial extension."


So with newer GDAL versions it is possible to create and read 
non-spatial tables.


Andreas


On 13.03.2017 17:13, josef k wrote:
Here is just a reminder from a user/plugin maintainer, please ignore 
if not relevant.


If the spatialite data provider is to be removed then we will have to 
update some plugins to reflect that which is ok, not a big deal. But 
it is important that the current features of the spatialite data 
provider are included into the OGR provider before changing.


E.g. we are using the spatalite data provider in plugins to add 
non-spatial spatialite tables. I could not achieve this by using the 
OGR provider (although it was a couple of years ago I was looking into 
this and it may have changed by now).


regards
Josef

On Mon, 13 Mar 2017 11:28:45 +1000, Nyall Dawson wrote:

I'm wondering what the future of the spatialite provider
should be. I
find it odd that spatialite layers utilise the dedicated
spatialite
provider, but geopackage layers use the OGR provider.

I think there's potential value in removing the spatialite
provider
and always reading these layers via OGR.




___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Plugin [1191] Tempus approval notification.

[noreply]

Plugin Tempus approval by pcav.
The plugin version "[1191] Tempus 1.0.1" is now approved
Link: http://plugins.qgis.org/plugins/tempus_qgis/
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Future of spatialite provider?

[josef k]

Here is just a reminder from a user/plugin maintainer, please ignore if not
relevant.

If the spatialite data provider is to be removed then we will have to
update some plugins to reflect that which is ok, not a big deal. But it is
important that the current features of the spatialite data provider are
included into the OGR provider before changing.

E.g. we are using the spatalite data provider in plugins to add non-spatial
spatialite tables. I could not achieve this by using the OGR provider
(although it was a couple of years ago I was looking into this and it may
have changed by now).

regards
Josef

On Mon, 13 Mar 2017 11:28:45 +1000, Nyall Dawson wrote:
>
>> I'm wondering what the future of the spatialite provider should be. I
>> find it odd that spatialite layers utilise the dedicated spatialite
>> provider, but geopackage layers use the OGR provider.
>>
>> I think there's potential value in removing the spatialite provider
>> and always reading these layers via OGR.
>>
>>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] QGIS remote control API

[Barry Rowlingson]

My first job was in integrating spatial statistics and GIS. In those
days (1990) that meant Arc/Info version 4 and FORTRAN, until we
discovered S-Plus and ditched Arc/Info for real statistics software.

Twenty six years on and still thinking about integration. Some of you
may have seen my very sketchy R package that starts up a map canvas
and layer list and then lets R users add map data to the canvas. It
works via a libpython interpreter loaded into R and then making PyQGIS
API calls. My GSoC 2017 proposal is basically improving and extending
that.

But I've leant towards a slightly different idea - remote control of a
QGIS instance. There exists already a QgsRemoteControl plugin which is
intended to keep two QGIS instances in sync with respect to projection
and extent etc. But what I'd like to do is have an HTTP API that could
also add and modify data layers to a running QGIS, potentially from
any client.

So once set up, you could do:

 wget http://localhost:17919/zoom?extent=...

 wget --post-file=map.json http://localhost:17919/addlayer

and so on. Then any "mapping deficient" programming language or system
could then have a client written for that API and use whatever
functionality is exposed by it.

 I've already got a basic HTTP server that runs in Qgis and accepts
requests, and it uses the Qt event system so is totally non-blocking
(except when actually processing a request).

 Is this a good idea/useful idea/dumb idea? I can rewrite my GSoC to
more reflect this idea if its thought useful. I have been contacted by
a possible student with an interest.

Barry
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Plugin [1188] MTOP Open Data approval notification.

[noreply]

Plugin MTOP Open Data approval by pcav.
The plugin version "[1188] MTOP Open Data 1.2 Experimental" is now approved
Link: http://plugins.qgis.org/plugins/MTOPOpenData/
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] R in Processing: errors not shown

[matteo]

> this did not happen in my case

ok, not sure if this is related to this mandatory R packages

> after installing them, the error is gone, and the entries appear on the list

ok, do you have ggplot2 installed? If not, try to import the attached
script (copy and paste the content in the editor) and try to use it

if it works and you did not had ggplot2 installed then Processing is
able to install additional packages, if not, then I'm totally wrong :)

Matteo
##[R-Geostatistics]=group
##showplots
##Layer=vector
##X=Field Layer
##Group=optional Field Layer
#Log_Scale = boolean False
##Data_Transformation=selection normal;log10;ln;sqrt;exp

require(ggplot2)


if(Data_Transformation == 0){
ax <- scale_y_continuous()
yy <- ylab(X)
} else if(Data_Transformation == 1){
ax <- scale_y_log10()
yy <- ylab(paste("log10", X))
} else if(Data_Transformation == 2){
ax <- coord_trans(y = "log")
yy <- ylab(paste("ln", X))
} else if(Data_Transformation == 3){
ax <- coord_trans(y = "sqrt")
yy <- ylab(paste("sqrt", X))
} else if(Data_Transformation == 4){
ax <- coord_trans(y = "exp")
yy <- ylab(paste("exp", X))
}

if(is.null(Group)){
ggplot()+
geom_boxplot(aes(x=1, y=Layer[[X]]))+
xlab("")+
yy +
ax +
ggtitle(paste("Boxplot of", X))
} else {
ggplot()+
geom_boxplot(aes(x=Layer[[Group]], y=Layer[[X]], 
fill=as.factor(Layer[[Group]])))+
xlab(Group)+
yy +
scale_fill_discrete(name=Group) +
ax +
ggtitle(paste("Boxplot of", X))
}
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] R in Processing: errors not shown

[Paolo Cavallini]

Il 13/03/2017 15:09, matteo ha scritto:

> that sounds weird. Unless I'm wrong (and except the packages rgdal and
> raster) I thought that Processing would automatically download and
> install the additional packages if missing.

this did not happen in my case

> Are you sure that the error is related to the missing packages?

after installing them, the error is gone, and the entries appear on the list

thanks

-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all&geo=IT&q=qgis,arcgis
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] R in Processing: errors not shown

[matteo]

Hi,

> Hi all,
> when installing R scripts from online repo for Processing, no error is
> visible to users when necessary R modules are missing, but models are
> not shown. Errors are in the log:
> ===
> 2017-03-12T23:39:03   0   Comandi di esecuzione R
>   options("repos"="http://cran.at.r-project.org/";)
>   tryCatch(find.package("rgdal"), error=function(e)
> install.packages("rgdal", dependencies=TRUE))
>   tryCatch(find.package("raster"), error=function(e)
> install.packages("raster", dependencies=TRUE))
>   library("raster")
> ===
> IMHO this is difficult to grasp for the user, and an explicit error
> should be given, together with the suggestion to install the missing libs.
> Am I missing something?
> Thanks.

that sounds weird. Unless I'm wrong (and except the packages rgdal and
raster) I thought that Processing would automatically download and
install the additional packages if missing.

Are you sure that the error is related to the missing packages?

Matteo
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS 2.18 on OSX

[Paolo Cavallini]

Il 13/03/2017 14:05, William Kyngesburye ha scritto:
> Since point releases are not announced on the list any more, I often miss 
> them for packaging.  I usually see a reference to them on the list in a 
> question.  Also, I've been a bit occupied lately with other things.  I'll 
> work on packaging the latest updates soon.

Thanks William.
You can find all the dates here:
http://qgis.org/en/site/getinvolved/development/roadmap.html#release-schedule
All the best.

-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all&geo=IT&q=qgis,arcgis
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS 2.18 on OSX

[William Kyngesburye]

Since point releases are not announced on the list any more, I often miss them 
for packaging.  I usually see a reference to them on the list in a question.  
Also, I've been a bit occupied lately with other things.  I'll work on 
packaging the latest updates soon.

> On Mar 13, 2017, at 5:19 AM, Paolo Cavallini  wrote:
> 
> Il 13/03/2017 11:10, Giovanni Manghi ha scritto:
>>> * Processing throws an error:
>>> ===
>>> Couldn't load plugin processing due to an error when calling its
>>> classFactory() method
>> 
>> Can't confirm on macOS Sierra and 2.18.2.
> 
> Thanks for checking. At first I also had no issue, but after some usage
> the error popped up, and now I cannot get rid of it.
> All the best.
> 
> -- 
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> https://www.google.com/trends/explore?date=all&geo=IT&q=qgis,arcgis
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Ideas concerning plugin deployment

[Tom Kralidis]

In MetaSearch we have a release workflow for 'out-of-band' releases
from QGIS core which was inherited from when MetaSearch was not a core
QGIS plugin.

MetaSearch uses Paver to generate a zipfile for upload to plugins.qgis.org [1].
You can see the core machinery to generate the zipfile at [2].

Hope this helps.

..Tom

[1] 
https://github.com/qgis/QGIS/blob/master/python/plugins/MetaSearch/pavement.py#L138
[2] 
https://github.com/qgis/QGIS/blob/master/python/plugins/MetaSearch/pavement.py#L106


On Mon, 13 Mar 2017, Matthias Kuhn wrote:


Date: Mon, 13 Mar 2017 09:26:18 +0100
From: Matthias Kuhn 
To: qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] Ideas concerning plugin deployment

Hi Magnus,

we use a release script in QFieldSync, where we directly release from
travis when a new tag pushed and tests run successfully (and some other
conditions like tag name matches the version in metadata etc. are met).

https://github.com/opengisch/qfieldsync/blob/master/.travis.yml#L27

It also only packages a sub-folder with the plugin, so scripts for ci
etc that live outside this folder are not packaged.

Hope that helps :)

Matthias


On 03/11/2017 10:12 PM, Magnus Homann wrote:

Hello, currently I tag my plugin code in git, and extract and build a
zip-file which is uploaded to plugin repo.
The Makefile that plugin_builder is supplyng, also have an option to zip
locally deployed files for later upload.

I prefer to packaged directly from tag in git, but then every file that
is in git will be packaged!

Have anyone made a mixed approach, packaging directly from a git tag,
but only a sub-set of the files?

/Magnus
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Future of spatialite provider?

[a . furieri]

On Mon, 13 Mar 2017 11:28:45 +1000, Nyall Dawson wrote:

I'm wondering what the future of the spatialite provider should be. I
find it odd that spatialite layers utilise the dedicated spatialite
provider, but geopackage layers use the OGR provider.

I think there's potential value in removing the spatialite provider
and always reading these layers via OGR.



+1

less complexity = more efficiency = stronger standardization

I personally advocated to adopt such an approach one or two
years ago; maintaining an ad hoc QGIS provider simply adds
more unrequired complexity with no obvious benefits.

thanks to the magnificent work of Even Rouault the OGR
sqlite/spatialite/gpkg provider is very stable and affordable,
it's frequently updated and it's very quick in supporting the
most recent cool features introduced by subsequent updated
versions.
Even more important: many other GFOSS components (e.g.
MapServer) are based on the OGR provider, so switching
from the QGIS provider to the standard OGR provider
will obviously facilitate a smoother and more consistent
integration between different tools/apps.

bye Sandro
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS 2.18 on OSX

[Paolo Cavallini]

Il 13/03/2017 11:10, Giovanni Manghi ha scritto:
>> * Processing throws an error:
>> ===
>> Couldn't load plugin processing due to an error when calling its
>> classFactory() method
> 
> Can't confirm on macOS Sierra and 2.18.2.

Thanks for checking. At first I also had no issue, but after some usage
the error popped up, and now I cannot get rid of it.
All the best.

-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all&geo=IT&q=qgis,arcgis
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Ideas concerning plugin deployment

[Marco Bernasocchi]

On 13.03.2017 11:12, Marco Bernasocchi wrote:

> maybe we could have a pip repo as backend. just talking out loud and
> explicitly adding Ale to the conversation :)
> 

Forgot the link: https://packaging.python.org/self_hosted_repository/


> ciao
> 
> 
> 
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> 

-- 
Marco Bernasocchi
OPENGIS.ch - berna.io - 27summits.ch



signature.asc
Description: OpenPGP digital signature
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Ideas concerning plugin deployment

[Marco Bernasocchi]

On 13.03.2017 11:06, Tim Sutton wrote:
>> or make plugins PIP packages :)
> 
> Yeah or that :-) I think we did discuss it before and it would be pretty
> cool - only thing we lose really if the curated repository approach we
> have now (which might make some people happy I guess)...

maybe we could have a pip repo as backend. just talking out loud and
explicitly adding Ale to the conversation :)

ciao

-- 
Marco Bernasocchi
OPENGIS.ch - berna.io - 27summits.ch



signature.asc
Description: OpenPGP digital signature
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS 2.18 on OSX

[Giovanni Manghi]

> * Processing throws an error:
> ===
> Couldn't load plugin processing due to an error when calling its
> classFactory() method

Can't confirm on macOS Sierra and 2.18.2.


-- G --
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Ideas concerning plugin deployment

[Tim Sutton]

Hi

> On 13 Mar 2017, at 12:04 PM, Marco Bernasocchi  wrote:
> 
> Hi
> 
> On 13.03.2017 10:44, Tim Sutton wrote:
>> One thing that might actually be nice is for us to introduce some kind
>> of Manifest file for plugins (we could just copy the system from pip) so
>> that plugin authors can specify which files and resources get packaged.
> 
> 
> or make plugins PIP packages :)

Yeah or that :-) I think we did discuss it before and it would be pretty cool - 
only thing we lose really if the curated repository approach we have now (which 
might make some people happy I guess)...

Regards

Tim


> 
> 
> -- 
> Marco Bernasocchi
> OPENGIS.ch - berna.io - 27summits.ch
> 

—










Tim Sutton

Co-founder: Kartoza
Project chair: QGIS.org

Visit http://kartoza.com  to find out about open source:

Desktop GIS programming services
Geospatial web development
GIS Training
Consulting Services

Skype: timlinux 
IRC: timlinux on #qgis at freenode.net

Kartoza is a merger between Linfiniti and Afrispatial

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Ideas concerning plugin deployment

[Marco Bernasocchi]

Hi

On 13.03.2017 10:44, Tim Sutton wrote:
> One thing that might actually be nice is for us to introduce some kind
> of Manifest file for plugins (we could just copy the system from pip) so
> that plugin authors can specify which files and resources get packaged.


or make plugins PIP packages :)


-- 
Marco Bernasocchi
OPENGIS.ch - berna.io - 27summits.ch



signature.asc
Description: OpenPGP digital signature
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Ideas concerning plugin deployment

[Tim Sutton]

Hi Magnus

(by the way nice to see you pop up here on the list after many years!)

> On 13 Mar 2017, at 10:32 AM, Magnus Homann  wrote:
> 
> Thank you, I'll look into InaSAFE if that is something I could use. The 
> Makefile from plugin builder is already using git archive, but packages every 
> file in the repo. 

Yeah if you are using git-archive it is going to make a zip containing 
everything in the tag so you need to extract that afterwards and clean out 
non-distributable stuff. Some folks are also using paver to do package 
preparation - check at some of the Boundless plugins for examples...

One thing that might actually be nice is for us to introduce some kind of 
Manifest file for plugins (we could just copy the system from pip) so that 
plugin authors can specify which files and resources get packaged.

Regards

Tim


> 
> /Magnus
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

—










Tim Sutton

Co-founder: Kartoza
Project chair: QGIS.org

Visit http://kartoza.com  to find out about open source:

Desktop GIS programming services
Geospatial web development
GIS Training
Consulting Services

Skype: timlinux 
IRC: timlinux on #qgis at freenode.net

Kartoza is a merger between Linfiniti and Afrispatial

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Plugin [1048] Another DXF Importer / DXF2Shape Converter approval notification.

[noreply]

Plugin Another DXF Importer / DXF2Shape Converter approval by pcav.
The plugin version "[1048] Another DXF Importer / DXF2Shape Converter 0.81" is 
now approved
Link: http://plugins.qgis.org/plugins/AnotherDXF2Shape/
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] rename Advanced digitizing tools to CAD tools

[Denis Rouzaud]

Dear all,

I just made a proposition to rename Advanced digitizing tools to CAD tools.
Here is the discussion:
https://github.com/qgis/qgis3_UIX_discussion/issues/37

Please reply on the issue if you think it should or should not happen.

Cheers,
Denis
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Ideas concerning plugin deployment

[Magnus Homann]

Thank you, I'll look into InaSAFE if that is something I could use. The 
Makefile from plugin builder is already using git archive, but packages every 
file in the repo. 

/Magnus
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Plugin [1193] Shape Tools approval notification.

[noreply]

Plugin Shape Tools approval by pcav.
The plugin version "[1193] Shape Tools 0.2" is now approved
Link: http://plugins.qgis.org/plugins/shapetools/
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Plugin [880] Physiocap approval notification.

[noreply]

Plugin Physiocap approval by pcav.
The plugin version "[880] Physiocap 1.7.0" is now approved
Link: http://plugins.qgis.org/plugins/PhysiocapAnalyseur/
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Ideas concerning plugin deployment

[Matthias Kuhn]

Hi Magnus,

we use a release script in QFieldSync, where we directly release from
travis when a new tag pushed and tests run successfully (and some other
conditions like tag name matches the version in metadata etc. are met).

https://github.com/opengisch/qfieldsync/blob/master/.travis.yml#L27

It also only packages a sub-folder with the plugin, so scripts for ci
etc that live outside this folder are not packaged.

Hope that helps :)

Matthias


On 03/11/2017 10:12 PM, Magnus Homann wrote:
> Hello, currently I tag my plugin code in git, and extract and build a
> zip-file which is uploaded to plugin repo.
> The Makefile that plugin_builder is supplyng, also have an option to zip
> locally deployed files for later upload.
> 
> I prefer to packaged directly from tag in git, but then every file that
> is in git will be packaged!
> 
> Have anyone made a mixed approach, packaging directly from a git tag,
> but only a sub-set of the files?
> 
> /Magnus
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> 
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QgsGeometry, Geos and SFCGAL

[G. Allegri]

Something I forgot to add in my original reply - instead of investing

time into utilising CGAL instead of GEOS, I'd rather see us
investigate swapping out GEOS calls to Boost::geometry calls. The
boost geometry algorithms are really nicely implemented, and their
interface avoids the need to convert between different object types
(ie QgsGeometry->GEOS). This could potentially be a big
performance/memory usage win.


I think that keeping GEOS for all the Simple Features stuff (geoms,
predicates and ops) is important to remain aligned and keep comparability
with most of the other GFOSS sw based on GEOS/JTS.

The only relevant exception is GRASS GIS, but it's different in so many
ways that it is barely comparable to anyone else...

Giovanni
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Plugin [1187] Split Features On Steroids approval notification.

[noreply]

Plugin Split Features On Steroids approval by pcav.
The plugin version "[1187] Split Features On Steroids 0.6" is now approved
Link: http://plugins.qgis.org/plugins/SplitPolygonShowingAreas/
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Missing the support for scale parameter in WMS Legend

[Andrea Peri]

Hereis the link to dowload the quick video.
It use the qgis 2.2.

https://www.dropbox.com/s/agskwlvw44amcw8/Video13-03-2017-08-05-42.zip?dl=0

A.

2017-03-13 7:43 GMT+01:00 Nyall Dawson :
> On 13 March 2017 at 16:32, Andrea Peri  wrote:
>> Hi Nyal,
>> Unfortunatelly no.
>> No news on this.
>> I have no the skill to understand what is the code interested.
>> I know it should on one the the committed link due a report send us at
>> that time.
>>
>> Now I try to install the qgis 2.2 or qgis 2.4, and try to test it again.
>> Maybe I could do a video.
>
> A video would be good - I'm not really sure what this change is supposed to 
> do.
>
> I'/m just trying to clarify... is it something which is broken, or
> something which has been totally removed?
>
> Nyall



-- 
-
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer