Re: [QGIS-Developer] [PyQGIS] adding a layer with an auth config ID leaks into the project

[Bernhard Ströbl]

Hi Denis,

I use:
uri = QgsDataSourceUri()
uri.setDataSource(schemaName, tableName, geomColumn)
uri.setConnection(thisHostName,
str(thisPort), thisDatabaseName,
"", "", QgsDataSourceUri.SslRequire, thisAuthCfgId)
vLayerUri = uri.uri(False)
vlayer = QgsVectorLayer(vLayerUri, displayName, "postgres",
layerOptions)

this works as expected storing the authcfg=auth_id using QGIS 3.4

Bernhard

Am 14.10.2019 um 15:52 schrieb Denis Rouzaud:

Hi all,

I add a layer using an authentification config ID using PyQGIS:

uri = QgsDataSourceUri()
uri.setConnection(HOST, PORT, DB, None, None, 
QgsDataSourceUri.SslPrefer, pg_auth_id)


In the project, the credentials are written in clear text in the project 
file:


dbname='pub' host=geodb.rootso.org  
port=5432 user='xx' password='xx'


Is it possible to avoid this? How?

Cheers,
Denis




__ Information from ESET Mail Security, version of virus signature 
database 20178 (20191014) __

The message was checked by ESET Mail Security.
http://www.eset.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] SSL Performance Overhead

[Bernhard Ströbl]

Hi all,

I have to add that we use SSL to encrypt the user credentials as we use 
LDAP to authentificate users at the database. So SSL is not only 
relevant looking at data stored in the database.

Bernhard

Am 17.06.2019 um 13:56 schrieb Andreas Neumann:

Hi Stefan,

Yes, sure. If I were a bank or the national bank I would also mandate 
use of SSL. Also, when personal data is involved. But many gov 
authorities have primarily publically available geoinformation (object 
data, no personal data) in their DBs and no sensitive data.


We are just discussing the defaults, anyone can enable SSL if it is 
useful or required in their usage scenario.


Andreas

On 2019-06-17 13:20, Stefan Steiger wrote:

One of our customers (Swiss National Bank) mandates the use of SSL in 
their internal LAN, even for DB connections.


Using anything but SSL is an insecure mode of communication, even in LAN.

RSA/DSA Accepted key-length is 2048 bit, recommended is 3072, ECC is 
160 Bit, recommended 256.


-Only latest version of OpenSSL allowed

-Accepted TLS 1.1+, recommended TLS 1.2+

-SSL Version 3.0 or older are explicitly forbidden

-Sha-1 is disallowed, sha2/3 accepted @ hash length 256 Bit

-Extended Validation certificates have to be used

-Wildcards in fully qualified names not allowed

-Accepted: CTR/CBC/CCM/EAX, recommended GCM

-SSL accepted with forward secrecy Disabled, recommended Enabled

-Recommended CryptRandom: /dev/random, /dev/urandom,

as per IT Security Baseline 2017-07-20

*Von:*QGIS-Developer [mailto:qgis-developer-boun...@lists.osgeo.org] 
*Im Auftrag von *Andreas Neumann

*Gesendet:* Montag, 17. Juni 2019 09:05
*An:* Matthias Kuhn 
*Cc:* qgis-developer@lists.osgeo.org
*Betreff:* Re: [QGIS-Developer] SSL Performance Overhead

Hi,

I would say, that the use of SSL should be encouraged if the 
connection goes through public networks. If the Postgis connection is 
within the company LAN I don't see a strong reason for enabling SSL, 
unless the company LAN is designed in an "unsafe" way, or if sensitive 
data must be hidden from other employees in the same company.


Personally, I never had good results (performance wise) if Postgis 
connections went through the public Internet, unless it is some "toy 
data".


For this reason, I usually used streaming replication to replicate 
Postgis, so it is as close as possible to the users who need the data. 
The streaming replication, if it goes through the public internet, of 
course should use SSL (or often it goes through an SSH tunnel).


Sorry, I don't have any data on the overhead of SSL connections though.

Andreas

On 2019-06-17 08:48, Matthias Kuhn wrote:

Hi,

The documentation currently promises "massive speed-ups in PostGIS
layer rendering" with SSL disabled. [1

]

I find some references to performance cost of SSL but they should
be compensated for with connection pooling which we use for quite
some time already.

Recently, the web is more and more encrypted - and that is very
good! - so I think we should also start to encourage people to
encrypt their SSL connections. Or at least certainly not
discourage them from using encryption by promising performance
benefits.

Is there anyone who knows why this sentence was introduced? And if
there is (still) an issue with performance when using SSL?

Best regards

Matthias

[1]

https://docs.qgis.org/2.18/en/docs/user_manual/managing_data_source/opening_data.html#creating-a-stored-connection



[2] https://github.com/qgis/QGIS-Documentation/pull/3840

___
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





__ Information from ESET Mail Security, version of virus 
signature database 19536 (20190617) __


The message was checked by ESET Mail Security.
http://www.eset.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







__ Information from ESET Mail Security, version of virus signature 
database 19537 (20190617) __

The message was checked by ESET Mail Security.
http://www.eset.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] New version notifications

[Bernhard Ströbl]

Hi Etienne,

thank you, pretty obvious :-)

Bernhard

Am 04.06.2019 um 07:11 schrieb Etienne Trimaille:

In QGIS Settings -> "General", you can disable "Check QGIS version".

If you are deploying QGIS with an INI file, you can do it 
programmatically. You can hide this checkbox because QGIS version is 
managed by the system administrator.

https://docs.qgis.org/3.4/en/docs/user_manual/introduction/qgis_configuration.html#deploying-qgis-within-an-organization

Le mar. 4 juin 2019 à 06:55, Bernhard Ströbl <mailto:bernhard.stro...@jena.de>> a écrit :


On that occasion:

how can I deactivate the new version information? I get frequent calls
from my users asking if they need to do something. It's kind of
annoying
because we use LTS.

Bernhard

Am 03.06.2019 um 18:11 schrieb Tim Sutton:
 > It takes the version status from QGIS.org <http://QGIS.org> not
from the
 > repositories. When the actual package arrives depends on your
package
 > repo etc.
 >
 > Regards
 >
 > Tim
 >
 >> On 3 Jun 2019, at 00:16, Cory Albrecht mailto:m...@hanfastolfe.com>
 >> <mailto:m...@hanfastolfe.com <mailto:m...@hanfastolfe.com>>> wrote:
 >>
 >> Why does QGIS alert about newer versions before the version is even
 >> available in something like the Debian/Ubuntu repos at
 >> http://qgis.org/ubuntu-nightly-release ?
 >> ___
 >> QGIS-Developer mailing list
 >> QGIS-Developer@lists.osgeo.org
<mailto:QGIS-Developer@lists.osgeo.org>
<mailto:QGIS-Developer@lists.osgeo.org
<mailto: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
 > *Ex Project chair:*QGIS.org <http://QGIS.org>
 >
 > Visit http://kartoza.com <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 <http://freenode.net>
<http://freenode.net>
 >
 > I'd love to connect. Here's my calendar link
 > <https://calendly.com/timlinux> to make finding time easy.
 >
 >
 >
 > __ Information from ESET Mail Security, version of virus
 > signature database 19461 (20190603) __
 >
 > The message was checked by ESET Mail Security.
 > http://www.eset.com
 >
 >  '�z�Zr �r ^�)�j[p��Z��'~��zJ&�W�� ��{^� �iק
 >



__ Information from ESET Mail Security, version of virus
signature database 19465 (20190604) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org <mailto:QGIS-Developer@lists.osgeo.org>
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer





__ Information from ESET Mail Security, version of virus signature 
database 19465 (20190604) __

The message was checked by ESET Mail Security.
http://www.eset.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] New version notifications

[Bernhard Ströbl]

On that occasion:

how can I deactivate the new version information? I get frequent calls 
from my users asking if they need to do something. It's kind of annoying 
because we use LTS.


Bernhard

Am 03.06.2019 um 18:11 schrieb Tim Sutton:
It takes the version status from QGIS.org  not from the 
repositories. When the actual package arrives depends on your package 
repo etc.


Regards

Tim

On 3 Jun 2019, at 00:16, Cory Albrecht > wrote:


Why does QGIS alert about newer versions before the version is even 
available in something like the Debian/Ubuntu repos at 
http://qgis.org/ubuntu-nightly-release ?

___
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
*Ex 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 

I'd love to connect. Here's my calendar link 
 to make finding time easy.




__ Information from ESET Mail Security, version of virus 
signature database 19461 (20190603) __


The message was checked by ESET Mail Security.
http://www.eset.com

'�z�Zr�r^�)�j[p��Z��'~��zJ&�W����{^��iק





__ Information from ESET Mail Security, version of virus signature 
database 19465 (20190604) __

The message was checked by ESET Mail Security.
http://www.eset.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] QGIS server issue: bounding box issues

[Bernhard Ströbl]

Hi Andreas,

remember ticket #9160 [1], probably the solution found there could be 
used for QGIS-Server?


Bernhard

[1] https://issues.qgis.org/issues/9160

Am 09.05.2019 um 11:28 schrieb Andreas Neumann:

Hi QGIS (server) devs,

We came across issues around calculating bounding boxes in QGIS server.

1. Layers with only one point feature:

If a layer contains only one single point feature, QGIS server 
calculates a bounding box where the minx equals maxx and miny equals 
maxy, so resulting in a bounding box without a width and height. Sounds 
logical to QGIS server developers, but combined with the fact that QGIS 
server doesn't take into account rendered symbol sizes (another issue we 
have, see issue nr 2), it means that no WMS client will ever see this 
one single symbol rendered, which can't be the solution here ...


2. Layer bounding boxes do not take into account rendered symbol sizes:

Please have a look at 
http://www.carto.net/neumann/temp/qgis_server_bounding_box_issue.png - 
The green rectangle and the green arrows are not part of the QGIS server 
rendering, but they are added as an annotation to the rendered QGIS 
server graphics, to highlight the issues.


Here we have the issue that QGIS server only uses the "raw" geometry of 
point symbols without taking into account rendered symbol sizes. Now, I 
do understand that calculating symbol sizes is scale dependent and there 
is no single solution to that, but again, I think the current behavior 
of QGIS server (simply cutting off symbols at layer bounding boxes) is 
not a good and nice behavior. At least, I think the author of the WMS 
service should have a chance to define an extra margin to be added to 
the bounding boxes of the raw geometries of the point layer, either as a 
"per project" or "per layer" QGIS server configuration.


@Andrea: I wonder what Geoserver does in such cases?

Any thoughts how to solve these issues? The current behavior of QGIS 
server is not satisfactory to me, for both cases.


Thanks for your replies,

Andreas

___
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



--
Bernhard Ströbl
Anwendungsbetreuer GIS

Kommunale Immobilien Jena
Am Anger 26
07743 Jena

Tel.: 03641 49- 5190
E-Mail: bernhard.stro...@jena.de
Internet: www.kij.de


Kommunale Immobilien Jena
Eigenbetrieb der Stadt Jena
Werkleiter: Karl-Hermann Kliewe


__ Information from ESET Mail Security, version of virus signature 
database 19326 (20190509) __

The message was checked by ESET Mail Security.
http://www.eset.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] Why was selection tool behaviour changed in 3.x?

[Bernhard Ströbl]

sts.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

--
Marco Bernasocchi
QGIS.org Co-chair
ma...@opengis.ch <mailto:ma...@opengis.ch>
+41 (0)79 467 24 70 

OPENGIS.ch Logo <https://www.opengis.ch>


__ Information from ESET Mail Security, version of virus 
signature database 19173 (20190410) __


The message was checked by ESET Mail Security.
http://www.eset.com

'�z�Zr�r^�)�j[p��Z��'~��zJ&�W����{^��iק




--
Bernhard Ströbl
Anwendungsbetreuer GIS

Kommunale Immobilien Jena
Am Anger 26
07743 Jena

Tel.: 03641 49- 5190
E-Mail: bernhard.stro...@jena.de
Internet: www.kij.de


Kommunale Immobilien Jena
Eigenbetrieb der Stadt Jena
Werkleiter: Karl-Hermann Kliewe


__ Information from ESET Mail Security, version of virus signature 
database 19176 (20190411) __

The message was checked by ESET Mail Security.
http://www.eset.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] Zoom to selected point (if only one point is selected)

[Bernhard Ströbl]

Hi Andreas,
I filed a ticket for this very problem a couple of years ago:
https://issues.qgis.org/issues/9160

Bernhard

Am 24.10.2018 um 10:27 schrieb Andreas Neumann:

Hi,

Given a layer with POINT geometries, if only one point is selected, QGIS
doesn't zoom to this point, but only pans to the point so that the point
is in the center of the map canvas.

Now, I know that a single point does not have a dimension - but I still
think that the current behavious is not user friendly.

As an example: if your zoom level is at the whole dataset (many
kilometers wide), and QGIS only pans to that single point, it is almost
impossible to find that point.

How can we solve this issue? Here are my ideas:

a) QGIS points to a fraction (say 1%) of the overall width of all layers
in the project and uses that 1% width and pans to the point

b) The user can define a map scale that QGIS should use when zooming to
that single point

c) a combination of a) and b): if b) is set in the project, use the
setting, if not set, use the mechanism of a)

What are you thoughts?

Thanks,
Andreas


__ Information from ESET Mail Security, version of virus signature 
database 18265 (20181024) __

The message was checked by ESET Mail Security.
http://www.eset.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





__ Information from ESET Mail Security, version of virus signature 
database 18265 (20181024) __

The message was checked by ESET Mail Security.
http://www.eset.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] mirroring qgis.org repos

[Bernhard Ströbl]

Hi Richard,

nocache.qgis.org did the trick for us

thank you for your effort
Bernhard

Am 05.06.2018 um 12:22 schrieb Richard Duivenvoorde:

On 05-06-18 09:54, Richard Duivenvoorde wrote:

On 05-06-18 09:31, Jürgen E. Fischer wrote:

Hi Bernhard,

On Tue, 05. Jun 2018 at 08:29:09 +0200, Bernhard Ströbl wrote:

has anything changed recently? We have -again- since several days problems
mirroring ubuntugis locally:

debmirror --dist=xenial --section=main --arch=i386,amd64 --cleanup
--host=qgis.org --root=ubuntugis-ltr --method=https --rsync-extra=none
/mirrorpath
fails with 403 both via http and https


Odd.  With wget and a browser I can get
https://qgis.org/ubuntugis-ltr/dists/xenial/Release.

But I can reproduce with debmirror.   I works when when I use nocache.qgis.org
instead of qgis.org.

Looks like a cloudflare issue.


Using myself here (adding -v -debug).


Did some more testing, and it is definitly a cloudflare issue.
If I disable caching on qgis.org temporarily it works.

But if I use a silly (googled) perl script which mimics the perl lines
from debmirror:

# Create a user agent object
use LWP::UserAgent;
my $ua = LWP::UserAgent->new;
my $res = $ua->mirror(
'https://anonym...@qgis.org/ubuntugis-ltr/dists/xenial/Release',
'/tmp/Release' );
# Check the outcome of the response
if ($res->is_success) {
 print $res->content;
}
else {
 print $res->status_line, "\n";
}

it also(!) just works...
Tried to set the ssl_verification to false, other headers, but I could
not make debmirror work.

We cannot remove cache from qgis.org (as we generate too much web
traffic then, and our services really become slower)

You could use https://nocache.qgis.org ?

I prefer to keep ubuntu.qgis.org cached too, unless others have problems
with it too..

Sorry I cannot be of more help.

Regards,

Richard



__ Information from ESET Mail Security, version of virus signature 
database 17500 (20180605) __

The message was checked by ESET Mail Security.
http://www.eset.com






__ Information from ESET Mail Security, version of virus signature 
database 17501 (20180605) __

The message was checked by ESET Mail Security.
http://www.eset.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] mirroring qgis.org repos

[Bernhard Ströbl]

Hi Richard, hi group,

has anything changed recently? We have -again- since several days 
problems mirroring ubuntugis locally:


debmirror --dist=xenial --section=main --arch=i386,amd64 --cleanup 
--host=qgis.org --root=ubuntugis-ltr --method=https --rsync-extra=none 
/mirrorpath

fails with 403 both via http and https

Bernhard


__ Information from ESET Mail Security, version of virus signature 
database 17500 (20180605) __

The message was checked by ESET Mail Security.
http://www.eset.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] QGIS 3 Crash Updating Digitalizing Tool

[Bernhard Ströbl]

Hi Antonio,

whilst Nyall is totally right I am still reading here, too. I would 
appreciate if you file a ticket so we can shift the discussion there. 
The stack trace doesn't tell me anything, I am afraid.


thank you

Bernhard

Am 21.05.2018 um 01:00 schrieb Nyall Dawson:

On 19 May 2018 at 15:24, Antonio Di Lecce  wrote:


h2. User Feedback

It's happen when I try to update Digitizing Tools



Digitizing tools is a 3rd party plugin - you need to report all issues
to the plugin author, not the QGIS project:

https://github.com/bstroebl/DigitizingTools/issues

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





__ Information from ESET Mail Security, version of virus signature 
database 17424 (20180522) __

The message was checked by ESET Mail Security.
http://www.eset.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] mirroring qgis.org repos

[Bernhard Ströbl]

Hi Richard,

thank you for your answer. Our goal is the same as two years ago: We 
want to mirror the repo locally, i.e. we want to see all the files.


This command currently works:
debmirror --dist=xenial --section=main --arch=i386,amd64 --cleanup 
--host=144.76.174.102 --root=ubuntugis-ltr --method=http --rsync-extra=none


BUT:
1) if the IP changes we will have to call again
2) if http is shut off we cannot access via https because the SSL 
certificate does not contain the address 144.76.174.102 (certificate 
verification fails)


regards
Bernhard


Am 02.01.2018 um 14:01 schrieb Richard Duivenvoorde:


Hi Bernhard,

Can you provide some more information on what you exactly want to see?

http://ubuntu.qgis.org ?

That one was still pointing to our old server (which since... I think 3
weeks does not have a webserver running anymore).

I let it point to our new qgis2 server now (144.76.174.102).
(note that this one is NOT being cached by cloudflare, so I doubt it is
'the same problem' as earlier)

And I see now:
http://ubuntu.qgis.org/ubuntugis/
which is a repo.

Fixed like this?

Sorry for the inconvenience.

Regards,

Richard Duivenvoorde


On 02-01-18 09:20, Bernhard Ströbl wrote:


Hi,
I wish everybody a good start in 2018!

We have -again- a problem mirroring the QGIS repos locally, see [1]. The
ubuntu subdomain is not accessible anymore and going directly to
qgis.org results in the same error as two years ago.

best regards

Bernhard

[1]
http://lists.osgeo.org/pipermail/qgis-developer/2016-January/041107.html


__ Information from ESET Mail Security, version of virus
signature database 16667 (20180102) __

The message was checked by ESET Mail Security.
http://www.eset.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




__ Information from ESET Mail Security, version of virus signature 
database 16669 (20180102) __

The message was checked by ESET Mail Security.
http://www.eset.com





--
Bernhard Ströbl
Anwendungsbetreuer GIS

Kommunale Immobilien Jena
Am Anger 26
07743 Jena

Tel.: 03641 49- 5190
E-Mail: bernhard.stro...@jena.de
Internet: www.kij.de


Kommunale Immobilien Jena
Eigenbetrieb der Stadt Jena
Werkleiter: Karl-Hermann Kliewe


__ Information from ESET Mail Security, version of virus signature 
database 16669 (20180102) __

The message was checked by ESET Mail Security.
http://www.eset.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

[QGIS-Developer] mirroring qgis.org repos

[Bernhard Ströbl]

Hi,
I wish everybody a good start in 2018!

We have -again- a problem mirroring the QGIS repos locally, see [1]. The 
ubuntu subdomain is not accessible anymore and going directly to 
qgis.org results in the same error as two years ago.


best regards

Bernhard

[1] http://lists.osgeo.org/pipermail/qgis-developer/2016-January/041107.html


__ Information from ESET Mail Security, version of virus signature 
database 16667 (20180102) __

The message was checked by ESET Mail Security.
http://www.eset.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] Authentication seems broken in master

[Bernhard Ströbl]

Hi Andreas,
I was under the impression that the qgis-auth.db is supposed to reside 
at $HOME/.local/share/QGIS/QGIS3/profiles/default because that is where 
QGIS3 recently installed plugins (a while ago indeed it was 
$HOME/.qgis3). I just copied my qgis-auth.db from $HOME/.qgis2 to 
$HOME/.local/share/QGIS/QGIS3/profiles/default and get "Auth db query 
exec() FAILED", too, upon opening options-cAuthentication


Bernhard

Am 02.11.2017 um 15:18 schrieb Andreas Neumann:

Hi Alessandro,

Already at the start of QGIS I get two times the error message:

WARNING: Auth db query exec() FAILED

WARNING: Auth db query exec() FAILED

This happens during startup of QGIS without any user interaction.

I had a look at the permissions of $HOME/.qgis3/qgis-auth.db - and they
seem fine to me.

Perhaps, if I/we can fix this, the other subsequent error message go
away as well?

Thanks,

Andreas


On 2017-11-02 15:04, Alessandro Pasotti wrote:


On Thu, Nov 2, 2017 at 2:54 PM, Andreas Neumann mailto:a.neum...@carto.net>> wrote:

Hi Alessandro,

Thank you for your reply.

I don't know what I need to do to fix the auth-db issues. I keep
getting tons of error messages like

Auth DB query exec failed()

for existing connections.

This is for access through the GUI, not through Python.

Also, when I try to create a new auth config entry, it doesn't
know my master password anymore and can't create a new one. Pretty
broken currently.

Does this mean that my auth-db is corrupt and that I need to
remove it and create a new one?



I've honestly no idea: it is not broken for me, I'm using the auth
manager right now on master with no issues and the authmanager tests
are all green (and there are quite a few).

I suggest you to file a bug report with some more details that can
help to reproduce the issue.

Thanks!



Thanks for your reply,

Andreas

On 2017-11-02 14:38, Alessandro Pasotti wrote:


On Thu, Nov 2, 2017 at 2:19 PM, Andreas Neumann
mailto:a.neum...@carto.net>> wrote:

Same for me. Very annoying.

Bernhard please file a ticket and assign it to Alessandro
or Luigi.

Thanks,



Andreas


Hi,

the API has changed and the singleton has been removed.

Auth manager instance is now accessible through the
QgsApplication as QgsApplication.authManager()

Please file a ticket for filling the API break document that
the lazy coder forgot to do (blame on him!).

btw, the lazy coder did not forget to fill the API break
document for the `get` removal, see

https://qgis.org/api/api_break.html#qgis_api_break_3_0_QgsAuthManager
<https://qgis.org/api/api_break.html#qgis_api_break_3_0_QgsAuthManager>


On 2017-11-02 14:05, Bernhard Ströbl wrote:

Hi all,

I cannot convince freshly compiled current master 1ffc3fd
to save an authentication database.
Furthermore the Python access to QgsAuthManager via
QgsAuthManager.instance() seems broken, too:
"type object 'QgsAuthManager' has no attribute 'instance'"

Both already worked in a former version (compiled about 2 weeks ago)

any hints?
shall I file tickets?

regards
Bernhard


__ Information from ESET Mail Security, version of virus 
signature database 16343 (20171102) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
<mailto:QGIS-Developer@lists.osgeo.org>
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
<https://lists.osgeo.org/mailman/listinfo/qgis-developer>
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
<https://lists.osgeo.org/mailman/listinfo/qgis-developer>



___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
<mailto:QGIS-Developer@lists.osgeo.org>
List info:
https://lists.osgeo.org/mailman/listinfo/qgis-developer
<https://lists.osgeo.org/mailman/listinfo/qgis-developer>
Unsubscribe:
https://lists.osgeo.org/mailman/listinfo/qgis-developer
<https://lists.osgeo.org/mailman/listinfo/qgis-developer>




--
Alessandro Pasotti
w3:   www.itopen.it <http://www.itopen.it>





--
Alessandro Pasotti
w3:   www.itopen.it <http://www.itopen.it>







__ Information from ESET Mail Security, v

Re: [QGIS-Developer] Authentication seems broken in master

[Bernhard Ströbl]

Hi Andreas,
thanks for your feedback.
Ticket filed.
Bernhard

Am 02.11.2017 um 14:19 schrieb Andreas Neumann:

Same for me. Very annoying.

Bernhard please file a ticket and assign it to Alessandro or Luigi.

Thanks,

Andreas

On 2017-11-02 14:05, Bernhard Ströbl wrote:


Hi all,

I cannot convince freshly compiled current master 1ffc3fd to save an
authentication database.
Furthermore the Python access to QgsAuthManager via
QgsAuthManager.instance() seems broken, too:
"type object 'QgsAuthManager' has no attribute 'instance'"

Both already worked in a former version (compiled about 2 weeks ago)

any hints?
shall I file tickets?

regards
Bernhard




__ Information from ESET Mail Security, version of virus signature 
database 16344 (20171102) __

The message was checked by ESET Mail Security.
http://www.eset.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

[QGIS-Developer] Authentication seems broken in master

[Bernhard Ströbl]

Hi all,

I cannot convince freshly compiled current master 1ffc3fd to save an 
authentication database.
Furthermore the Python access to QgsAuthManager via 
QgsAuthManager.instance() seems broken, too:

"type object 'QgsAuthManager' has no attribute 'instance'"

Both already worked in a former version (compiled about 2 weeks ago)

any hints?
shall I file tickets?

regards
Bernhard


__ Information from ESET Mail Security, version of virus signature 
database 16343 (20171102) __

The message was checked by ESET Mail Security.
http://www.eset.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] Editable CSV files

[Bernhard Ströbl]

Hi Stefan,

although I do not know very much about this topic I wonder how this is 
solved with other file-based data sets, e.g. shape. Furthermore I would 
not limit csv to Excel. I normally use an editor for csv (and sometimes 
LibreOffice). The editor does not lock the file but offers to refresh it 
if it has been changed on disk. LO does lock the file, so no concurrent 
editing is possible.


Bernhard

Am 19.07.2017 um 08:23 schrieb Stefan Keller:

Hii Andreas

I think this is particularly a Windows issue. For Linux it could be
implemented such that files are'nt write locked to other programs.
Background is how to solve the problem of concurrent editing (a file).
Just unlocking the file implies some problems of this type on how to
"inform" the other client to refresh?
A proper solution would be to implement a bidirectional communication
between Excel and QGIS - similar to how GISconnector for Excel (and
ArcGIS) did it.
Unfortunately Excel needs to be programmed in VBA :-(

:Stefan

2017-07-19 7:45 GMT+02:00 Andreas Neumann :

Hi,

Is there a particular technical reason why csv/text files aren't editable in
QGIS? Or is this mainly for historical reasons and it could be implemented
as editable with reasonable effort?

I know that there is a plugin called "Editable GeoCSV" - but shouldn't this
be supported by QGIS in general, without the need for a plugin?

I'd be willing to financially support such an improvement in QGIS core,
should a developer be interested in working on it.

Thanks,

Andreas

___



__ Information from ESET Mail Security, version of virus signature 
database 15770 (20170719) __

The message was checked by ESET Mail Security.
http://www.eset.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] Value entry using comma as decimal separator?

[Bernhard Ströbl]

Hi,
just my two cents: My users are working in a German administration and 
they depend on QGIS having a German UI. They will be puzzled if they are 
supposed to use a point instead of the regular komma as decimal 
separator. On the other hand they won't expect "5.5" to be a regular 
entry into a decimal field either.


Bernhard

Am 08.07.2017 um 09:58 schrieb Richard Duivenvoorde:

On 08-07-17 01:11, Nyall Dawson wrote:


It's a trivial change to make to get the spin boxes to accept the
local decimal separator, but this would prevent users entering "5.5"
in those locales.

Can someone from one of these affected regions let me know what the
correct behavior should be? I don't want to make the change if it
breaks entry of 5.5 and that's the standard used in those locales.


My personal view:

In The Netherlands we also use comma as a decimal separator (don't most
european countries do?), and though I never use the Dutch locale myself,
I know ALL governmental organisations I've been run the Dutch
QGIS/localse just because Windows there is in Dutch (and set the Dutch
locale).

I also know in the Spreadsheet world this gives A LOT of trouble because
most average users are not even aware what 'locale' they are using... So
people sending a us-locale spreadsheet to a dutch-locale user is often
in trouble

This makes for example so that in modern Banking web applications they
check and you can use both , and . as decimal separator (probably there
is some heuristic in which they check:
- if there is only one type of separator
- if there is one, and it is just 2 position from the end
- it is used as decimal separator
etc etc
But... that is easier when you are only doing currency numbers...

I would not try to fight this locale war, or try to be smarter then
Qt/Windows:
IF people use a 'comma'-locale, they should use comma.
IF they do not like that: use us-locale

It is the same problem with the character encoding in shapefiles. People
are not aware of what they do, but 'we' as part of the Qt or Windows
should not try to be smarter then that world we are part of.

Untill the rest of the world come to their senses and start using the
comma as separator, use 24hr clocks (well preferably 100...), meters,
kilograms etc etc...

Regards,

Richard Duivenvoorde
___
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





__ Information from ESET Mail Security, version of virus signature 
database 15722 (20170710) __

The message was checked by ESET Mail Security.
http://www.eset.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] Split parts tool - invalid output

[Bernhard Ströbl]

Giovanni,
I know you did not target at me :-)
I wanted to express that I would prefer to be able to implement this in 
C++ myself but instead of having nothing I tried to make a workaround in 
Python.


regards
Bernhard

Am 21.06.2017 um 12:44 schrieb Giovanni Manghi:

Hi Bernhard, thanks for the answer


I would definitely wish to have proper tools in core but as I am not a
C++ guy all I can do is implement things in a Python plugin :-(
DigitizingTools is an effort to provide missing tools until there is a
solution in core (I just abandoned a tool whose functionality has been
implemented). I welcome any C++ dev going ahead and copying (and
improving) the tools I provide.
You may have seen that I commented on [1]



my message wasn't targeted to you, but rather a small rant... what I
meant is that is someone (you) had to "fix" this editing tool with a
plugin it really means that the core one has an issue (and indeed it
has it).

cheers!

-- 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






__ Information from ESET Mail Security, version of virus signature 
database 15619 (20170621) __

The message was checked by ESET Mail Security.
http://www.eset.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] Split parts tool - invalid output

[Bernhard Ströbl]

Hi Giovanni

Am 20.06.2017 um 14:18 schrieb Giovanni Manghi:

Hi,



Hi,

I would like to raise attention for an issue which was discussed in
length in the qgis-users list [1]

You can ignore the beginning of the discussion where I mixed up "Split
parts" and "Split features".

The split features tool does not produce valid geometries. This can be
easily reproduced by splitting one part of a multipart feature and
then try to split that part again (or save and check the feature with
e.g. postgis' st_isvalid()). This goes hand-in-hand with the comments
in a related, older issue [2].

This makes the workflow much more complex [see 3], if you want to have
a valid output at the end.

The discussion ended in a new Tool in the DigitizingTools (0.11.0)
plugin (thank you Bernhard), which acts much more intuitive from a
users' perspective.
- singlepart features are split and one half inserted as a new feature
- multipart features are split and the user has to choose which part
gets inserted as a new feature, while the other half stays a multipart
feature with all other parts still connected

This raises the question if and how to get that to replace the core tools.

Happy for any input :)




is strange this thread is seemingly not getting much traction at least
in the dev list. Having a core digitizing tool that cripples
geometries do not look good to me, and apparently a good solution has
been implemented (or had to) in a plugin. Isn't worth having core
doing it the right way?


cheers

-- G --


I would definitely wish to have proper tools in core but as I am not a 
C++ guy all I can do is implement things in a Python plugin :-( 
DigitizingTools is an effort to provide missing tools until there is a 
solution in core (I just abandoned a tool whose functionality has been 
implemented). I welcome any C++ dev going ahead and copying (and 
improving) the tools I provide.

You may have seen that I commented on [1]

Bernhard

[1] https://issues.qgis.org/issues/12754


__ Information from ESET Mail Security, version of virus signature 
database 15614 (20170620) __

The message was checked by ESET Mail Security.
http://www.eset.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] [Processing] how to handle selections

[Bernhard Ströbl]

of course, I see. I was under the impression that apart from honoring 
the option by using the method you would not run into problems if the 
api changes.

Bernhard

Am 19.01.2017 um 10:47 schrieb Victor Olaya:

hmm, not a bad idea, but it is actually very easy to do that using
standard QGIS methods (you can see how simple the fix i made is). The
advantage of vector.features is that it honors the option setting,
without the developer having to take care of that.

Cheers



2017-01-19 10:43 GMT+01:00 Bernhard Ströbl :

Hi Victor,

what do you think about enhancing processing's vector.features with an
additional optional flag that returns the selection no matter if the option
is set or not?

Bernhard


Am 19.01.2017 um 10:35 schrieb Victor Olaya:


Good catch

I fixed it and now it uses the selected features, regardless of the
config parameter. The change is in 2.18 and master branches

Thanks!

2017-01-18 10:44 GMT+01:00 Bernhard Ströbl :


Hi all,
processing sports the "Save selected features" algorithm. However if in
processing's options you untick "Use only selected features" the
algorithm
outputs _all_ features of the input layer. Although I know that
processing
works only on selections when the option is ticked IMHO the current
behaviour is not intuitive: if an algorithm in its name (and help) claims
to
do something with the selected features it should do that _all the time_.
Opinions?

Background: I opened a PR [1] yesterday for an algorithm that works on
selected features all the time (won't make sense otherwise) and would
like
processing to be consistent in that respect.

regards

Bernhard

[1] https://github.com/qgis/QGIS/pull/4011


__ Information from ESET Mail Security, version of virus
signature
database 14787 (20170118) __

The message was checked by ESET Mail Security.
http://www.eset.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




__ Information from ESET Mail Security, version of virus signature
database 14793 (20170119) __

The message was checked by ESET Mail Security.
http://www.eset.com






__ Information from ESET Mail Security, version of virus signature
database 14793 (20170119) __


The message was checked by ESET Mail Security.
http://www.eset.com





__ Information from ESET Mail Security, version of virus signature 
database 14793 (20170119) __

The message was checked by ESET Mail Security.
http://www.eset.com






__ Information from ESET Mail Security, version of virus signature 
database 14793 (20170119) __

The message was checked by ESET Mail Security.
http://www.eset.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] [Processing] how to handle selections

[Bernhard Ströbl]

Hi Victor,

what do you think about enhancing processing's vector.features with an 
additional optional flag that returns the selection no matter if the 
option is set or not?


Bernhard

Am 19.01.2017 um 10:35 schrieb Victor Olaya:

Good catch

I fixed it and now it uses the selected features, regardless of the
config parameter. The change is in 2.18 and master branches

Thanks!

2017-01-18 10:44 GMT+01:00 Bernhard Ströbl :

Hi all,
processing sports the "Save selected features" algorithm. However if in
processing's options you untick "Use only selected features" the algorithm
outputs _all_ features of the input layer. Although I know that processing
works only on selections when the option is ticked IMHO the current
behaviour is not intuitive: if an algorithm in its name (and help) claims to
do something with the selected features it should do that _all the time_.
Opinions?

Background: I opened a PR [1] yesterday for an algorithm that works on
selected features all the time (won't make sense otherwise) and would like
processing to be consistent in that respect.

regards

Bernhard

[1] https://github.com/qgis/QGIS/pull/4011


__ Information from ESET Mail Security, version of virus signature
database 14787 (20170118) __

The message was checked by ESET Mail Security.
http://www.eset.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



__ Information from ESET Mail Security, version of virus signature 
database 14793 (20170119) __

The message was checked by ESET Mail Security.
http://www.eset.com






__ Information from ESET Mail Security, version of virus signature 
database 14793 (20170119) __

The message was checked by ESET Mail Security.
http://www.eset.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

[Qgis-developer] [Processing] how to handle selections

[Bernhard Ströbl]

Hi all,
processing sports the "Save selected features" algorithm. However if in 
processing's options you untick "Use only selected features" the 
algorithm outputs _all_ features of the input layer. Although I know 
that processing works only on selections when the option is ticked IMHO 
the current behaviour is not intuitive: if an algorithm in its name (and 
help) claims to do something with the selected features it should do 
that _all the time_.

Opinions?

Background: I opened a PR [1] yesterday for an algorithm that works on 
selected features all the time (won't make sense otherwise) and would 
like processing to be consistent in that respect.


regards

Bernhard

[1] https://github.com/qgis/QGIS/pull/4011


__ Information from ESET Mail Security, version of virus signature 
database 14787 (20170118) __

The message was checked by ESET Mail Security.
http://www.eset.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] QGIS menu item

[Bernhard Ströbl]

What I was trying to say is that many applications have a "File" menu at 
the first position. As QGIS is not really following that scheme (because 
the menu is named "Project" and I totally agree with not having it 
renamed to "File") I support your idea of the QGIS menu.


Bernhard

Am 10.01.2017 um 09:15 schrieb Nathan Woodrow:

File was renamed to Project for a few reasons, mainly for better context
awareness and external non file based projects.  No plans to change that
as I think that works well.


On Tue, 10 Jan 2017 6:11 pm Bernhard Ströbl mailto:bernhard.stro...@jena.de>> wrote:

Hi Nathan,

I think the original idea was to have something like a "File" menu, that
many applications have, too. Although it is not named "File". Anyway
IMHO it is a good idea, because many users get general and project's
settings mixed up and I would not favor renaming "Project" to "File"
either.
Going into detail: shouldn't "Project Properties..." go into the
"Project" menu then (and be renamed to "Properties")?
"Snapping Options..." are currently placed in settings, but are a
project's setting. Should go in the "Project" menu then, too.

Bernhard

Am 10.01.2017 um 04:11 schrieb Nathan Woodrow:
> Hey all,
>
> I would like to propose a new QGIS menu item that in the menu
before the
> Project item.  This menu item will contain all the stuff in the
Settings
> Menu, Exit QGIS, and some of the stuff from the Help menu like About
>
> Motivation:  A lot of application have a "Application" menu with
> application-wide settings, etc . I think this would make it clear that
> anything in this menu is related to the application itself and not the
> project.  Having a Settings menu just floating in the middle of
the menu
> bar seems strange to me now.
>
> Example
>
> Inline image 1
>
> Thoughts?
>
> - Nathan
>
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org <mailto:Qgis-developer@lists.osgeo.org>
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>



__ Information from ESET Mail Security, version of virus
signature database 14743 (20170110) __

The message was checked by ESET Mail Security.
http://www.eset.com


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





__ Information from ESET Mail Security, version of virus signature 
database 14743 (20170110) __

The message was checked by ESET Mail Security.
http://www.eset.com


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

Re: [Qgis-developer] QGIS menu item

[Bernhard Ströbl]

Hi Nathan,

I think the original idea was to have something like a "File" menu, that 
many applications have, too. Although it is not named "File". Anyway 
IMHO it is a good idea, because many users get general and project's 
settings mixed up and I would not favor renaming "Project" to "File" 
either.
Going into detail: shouldn't "Project Properties..." go into the 
"Project" menu then (and be renamed to "Properties")?
"Snapping Options..." are currently placed in settings, but are a 
project's setting. Should go in the "Project" menu then, too.


Bernhard

Am 10.01.2017 um 04:11 schrieb Nathan Woodrow:

Hey all,

I would like to propose a new QGIS menu item that in the menu before the
Project item.  This menu item will contain all the stuff in the Settings
Menu, Exit QGIS, and some of the stuff from the Help menu like About

Motivation:  A lot of application have a "Application" menu with
application-wide settings, etc . I think this would make it clear that
anything in this menu is related to the application itself and not the
project.  Having a Settings menu just floating in the middle of the menu
bar seems strange to me now.

Example

Inline image 1

Thoughts?

- Nathan


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





__ Information from ESET Mail Security, version of virus signature 
database 14743 (20170110) __

The message was checked by ESET Mail Security.
http://www.eset.com


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

Re: [Qgis-developer] When to start converting our plugins?

[Bernhard Ströbl]

Hi Tom,

would be great to have your and anybody else's experiences and how tos 
available for reference by then. Is there a website where people can 
contribute?


Bernhard

Am 06.01.2017 um 00:23 schrieb Tom Chadwin:

Nyall Dawson wrote

I'd say just before/after feature freeze.


Sounds sensible. Any ideas on how long between beginning of feature freeze
and release? Could be *a lot* of plugin devs pleading for help from QGIS
devs.

Thanks again

Tom






__ Information from ESET Mail Security, version of virus signature 
database 14724 (20170106) __

The message was checked by ESET Mail Security.
http://www.eset.com


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

Re: [Qgis-developer] Processing NG/V2 - brainstorming

[Bernhard Ströbl]

Hi Nayll and all,

my ideas are more from a user's perspective and from that point of view 
I like your first idea most which (hopefully) increases performance and 
improves the output.


Moreover I would like to add the following ideas
1) Selection: It would be cool to integrate QGIS' expression builder 
into processing so when using the "Select by expression" algorithm 
instead of typing the expression one could use expression builder to 
have it created (no field names available, of course, if used in a model).


2) Filter: Select features (e.g. by expression) and process both the 
features that match the expression _and_ those that don't in seperate 
branches of a model.


Bernhard

Am 05.12.2016 um 10:03 schrieb Nyall Dawson:

Hi all,

I've recently been informally chatting about possible enhancements to
processing with a few QGIS team members, and I thought it'd be worth
starting a public brainstorm about these ideas.

This is really just "thinking aloud" about what the next logical steps
are for processing and how we can make it more competitive against
programs like FME.

So here we go... a bunch of random ideas on future processing enhancements:


1. Rework native algorithms to avoid layer input/outputs

(Full credit goes to Matthias here). One current inefficiency with
processing models is that every step is exported to a file based
format, which is then reread in for the next algorithm. This means
that a simple set of steps like buffer->reproject involves multiple
conversions from OGR formats to QgsFeature/QgsGeometry and back to the
OGR output format, when it could be simplified to just two operations
on a QgsFeature's geometry and then a final write to disk. In addition
to the inefficiency here we also lose things like long field names and
full support for z/m/curves (depending on the intermediate file
format).

So... how to address this... Matthias came up with the idea that
native processing algs could accept a feature iterator instead of an
input layer, and themselves be a feature iterator. This effectively
would make a processing model a chain of iterators which features are
"pulled" through from a final writer step. Ie, the source
layer->buffer->save to layer->load layer->reproject->save to layer
model becomes:

a writer
-> which reads features from the iterator provided a transform alg
-> which reprojects the geometry from features provided by a buffer
alg's output iterator
-> which buffers the geometry on features from an iterator from the
original source layer

(Obviously, anytime a non-native algorithm (eg saga/grass/ogr) is used
then the features would need to be written to disk first. But this is
no different to the current behaviour so there shouldn't be any extra
cost incurred.)

This gets a little trickier when we want to multithread something, eg.
2 input layers-> each buffered -> intersection of the two. But we
could handle this by using a form of "pipe" iterator, which sucks in
features as fast as possible from its input iterator and stores them
in one thread, and then an algorithm in another thread consumes these
features as they become available. Ie:

thread a:
input layer 1 iterator -> buffer 1 alg iterator -> "pipe" iterator a ->


thread c: intersection alg
thread b:
input layer 2 iterator -> buffer 2 alg iterator  -> "pipe" iterator b ->

where thread c reads the features from "pipe iterator a" and "b" as
they become available, and then does its processing on them.

(hope that makes sense!)

2. Georeferenced geometries

I think for the approach in 1 to work we'd also need to introduce the
concept of "referenced" geometries. This would basically be
QgsGeometry + a QgsCoordinateReferenceSystem. It would allow retrieval
of a geometry's CRS without requiring any knowledge of its source
layer (or where no layer exists, eg the canvas extent as a geometry).

I've pondered several approaches to this, such as:
- QgsReferencedFeature (QgsFeature + crs): This doesn't work for
non-feature based geometries or allow features with multiple
geometries in different CRSes. (See
https://github.com/qgis/qgis3.0_api/issues/21).
- QgsReferencedGeometry: subclass of QgsGeometry with a CRS member.
This approach would avoid adding any extra overhead to QgsGeometry.
But given that the main use of QgsGeometry (geometry attached to a
feature from a layer) will always have a CRS associated, this seems
like it unnecessarily complicates the API.

So my current preference would be for QgsGeometry to gain a
QgsCoordinateReferenceSystem member variable, which is an invalid crs
if the geometry is not referenced. This should still be quite
lightweight given that QgsCoordinateReferenceSystem is implicitly
shared.


3. Porting components of processing to core

There's demand (from eg QField) to reuse parts of processing outside of PyQGIS.

I think good candidates for porting to core would be:
- parameters
- inputs
- the algorithm base class

In addition to allowing use outsid

Re: [Qgis-developer] About QGIS-*.DMP files in Temp folder on Windows

[Bernhard Ströbl]

Hi,
just a notice: I experience crashes while zooming if geometries are 
invalid. As soon as I fix them the crashes stop.


Setting: Geometries from PostGIS with ST_IsValid(geometry) = false, QGIS 
2.* 64bit on Win7

So it could be worth to check your data.

Bernhard

Am 09.11.2016 um 21:37 schrieb Jonathan Moules:

Hi,
Have you reported it to the bug tracker -  https://hub.qgis.org/issues -
That's the best way to report this sort of behaviour. While I can see
why a dmp file would be useful, no program should be leaving GB of dump
files behind.

Maybe it should clean up when there are more than x number?

Cheers,
Jonathan

On 09/11/2016 11:28, Geo DrinX wrote:

Good morning,


purging my PC,  I found 1595  files named   "qgis-*.dmp"  in my Temp
folder.

Totally, they amount to 36 giga of space  :(

For example, I have many of:

myUSER\AppData\Local\Temp\qgis-20140915-160805-11200-8480-c3a2817.dmp

each of 23 mega.


So, for each quitting of QGIS since 2.18  from  september 05 2014  I
had a crash (also without any plugin installed).

Also, randomically I had crashes.

So, now I am deleting these files, to have space sufficent in my PC to
work.


I hope this can be sufficient for you to start a good debug of this
problem, that I have reported more than once.

If you need, I can share that files with you (also if I don't know how).


Best regards

Geo



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




__ Information from ESET Mail Security, version of virus
signature database 14417 (20161109) __

The message was checked by ESET Mail Security.
http://www.eset.com


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






__ Information from ESET Mail Security, version of virus signature 
database 14419 (20161110) __

The message was checked by ESET Mail Security.
http://www.eset.com


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

Re: [Qgis-developer] Let's clean up hub.qgis.org

[Bernhard Ströbl]

Paolo,

I have moved the open tickets to github and updated metadata on 
plugins.qgis.org accordingly. Plugins' metadata.txt files will be 
updated with the next relaese of the respective plugin.


thanks

Bernhard

Am 24.08.2016 um 08:15 schrieb Paolo Cavallini:

Il 24/08/2016 07:40, Denis Rouzaud ha scritto:

Same with Item Browser and qSearch!


On 08/24/2016 07:38 AM, Bernhard Ströbl wrote:

Hi Paolo,

how can I remove the projects I created? I didn't find any button to
do that on hub.
If I cannot do that myself you may remove DataDrivenInputMask and
DigitizingTools now.


I can do that, whan you confirm all the good info has been safely moved
elsewhere, and metadata updated.
Thanks a lot.





__ Information from ESET Mail Security, version of virus signature 
database 14009 (20160824) __

The message was checked by ESET Mail Security.
http://www.eset.com


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

Re: [Qgis-developer] Let's clean up hub.qgis.org

[Bernhard Ströbl]

Hi Paolo,

how can I remove the projects I created? I didn't find any button to do 
that on hub.
If I cannot do that myself you may remove DataDrivenInputMask and 
DigitizingTools now.


best regards

Bernhard

Am 23.08.2016 um 23:06 schrieb Paolo Cavallini:

Hi all,
we are currently busy migrating the good old redmine to a new
infrastructure. We intend, for various reasons, to migrate only the data
for the main application. We would therefore appreciate if you could
move your projects (mostly plugins, some extra stuff) to another
platform of your choice, remove the project from hub, and update
metadata.txt on plugins.qgis.org accordingly.
Do not hesitate asking in case you need assistance.
All the best.





__ Information from ESET Mail Security, version of virus signature 
database 14009 (20160824) __

The message was checked by ESET Mail Security.
http://www.eset.com


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

Re: [Qgis-developer] featureID changed to row number

[Bernhard Ströbl]

Hi Matthias,

thanks for the hint. I was guessing that it was connected to a mapping 
for bigint primary keys Jürgen talked about the other day. Hmm, will 
have to rethink if I can avoid bigint PKs.


Bernhard

Am 09.08.2016 um 11:02 schrieb Matthias Kuhn:

Hi Bernhard,

The behavior has been changed only for 64bit signed integers in QGIS 2.16.

Details here:

https://github.com/qgis/QGIS/pull/3036


Regards,
Matthias

On 08/08/16 15:47, Bernhard Ströbl wrote:

Hi all,

in former versions QGIS' featureID used to be indentical with the
primary key value of a PostGIS layer (if the field was an integer or
similar)
Now (QGIS 2.16.1) the featureID seems to be identical with the row number
My questions:
1) has this been changed by intention?
2) If yes - why?
3) if yes - since when (version)?

Please enlight me

regards

Bernhard



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





__ Information from ESET Mail Security, version of virus signature 
database 13932 (20160809) __

The message was checked by ESET Mail Security.
http://www.eset.com


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

[Qgis-developer] featureID changed to row number

[Bernhard Ströbl]

Hi all,

in former versions QGIS' featureID used to be indentical with the 
primary key value of a PostGIS layer (if the field was an integer or 
similar)

Now (QGIS 2.16.1) the featureID seems to be identical with the row number
My questions:
1) has this been changed by intention?
2) If yes - why?
3) if yes - since when (version)?

Please enlight me

regards

Bernhard

--
Bernhard Ströbl
Anwendungsbetreuer GIS

Kommunale Immobilien Jena
Am Anger 26
07743 Jena

Tel.: 03641 49- 5190
E-Mail: bernhard.stro...@jena.de
Internet: www.kij.de


Kommunale Immobilien Jena
Eigenbetrieb der Stadt Jena
Werkleiter: Karl-Hermann Kliewe


__ Information from ESET Mail Security, version of virus signature 
database 13927 (20160808) __

The message was checked by ESET Mail Security.
http://www.eset.com


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

Re: [Qgis-developer] QGIS for INSPIRE

[Bernhard Ströbl]

Hi Patrick,

I did part of what you listed in my Plugin DataDrivenInputMask (Python), 
only available for PostGIS, though. Source code and documentation are on 
github.
The plugin provides suitable widgets for any supported data type (e.g. 
date, boolean, arrays types). You might also want to look at how NULL 
values are handled (if field has no NOT NULL constraint). Furthermore 
any relation type (1:1, 1:n, n:1 and n:m) is supported.


Bernhard

Am 06.07.2016 um 16:27 schrieb Patrick Valsecchi:

Hi,

We (titellus and camptocamp) are going to start working on adding a few
functionalities needed for INSPIRE to QGIS core.  Before starting, we’d
like to tell the community what we plan to do (maybe, some are optional)
and give a chance to everybody to comment.


-

Advanced attribute types support
-

   Add support for viewing/editing maps (key/value) and arrays
   -

  Usage of native type for postgis
  -

  Usage of string representation for sqlite (for example JSON)
  -

   Add a few expression functions for accessing those types:
   array_get(idx), array_length, array_join(separator) / dict_get(key), etc
   -

   Add a few function to search in those types: array_search(),
   dict_search()
   -

   Detect a date column and use the proper widget for editing those
   -

   Same for other types
   -

   Allow plugins to provide custom widgets for specific types
   automatically.
   -

Fix bug where null dates are shown as the current time instead of null
in forms and saved like that, even for features that are not modified
-

Custom types widgets, per type
-

Auto discover database joins:
-

   Add FK (Foreign Key) discovery to the postgis and spatialite specific
   code.
   -

   Improve QGIS when creating relations according to the FK in the DB:
   view existing relations in the DB and select those to add
automatically to
   the project.
   -

   Improve QGIS when creating joins in layers according to the FK in the
   DB: view existing relations with the current layer and select
those to add
   automatically.


If somebody is already working on one of those features or is having
recommendations/comments/questions, please tell us.

Is there any point that would require a QEP?

Thanks



__ Information from ESET Mail Security, version of virus signature 
database 13760 (20160706) __

The message was checked by ESET Mail Security.
http://www.eset.com




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





__ Information from ESET Mail Security, version of virus signature 
database 13783 (20160711) __

The message was checked by ESET Mail Security.
http://www.eset.com


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

Re: [Qgis-developer] Possible plugin licensing problems

[Bernhard Ströbl]

As far as I understood the recent plugin licensing discussion on this 
list a plugin importing qgis.core or qgis.gui (or OS-pyQt) needs to be 
licenced compatible to GPL2, so even in a private repository a plugin 
author cannot claim a plugin to be for private use only(?). One could of 
course publish a limited-use plugin under GPL and sell the full blown 
plugin, but as it has to be GPL, too, after some sales it might be 
available for download somewhere.

Please correct me if I am wrong.

Bernhard

Am 26.05.2016 um 08:41 schrieb Paolo Cavallini:

It has been submitted, not approved pending our decision.
Thanks.

Il 26 maggio 2016 08:37:20 CEST, Andreas Neumann  ha 
scritto:

Hi Paolo,

Is this in our main public plugin repository?

I think we shouldn't have such plugins in our main repository. If it is

in a private repository, there is not much we can do, probably.

Andreas

On 26.05.2016 08:07, Paolo Cavallini wrote:

Hi all,
I'm unsure this is acceptable for us:
===
Please know that this Plugin is for own use purpose/evaluation but

not

for commercial. If you need it for commercial purpose please contact
***, and I will refer you to our marketing team to buy the commercial
*** key. At the same time, the non-commercial also has limitation on
number of calls and points.
===
Opinions?
Thanks.


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




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





__ Information from ESET Mail Security, version of virus signature 
database 13547 (20160526) __

The message was checked by ESET Mail Security.
http://www.eset.com


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

[Qgis-developer] no icons for plugin

[Bernhard Ströbl]

Hi all,

I experience singular bug reports [1], [2] about icons for my plugin 
DigitizingTools not showing. Is anybody aware of some misconfiguration 
in the plugin or at the user's that may cause these problems?


regards

Bernhard

[1] http://hub.qgis.org/issues/14503
[2] http://hub.qgis.org/issues/14825


__ Information from ESET Mail Security, version of virus signature 
database 13506 (20160518) __

The message was checked by ESET Mail Security.
http://www.eset.com


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

Re: [Qgis-developer] PostGIS queries slow when in edit mode

[Bernhard Ströbl]

Hi Manuel,

instead of developping a new plugin my plugin DataDrivenInputMask [1] 
might suit your needs. It handles all kinds of relations and referential 
integrity out of the box (if thoroughly defined in the DB). Tickets, 
feedback, feature requests welcome.


Bernhard

[1] http://plugins.qgis.org/plugins/DataDrivenInputMask/


Am 11.04.2016 um 10:30 schrieb Manuel Hernández Martínez:

Hi, Andreas, thanks for your help.
We tried the built-in relation support, combined with the edit widgets and form 
view. Is that what you mean? Powerful features as they are, they don’t fit our 
needs, however. There are quite a few tables, with two-level relationships; the 
generated forms and the workflow using the built-in solution is still too 
complex for our digitizers daily work. We also had doubts regarding to how to 
handle referential integrity constraints in edit mode. That’s why we finally 
decided to build our own plugin.
In any case, I have taken a look at it again; it feels somewhat slower than our 
solution when not editing, and roughly the same in edit mode (no measures, 
though, just my first subjective impressions).

De: Neumann, Andreas [mailto:a.neum...@carto.net]
Enviado el: viernes, 08 de abril de 2016 16:02
Para: Manuel Hernández Martínez
CC: 'qgis-developer@lists.osgeo.org'
Asunto: Re: [Qgis-developer] PostGIS queries slow when in edit mode


Hi Manuel,

QGIS already has built-in relation support (1:n and n:m) - they should support 
server side queries. Do you really need to write your own plugin? Are the 
built-in relations not good enough?

Andreas

On 2016-04-08 15:26, Manuel Hernández Martínez wrote:
Hi!
I'm developing a plugin for QGIS. When the user selects a feature, it queries a 
few other layers from Postgis to fill in a form with related data.
The queries are slow, unless I check the option to run queries server-side. 
After that, the queries run instantaneously. Yay!
However, if the layers are put in edit mode, the queries are slow again! :(
After checking the Postgis logs it seems that the run queries server-side 
option has no effect when the layers are in edit mode.
Does anyone know whether it is a known, well-founded limitation or a bug?

Regards, Manuel


Manuel Hernández Martínez
mhernand...@agenciamedioambienteyagua.es

Agencia de Medio Ambiente y Agua de Andalucía.
http://www.agenciamedioambienteyagua.es
Subdirección de Tecnologías de la Información.
Red de Información Ambiental de Andalucía, REDIAM.

Johan G. Gutenberg, 1. Isla de la Cartuja

41092 - SEVILLA, Sevilla. (Spain)



Tel:

+34 955 26 00 00 / +34 902 52 51 00

Fax:

+34 955 04 46 10





En la medida de lo posible, evite imprimir este correo.

Este correo electrónico y los documentos que en él se puedan adjuntar, contiene 
información de carácter confidencial dirigida exclusivamente a su/s 
destinatario/s. Si Usted no es el destinatario de este mensaje, le ruego que lo 
destruya sin hacer copia digital o física, comunicando por correo electrónico, 
fax o teléfono a la Agencia de Medio Ambiente y Agua de Andalucía la recepción 
del mismo. Así mismo, queda expresamente prohibida su divulgación, copia o 
distribución a terceros sin la previa autorización escrita de la Agencia de 
Medio Ambiente y Agua de Andalucía.




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





Hi, Andreas, thanks for your help.

We tried the built-in relation support, combined with the edit widgets
and form view. Is that what you mean? Powerful features as they are,
they don’t fit our needs, however. There are quite a few tables, with
two-level relationships; the generated forms and the workflow using the
built-in solution is still too complex for our digitizers daily work. We
also had doubts regarding to how to handle referential integrity
constraints in edit mode. That’s why we finally decided to build our own
plugin.

In any case, I have taken a look at it again; it feels somewhat slower
than our solution when not editing, and roughly the same in edit mode
(no measures, though, just my first subjective impressions).

*De:*Neumann, Andreas [mailto:a.neum...@carto.net]
*Enviado el:* viernes, 08 de abril de 2016 16:02
*Para:* Manuel Hernández Martínez
*CC:* 'qgis-developer@lists.osgeo.org'
*Asunto:* Re: [Qgis-developer] PostGIS queries slow when in edit mode

Hi Manuel,

QGIS already has built-in relation support (1:n and n:m) - they should
support server side queries. Do you really need to write your own
plugin? Are the built-in relations not good enough?

Andreas

On 2016-04-08 15:26, Manuel Hernández Martínez wrote:

Hi!

I'm developing a plugin for QGIS. When the user selects a f

Re: [Qgis-developer] Warning from DigitizingTools about CRS mismatch

[Bernhard Ströbl]

Hi,

it might be even easier to completely delete the prj file and either 
manually or by default set the layer's projection to the project's 
projection (as I understood they are both identical).


Bernhard

Am 09.04.2016 um 09:35 schrieb Bo Victor Thomsen:

A futher note..

The two projections 3044 and 25832 are *identical* regarding the proj4
parameterdefinitions in the srs.db database, so QGIS might get confused
when it opens a datasource, where the projection definition for the
datasource is based on proj4.

See
http://gis.stackexchange.com/questions/115690/difference-between-etrs89-etrs-tm32-and-etrs89-utm-zone-32n


You could do some kind of "cowboy" trick and remove the reference to
3044 from the srs.db database, table tbl_srs. The warnings from last
post still apply :-)

Regards

Bo Victor Thomsen
GIS & Database specialist
Municipality of Frederikssund, Denmark

Den 08/04/16 kl. 13:27 skrev Casper Børgesen (CABO):

Hi Bernhard

I do follow your suggestions and they make perfectly sense. This is a
warning and I can probably safely disregard it in this case. I'm more
curious to discover why two computers using the same OS and QGIS
version seems to handle the CRS difference differently. My initial
mail was not specifically directed at DigitizingTools but it is (from
the user point of view) the source of the warning.

What I suspect is that some setting somewhere, inside or outside QGIS,
might lead QGIS to behave differently - and I am curious to know :)


Regards Casper

-Original Message-
From: Bernhard Ströbl [mailto:bernhard.stro...@jena.de]
Sent: 8. april 2016 12:55
To: Casper Børgesen (CABO); qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] Warning from DigitizingTools about CRS
mismatch

Hi Casper,

I meant the CRS set in the layer's properties for the layer in question.
As you said both are using the same project so the project's CRS
should be the same in both cases.
In your first mail you state that the project's CRS is EPSG:25832 and
the layer's is EPSG:3044. There is the missmatch. Change this to
EPSG:25832 and all is fine. Check if the layer's CRS has been set to
EPSG:25832 on the working computer.
If the very same layer loads into the very same project with different
CRS on different machines then this is a question of QGIS in general
and has nothing to do with DigitizingTools (which is just pointing out
the difference).

Bernhard

Am 08.04.2016 um 12:43 schrieb Casper Børgesen (CABO):

Hi Bernhard

Since its the same QGIS project were opening on the different
computers, I would expect them to behave the same. The current CRS
(as stated in the bottom right of the QGIS window) is EPSG:25832 (OTF).

I tried replacing the PRJ file of problematic shape file with the PRJ
from the working shape file (see the first mail), but QGIS still
displays the warning.


Regards, Casper

-Original Message-
From: Bernhard Ströbl [mailto:bernhard.stro...@jena.de]
Sent: 8. april 2016 11:38
To: Casper Børgesen (CABO); qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] Warning from DigitizingTools about CRS
mismatch

Hi Casper,

no idea why they behave differently. Are the settings for the layer's
SRS on both machines the same?
As I wrote, the warning is shown if there is a missmatch in the
project's and the layer's SRS-id.

Bernhard

Am 08.04.2016 um 11:13 schrieb Casper Børgesen (CABO):

Hi Bernhard

Thanks for your answer.

Yes I know that QGIS tries hard to determine the SRS-id which
matches the values of the PRJ file. But my main issue is why it
displays the warning only on one computer and not the others (same
QGIS project with same data)?

Which mechanisms could trigger the difference in whether the warning
should be shown or not?

We are running QGIS 2.14.0 64 bit on Windows 7.


Regards Casper


-Original Message-
From: Qgis-developer [mailto:qgis-developer-boun...@lists.osgeo.org]
On Behalf Of Bernhard Ströbl
Sent: 8. april 2016 10:38
To: qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] Warning from DigitizingTools about CRS
mismatch

Hi Casper,

DigitizingTools compares _only_ the SRS-id (SRS =
SpatialReferenceSystem) of the project and the layer. If they
missmatch the warning is thrown so the user gets a hint why certain
functions are greyed out.
Thus relevant is not the prj file but the SRS assigned to the layer
and the project in their properties. To solve this issue: if they
share a common projection, go in the layer properties and choose the
same SRS as the project's from the list of projections.
Background (AFAIK): In Shapefiles the data do not carry information
on their SRS (like e.g. in PostGIS or gml). This information is
contained in the (optional) prj file. QGIS reads the prj file and
assigns the first matching SRS to the data (matching = definition is
identical). If there is none matching, a USER-SRS is created with
the projection information given in the

Re: [Qgis-developer] Warning from DigitizingTools about CRS mismatch

[Bernhard Ströbl]

Hi Casper,

I meant the CRS set in the layer's properties for the layer in question. 
As you said both are using the same project so the project's CRS should 
be the same in both cases.
In your first mail you state that the project's CRS is EPSG:25832 and 
the layer's is EPSG:3044. There is the missmatch. Change this to 
EPSG:25832 and all is fine. Check if the layer's CRS has been set to 
EPSG:25832 on the working computer.
If the very same layer loads into the very same project with different 
CRS on different machines then this is a question of QGIS in general and 
has nothing to do with DigitizingTools (which is just pointing out the 
difference).


Bernhard

Am 08.04.2016 um 12:43 schrieb Casper Børgesen (CABO):

Hi Bernhard

Since its the same QGIS project were opening on the different computers, I 
would expect them to behave the same. The current CRS (as stated in the bottom 
right of the QGIS window) is EPSG:25832 (OTF).

I tried replacing the PRJ file of problematic shape file with the PRJ from the 
working shape file (see the first mail), but QGIS still displays the warning.


Regards, Casper

-Original Message-----
From: Bernhard Ströbl [mailto:bernhard.stro...@jena.de]
Sent: 8. april 2016 11:38
To: Casper Børgesen (CABO); qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] Warning from DigitizingTools about CRS mismatch

Hi Casper,

no idea why they behave differently. Are the settings for the layer's SRS on 
both machines the same?
As I wrote, the warning is shown if there is a missmatch in the project's and 
the layer's SRS-id.

Bernhard

Am 08.04.2016 um 11:13 schrieb Casper Børgesen (CABO):

Hi Bernhard

Thanks for your answer.

Yes I know that QGIS tries hard to determine the SRS-id which matches the 
values of the PRJ file. But my main issue is why it displays the warning only 
on one computer and not the others (same QGIS project with same data)?

Which mechanisms could trigger the difference in whether the warning should be 
shown or not?

We are running QGIS 2.14.0 64 bit on Windows 7.


Regards Casper


-Original Message-
From: Qgis-developer [mailto:qgis-developer-boun...@lists.osgeo.org]
On Behalf Of Bernhard Ströbl
Sent: 8. april 2016 10:38
To: qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] Warning from DigitizingTools about CRS
mismatch

Hi Casper,

DigitizingTools compares _only_ the SRS-id (SRS =
SpatialReferenceSystem) of the project and the layer. If they missmatch the 
warning is thrown so the user gets a hint why certain functions are greyed out.
Thus relevant is not the prj file but the SRS assigned to the layer and the 
project in their properties. To solve this issue: if they share a common 
projection, go in the layer properties and choose the same SRS as the project's 
from the list of projections.
Background (AFAIK): In Shapefiles the data do not carry information on their 
SRS (like e.g. in PostGIS or gml). This information is contained in the 
(optional) prj file. QGIS reads the prj file and assigns the first matching SRS 
to the data (matching = definition is identical). If there is none matching, a 
USER-SRS is created with the projection information given in the prj file.

Bernhard

Am 08.04.2016 um 10:10 schrieb Casper Børgesen (CABO):

Hi!

I have a user who constantly get a yellow warning from QGIS when he enables 
editing on set of specific shape files. The message is:

DigitizingTools: Amend Line is disabled because layer CRS and project CRS do 
not match!

The project CRS is EPSG:25832. The shape file has the following .prj file:

PROJCS["ETRS_1989_UTM_Zone_32N",GEOGCS["GCS_ETRS_1989",DATUM["D_ETRS_
1
989",SPHEROID["GRS_1980",6378137.0,298.257222101]],PRIMEM["Greenwich"
,
0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Transverse_Mercat
o
r"],PARAMETER["False_Easting",50.0],PARAMETER["False_Northing",0.
0
],PARAMETER["Central_Meridian",9.0],PARAMETER["Scale_Factor",0.9996],
P ARAMETER["Latitude_Of_Origin",0.0],UNIT["Meter",1.0]]

In "layer properties/General/Coordinate reference system", QGIS displays "Selected 
CRS (EPSG: 3044, ETRS89 / ETRS-TM32".

If he enables editing on a shape file with the following .prj file, it doesn't 
happen:

PROJCS["ETRS89_UTM_zone_32N",GEOGCS["GCS_ETRS_1989",DATUM["D_ETRS_198
9
",SPHEROID["GRS_1980",6378137,298.257222101]],PRIMEM["Greenwich",0],U
N
IT["Degree",0.017453292519943295]],PROJECTION["Transverse_Mercator"],
P
ARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",9],PARA
M
ETER["scale_factor",0.9996],PARAMETER["false_easting",50],PARAMET
E R["false_northing",0],UNIT["Meter",1]]

The strange thing is that this only happens on his compu

Re: [Qgis-developer] Warning from DigitizingTools about CRS mismatch

[Bernhard Ströbl]

Hi Casper,

no idea why they behave differently. Are the settings for the layer's 
SRS on both machines the same?
As I wrote, the warning is shown if there is a missmatch in the 
project's and the layer's SRS-id.


Bernhard

Am 08.04.2016 um 11:13 schrieb Casper Børgesen (CABO):

Hi Bernhard

Thanks for your answer.

Yes I know that QGIS tries hard to determine the SRS-id which matches the 
values of the PRJ file. But my main issue is why it displays the warning only 
on one computer and not the others (same QGIS project with same data)?

Which mechanisms could trigger the difference in whether the warning should be 
shown or not?

We are running QGIS 2.14.0 64 bit on Windows 7.


Regards Casper


-Original Message-
From: Qgis-developer [mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf 
Of Bernhard Ströbl
Sent: 8. april 2016 10:38
To: qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] Warning from DigitizingTools about CRS mismatch

Hi Casper,

DigitizingTools compares _only_ the SRS-id (SRS =
SpatialReferenceSystem) of the project and the layer. If they missmatch the 
warning is thrown so the user gets a hint why certain functions are greyed out.
Thus relevant is not the prj file but the SRS assigned to the layer and the 
project in their properties. To solve this issue: if they share a common 
projection, go in the layer properties and choose the same SRS as the project's 
from the list of projections.
Background (AFAIK): In Shapefiles the data do not carry information on their 
SRS (like e.g. in PostGIS or gml). This information is contained in the 
(optional) prj file. QGIS reads the prj file and assigns the first matching SRS 
to the data (matching = definition is identical). If there is none matching, a 
USER-SRS is created with the projection information given in the prj file.

Bernhard

Am 08.04.2016 um 10:10 schrieb Casper Børgesen (CABO):

Hi!

I have a user who constantly get a yellow warning from QGIS when he enables 
editing on set of specific shape files. The message is:

DigitizingTools: Amend Line is disabled because layer CRS and project CRS do 
not match!

The project CRS is EPSG:25832. The shape file has the following .prj file:

PROJCS["ETRS_1989_UTM_Zone_32N",GEOGCS["GCS_ETRS_1989",DATUM["D_ETRS_1
989",SPHEROID["GRS_1980",6378137.0,298.257222101]],PRIMEM["Greenwich",
0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Transverse_Mercato
r"],PARAMETER["False_Easting",50.0],PARAMETER["False_Northing",0.0
],PARAMETER["Central_Meridian",9.0],PARAMETER["Scale_Factor",0.9996],P
ARAMETER["Latitude_Of_Origin",0.0],UNIT["Meter",1.0]]

In "layer properties/General/Coordinate reference system", QGIS displays "Selected 
CRS (EPSG: 3044, ETRS89 / ETRS-TM32".

If he enables editing on a shape file with the following .prj file, it doesn't 
happen:

PROJCS["ETRS89_UTM_zone_32N",GEOGCS["GCS_ETRS_1989",DATUM["D_ETRS_1989
",SPHEROID["GRS_1980",6378137,298.257222101]],PRIMEM["Greenwich",0],UN
IT["Degree",0.017453292519943295]],PROJECTION["Transverse_Mercator"],P
ARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",9],PARAM
ETER["scale_factor",0.9996],PARAMETER["false_easting",50],PARAMETE
R["false_northing",0],UNIT["Meter",1]]

The strange thing is that this only happens on his computer not on a couple of 
other machines we have tried on.

If there indeed is a CRS mismatch it make sense, but he is the only of our 
users experiencing this.


Regards, Casper








__ Information from ESET Mail Security, version of virus signature 
database 13303 (20160408) __

The message was checked by ESET Mail Security.
http://www.eset.com


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

Re: [Qgis-developer] Warning from DigitizingTools about CRS mismatch

[Bernhard Ströbl]

Hi Casper,

DigitizingTools compares _only_ the SRS-id (SRS = 
SpatialReferenceSystem) of the project and the layer. If they missmatch 
the warning is thrown so the user gets a hint why certain functions are 
greyed out.
Thus relevant is not the prj file but the SRS assigned to the layer and 
the project in their properties. To solve this issue: if they share a 
common projection, go in the layer properties and choose the same SRS as 
the project's from the list of projections.
Background (AFAIK): In Shapefiles the data do not carry information on 
their SRS (like e.g. in PostGIS or gml). This information is contained 
in the (optional) prj file. QGIS reads the prj file and assigns the 
first matching SRS to the data (matching = definition is identical). If 
there is none matching, a USER-SRS is created with the projection 
information given in the prj file.


Bernhard

Am 08.04.2016 um 10:10 schrieb Casper Børgesen (CABO):

Hi!

I have a user who constantly get a yellow warning from QGIS when he enables 
editing on set of specific shape files. The message is:

DigitizingTools: Amend Line is disabled because layer CRS and project CRS do 
not match!

The project CRS is EPSG:25832. The shape file has the following .prj file:

PROJCS["ETRS_1989_UTM_Zone_32N",GEOGCS["GCS_ETRS_1989",DATUM["D_ETRS_1989",SPHEROID["GRS_1980",6378137.0,298.257222101]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Transverse_Mercator"],PARAMETER["False_Easting",50.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",9.0],PARAMETER["Scale_Factor",0.9996],PARAMETER["Latitude_Of_Origin",0.0],UNIT["Meter",1.0]]

In "layer properties/General/Coordinate reference system", QGIS displays "Selected 
CRS (EPSG: 3044, ETRS89 / ETRS-TM32".

If he enables editing on a shape file with the following .prj file, it doesn't 
happen:

PROJCS["ETRS89_UTM_zone_32N",GEOGCS["GCS_ETRS_1989",DATUM["D_ETRS_1989",SPHEROID["GRS_1980",6378137,298.257222101]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",9],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",50],PARAMETER["false_northing",0],UNIT["Meter",1]]

The strange thing is that this only happens on his computer not on a couple of 
other machines we have tried on.

If there indeed is a CRS mismatch it make sense, but he is the only of our 
users experiencing this.


Regards, Casper






__ Information from ESET Mail Security, version of virus signature 
database 13303 (20160408) __

The message was checked by ESET Mail Security.
http://www.eset.com


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

Re: [Qgis-developer] QGIS PDF export options

[Bernhard Ströbl]

Hi,

just to add another thought: In the past I bypassed disable print 
settings in pdf documents by using a pdf viewer other than AdobeAcrobat 
Reader (gsView in that case) and thus was able to print. So setting 
flags does not necessarily mean that all pdf readers out there honor them.


Bernhard

Am 20.03.2016 um 11:14 schrieb Andreas Neumann:

Hi Magnus,

What you list below is a LOT of work and won't just "happen". You would
have to find a developer with profound PDF know-how to do the work.

Besides, some of your ideas even contradict with the values of the QGIS
project.

Why should the QGIS project encourage or include technology that:
- disables printing and
- disables content copy ?

I would be against having such technology in QGIS.

QGIS is about enabling content and technologies, not about disabling and
restricting the users rights.

Other stuff you list would be very useful to have. But as said, you
would have to get active to get it implemented. It won't just happen ...

Greetings,
Andreas

On 18.03.2016 16:31, johnrobot wrote:

Hi
I would like to see a few options when exporting a layout to PDF:

- PDF version, such as archive PDF/A-1a
- Support for layers/geospatial PDF as discussed in
https://hub.qgis.org/issues/9362
- Resolution, compression
- Password protection
- Disable printing
- Enable/disable content copy
- Fit window, fit visible etc.

Any thoughts? Should I open a ticket for each one of the above or a
general
ticket?

Regards,

Magnus



--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/QGIS-PDF-export-options-tp5257213.html

Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer


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




__ Information from ESET Mail Security, version of virus signature 
database 13209 (20160321) __

The message was checked by ESET Mail Security.
http://www.eset.com


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

Re: [Qgis-developer] Intersection of two lines design

[Bernhard Ströbl]

Hi,

I use QgsGeometry.intersection() and QgsGeometry.difference() in the 
DigitizingTools plugin (cutter/clipper) and I did never experience any 
errors in these functions no matter if the geometries share a vertex or 
not (neither during my tests nor during courses I gave nor in the bug 
tracker). So I wouldn't say this is generally true. I wonder, however, 
why it seems to be a problem in processing.


Bernhard

Am 17.03.2016 um 23:19 schrieb Maximilian Krambach:

Hi,

I've frequently stumbled upon the problem that several functions (like
geomentry().intersection(geometry2), geometry().touches(geometry2) only
return something useful if BOTH geometries have a vertex at the meeting
point (which is inherited from GEOS)

My expection: they do intersect or touch if they share space.
I am Getting: Only a result if they share at least a vertex.

This results in tools like geoprocessing:intersection or clip giving
strange/unintuitive outputs.

Is it a design decision or just never discussed? It could be solved
quite easily, (see https://hub.qgis.org/issues/14504#note-2)
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer





__ Information from ESET Mail Security, version of virus signature 
database 13197 (20160318) __

The message was checked by ESET Mail Security.
http://www.eset.com


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

Re: [Qgis-developer] save layer as dxf

[Bernhard Ströbl]

I opened a ticket: http://hub.qgis.org/issues/14506

Bernhard

Am 14.03.2016 um 10:33 schrieb Bernhard Ströbl:

Hi,

I decided to post this on the dev list and not on the user's list.
Problem description: task is to export a single layer to dxf, CRS of
both, the project and the layer is EPSG:25832 (units = metres). Using
layer - save as with dxf results in a dxf file with units = inches
(although exported coordinates are EPSG:25832 coordinates, i.e. units
should be metres). Digging into this I found the description on the ogr
side [1] explainig that the default is "English - Inches". To use other
units one needs to use a different header file. But there is no way to
tell QGIS to do so (except I am missing something). IMHO this behaviour
is very counterintuitive, leeds to wrong results and is not really
solveable from a user's point of view (change the header file being
installed with QGIS, or change the resulting dxf with an editor).

I see these possible solutions
1) delete this option completely as we now have the dxf export function
2) enable the user to choose a header file and use the default only if
left blank
3) automatically change all units in the resulting dxf file to the ones
used in the chosen CRS

I would opt for solution 3 if we do not follow solution 1

tested with QGIS 2.8.3 on Win7 and QGIS 2.14.0 on Ubuntu

is this worth a ticket?

Bernhard

[1] http://www.gdal.org/drv_dxf.html


__ Information from ESET Mail Security, version of virus
signature database 13173 (20160314) __

The message was checked by ESET Mail Security.
http://www.eset.com


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




__ Information from ESET Mail Security, version of virus signature 
database 13186 (20160316) __

The message was checked by ESET Mail Security.
http://www.eset.com


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

Re: [Qgis-developer] Aggregates within expression engine

[Bernhard Ströbl]

Hi,
just my 2 ct:
I agree with Paolo that normal users do not know SQL, on the other hand 
there might be users that do not know spreadsheet syntax either (e.g. me 
:) which spreadsheet BTW: Excel? LO? or do they use the same syntax? SQL 
would be a standardized approach (and is the syntax already used in QGIS 
expressions). On the other hand if it is possible to "click together" 
the expression it doesn't matter which syntax is used, good 
documentation and direct help is a must here. If you e.g. choose a SUM 
function a GROUP BY woould be added automatically at the end (if not 
already there)
SQL is used at so many places in QGIS: layer filters, labelling, 
rule-based renderer... I would not mix this with different syntax.


Bernhard

Am 16.03.2016 um 08:36 schrieb Paolo Cavallini:

Il 16/03/2016 08:30, Neumann, Andreas ha scritto:


Why do you think SQL aggregate syntax (e.g. as outlined
at http://www.postgresql.org/docs/9.5/interactive/functions-aggregate.html)
is a no-go? Can you explain this in detail? QGIS is much closer to a
database then it is to a spreadsheet - in fact for most serious QGIS
work you store your data in a SQL database.

It was my impression that QGIS tries to maintain expression syntax
compatible with SQL wherever possible. I think it would be a good thing.


Hi Andreas,
based on my lengthy experience with courses, I'm pretty sure SQL
commands are out of reach for most "normal" GIS users.
It is fine to have access to SQL for power users, but aggregate
functions should IMHO be available to anyone.
All the best.





__ Information from ESET Mail Security, version of virus signature 
database 13185 (20160316) __

The message was checked by ESET Mail Security.
http://www.eset.com


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

[Qgis-developer] [Processing] access output layer as QgsVectorLayer object

[Bernhard Ströbl]

Hi,

I am currently rewriting a processing alg. What I need is
- either a temporary layer (I could do that with QGIS Python api but 
wondered if there is a helper function for that)
- or (prefered) get the layer created by output (and modify it further) 
I cannot access it, this is my code:

output = self.getOutputFromName(self.OUTPUT)
writer = output.getVectorWriter(provider.fields(),
provider.geometryType(), inLayer.crs())
output.layer and writer.layer are both None

any help appreciated

Bernhard


__ Information from ESET Mail Security, version of virus signature 
database 13181 (20160315) __

The message was checked by ESET Mail Security.
http://www.eset.com


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

[Qgis-developer] save layer as dxf

[Bernhard Ströbl]

Hi,

I decided to post this on the dev list and not on the user's list.
Problem description: task is to export a single layer to dxf, CRS of 
both, the project and the layer is EPSG:25832 (units = metres). Using 
layer - save as with dxf results in a dxf file with units = inches 
(although exported coordinates are EPSG:25832 coordinates, i.e. units 
should be metres). Digging into this I found the description on the ogr 
side [1] explainig that the default is "English - Inches". To use other 
units one needs to use a different header file. But there is no way to 
tell QGIS to do so (except I am missing something). IMHO this behaviour 
is very counterintuitive, leeds to wrong results and is not really 
solveable from a user's point of view (change the header file being 
installed with QGIS, or change the resulting dxf with an editor).


I see these possible solutions
1) delete this option completely as we now have the dxf export function
2) enable the user to choose a header file and use the default only if 
left blank
3) automatically change all units in the resulting dxf file to the ones 
used in the chosen CRS


I would opt for solution 3 if we do not follow solution 1

tested with QGIS 2.8.3 on Win7 and QGIS 2.14.0 on Ubuntu

is this worth a ticket?

Bernhard

[1] http://www.gdal.org/drv_dxf.html


__ Information from ESET Mail Security, version of virus signature 
database 13173 (20160314) __

The message was checked by ESET Mail Security.
http://www.eset.com


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

Re: [Qgis-developer] Usability of searches

[Bernhard Ströbl]

Hi Paolo,

some comments below

Am 09.03.2016 um 11:11 schrieb Paolo Cavallini:

Hi all,

perhaps I'm missing something, but I find usability of current search
mechanism a bit cumbersome. AFAICT, to search a set of features, the
user should:
* select on the legend the layer to be searched
* open the attribute table
* select the Column filter button, selecting one column
* insert the condition
* click Apply
* click on Zoom to selection.
Alternatively, one can use the Select by expression tool.
Is there a more straightforward way?


Well, I normally use the select by expression button, which (obviously) 
saves a lot of clicks


I would suggest a simpler mechanism:
* click on a dedicated Search button
* select the layer to be searched from a dropdown of the layers in legend


I would vote against this because
1) it breaks with the standard behaviour "make layer active - press 
button for action with this layer" (information button, make-editable 
button...)

2) with many layers in the project you will hate it :-)


* show a form (with the dropdowns etc., as defined for the layer) where
the user can select or type (with autocompletion and automatic selection
of ranges) the search criteria
* automatically zoom to selected items.


I implemented these in my plugin DataDrivenInputMask (for PostGIS layers 
only) on a user request, and I use it a lot, so I reckon this would be 
interesting for other users (and data providers), too




Alternatively:
* add a Search entry for each layer, besides the Filter one, in the
legend > Right click.


+1 (a lot better than the universal search button and in line with e.g. 
the make-editable button)




Would this make sense?

All the best.



my 2 cents
Bernhard



__ Information from ESET Mail Security, version of virus signature 
database 13150 (20160309) __

The message was checked by ESET Mail Security.
http://www.eset.com


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

Re: [Qgis-developer] Processing algorithms and API breaks

[Bernhard Ströbl]

Hi,

I once improved an algorithm but rolled it back afterwards because of [1]
So I fear that users become frustrated easily if things break every now 
and then which has further disadvantages:

1) QGIS (processing) is perceived as being unreliable
2) there will be tickets to be coped with addressing these issues

Nevertheless I would vote in favor of the "aggressive approach" but this 
has to be clearly communicated.


Bernhard

[1] http://hub.qgis.org/issues/13502

Am 07.03.2016 um 09:39 schrieb Victor Olaya:

I would say that the "agrresive" approach (introducing API breaks
without waiting for next version) is a better option. Changes are
small and will be easy to adapt to (in most cases, it will happen that
an algorithm that changes is not used in any model, or just by a
handful of users). So the improvement-vs-annoyment ratio is high...

My 2 cents

2016-03-07 9:13 GMT+01:00 Alexander Bruy :

Hi all,

Processing, became an important part of QGIS. More and more users use it
and rely on it, especially when they developed their own models and scripts.
So we should keep Processing algorithms as stable as possible and don't
change their descriptions.

On other hand there are many bugreports and feature requests which require
changing algorithms description to be fixed/impelemented. This can be considired
as "API" break, as scripts and models which use affected algorithms
and were developed before such changes will not work. For example,
there were many
PR about fixing GRASS and SAGA algs, which change their descriptions. Time
from time we also fix bugs in native QGIS algs and also need to change
algorithm description, e.g. by replacing one parameter type with another or
adding new parameter.

I see only two solutions:
1. Postpone such changes for next major QGIS release when API break is
allowed. In this case all existing scripts/models will work. But we
should live
with bugs and without some features, even if fix already available and keep the
code of this fixes in sync with master until next major release.
2. Allow "API" breaks in Processing. In this case we create additional pressure
on the authors of 3rd party models/scripts and force them to follow Processing
changes and update their code accordingly.

What do you think, which approach we should choose?

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

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





__ Information from ESET Mail Security, version of virus signature 
database 13137 (20160307) __

The message was checked by ESET Mail Security.
http://www.eset.com


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

Re: [Qgis-developer] Questions/Suggestion on virtual layers

[Bernhard Ströbl]

Hi Hugo,

Am 03.03.2016 um 13:14 schrieb Hugo Mercier:

Hi,

Adding double quotes when the table name contains dots and is inserted
from the completion dialog would help, sure. Thanks for the feedback.


I would prefer to generally add double quotes (easier to code anyways :)


We can as well add something in the documentation about dots in the
query. But this is not specific to virtual layers. The same is true for
postgis / sqlite.


You are right but PostgreSQL e.g. is not case sensitive whereas the 
virtual layer's SQL is case sensitive (I have no idea if this is the 
same in sqlite)




I'll try to look at the documentation and small usability issues listed
in this thread soon.


thanks

Bernhard



On 03/03/2016 12:16, Bernhard Ströbl wrote:

Hi Andreas and all,

sorry to hijack your thread but my question is related as I am also
trying to evaluate the new feature virtual layer.

My first tests resulted in QGIS freezing upon clicking "Test" or "OK"
(2.14.0 on Ubuntu 14.04 64 bit). It finally turned up it was the layer's
names containing dots (e.g. "schema.table" as they come from PostGIS).
Double quoting any layer and field names containing dots solved this
issue. However I had joins containing field names with dots, too because
of the prefix I used ("table.") which could not be resolved but at least
threw an error on testing. So I would propose to at least add a notice
in the tooltip that if one runs into problems, double quoting layers'
and fields' names might solve issues. Better would be to already have
them double quoted if inserted from the pop-up list.
Should I open a ticket?

Very cool feature, though!

Bernhard


Am 02.03.2016 um 17:48 schrieb Neumann, Andreas:

Hi Hugo,

On 2016-03-02 17:17, Hugo Mercier wrote:


Hi Andreas,

On 02/03/2016 16:27, Neumann, Andreas wrote:


Hi,

I am experimenting with the virtual layers. They are quite cool!

I have some suggesions/questions:

1. It would be nice to have a preview of my query results. Currently it
is either it works - or not. If it works, but the results are wrong
you have to start from scratch. I would suggest that when you press
on the test button you would not only display "No error" or the
error message, but maybe the first 10 rows of the result.


True.
Note that you can also create a virtual layer using the DB Manager where
it can display the first rows of a query, as it is the case for other
databases.
I am not sure to love having these two very close but slightly different
dialogs. If anyone has a better idea in terms of usability, do not
hesitate to propose :)


Can one create new virtual layers in the DB manager? I know that I can
do queries on existing layers and load it as a new layer - but is this
the same thing like a virtual layer?


2. Updating the virtual layer: it would be really nice if I could
edit/improve on my virtual layers without having to start completely
from scratch. --> Oh - now I found out that if you select an
existing virtual layer and then use "Layer" --> "Add Layer" --> "Add
Virtual Layer", that you can refresh an existing virtual layer. This
is really not obvious. I think this is more a usability issue.


Yes ... I am more used to click on the addition icon, which makes it
more direct, but you are right, this is not perfect.


ah ok - the button works as "edit" if you have the layer selected. Maybe
then we should rename the tooltip from "Add Virtual Layer" to "Add or
Edit Virtual Layer"


An entry in the right-click menu ?


Yes - that was my first idea - to look for an entry in the layer context
menu. Of course this entry should only be there if it is a virtual
layer.


Edit - you can also use the drop down menu of the creation dialog to
switch between different virtual layer definitions, as mentioned by Yves


yes - now I found it - thanks!


3. it is not very obvious how you can reuse an already existing
geometry column. I discovered it by accident, that you can use
layer.geometry (regardless of the original name of the geometry
column), but I think that it is not obvious. A better hint in the
the tooltip would probably help.
Indeed it appears to be not documented.


This would just require an additional sentence in  the tooltip of the
Query panel, after the sentence "Any functions from SQLite or Spatialite
can then be used in the query.:

To add or access existing geometries of a table, you can use
"tablename.geometry", regardless of original geometry column's name.


4. Unique identifier column: If you join several tables, you often have
the issue that you need to create an artificial primary key. Could
we offer a preconfigured builtin pkey - something like a rowid  for
such cases?
Good point. An autoincremented id is already generated on the feature.
That may not be a problem to add a "rowid" column in that case.


That wo

Re: [Qgis-developer] Questions/Suggestion on virtual layers

[Bernhard Ströbl]

Hi Andreas and all,

sorry to hijack your thread but my question is related as I am also 
trying to evaluate the new feature virtual layer.


My first tests resulted in QGIS freezing upon clicking "Test" or "OK" 
(2.14.0 on Ubuntu 14.04 64 bit). It finally turned up it was the layer's 
names containing dots (e.g. "schema.table" as they come from PostGIS). 
Double quoting any layer and field names containing dots solved this 
issue. However I had joins containing field names with dots, too because 
of the prefix I used ("table.") which could not be resolved but at least 
threw an error on testing. So I would propose to at least add a notice 
in the tooltip that if one runs into problems, double quoting layers' 
and fields' names might solve issues. Better would be to already have 
them double quoted if inserted from the pop-up list.

Should I open a ticket?

Very cool feature, though!

Bernhard


Am 02.03.2016 um 17:48 schrieb Neumann, Andreas:

Hi Hugo,

On 2016-03-02 17:17, Hugo Mercier wrote:


Hi Andreas,

On 02/03/2016 16:27, Neumann, Andreas wrote:


Hi,

I am experimenting with the virtual layers. They are quite cool!

I have some suggesions/questions:

1. It would be nice to have a preview of my query results. Currently it
is either it works - or not. If it works, but the results are wrong
you have to start from scratch. I would suggest that when you press
on the test button you would not only display "No error" or the
error message, but maybe the first 10 rows of the result.


True.
Note that you can also create a virtual layer using the DB Manager where
it can display the first rows of a query, as it is the case for other
databases.
I am not sure to love having these two very close but slightly different
dialogs. If anyone has a better idea in terms of usability, do not
hesitate to propose :)


Can one create new virtual layers in the DB manager? I know that I can
do queries on existing layers and load it as a new layer - but is this
the same thing like a virtual layer?


2. Updating the virtual layer: it would be really nice if I could
edit/improve on my virtual layers without having to start completely
from scratch. --> Oh - now I found out that if you select an
existing virtual layer and then use "Layer" --> "Add Layer" --> "Add
Virtual Layer", that you can refresh an existing virtual layer. This
is really not obvious. I think this is more a usability issue.


Yes ... I am more used to click on the addition icon, which makes it
more direct, but you are right, this is not perfect.


ah ok - the button works as "edit" if you have the layer selected. Maybe
then we should rename the tooltip from "Add Virtual Layer" to "Add or
Edit Virtual Layer"


An entry in the right-click menu ?


Yes - that was my first idea - to look for an entry in the layer context
menu. Of course this entry should only be there if it is a virtual
layer.


Edit - you can also use the drop down menu of the creation dialog to
switch between different virtual layer definitions, as mentioned by Yves


yes - now I found it - thanks!


3. it is not very obvious how you can reuse an already existing
geometry column. I discovered it by accident, that you can use
layer.geometry (regardless of the original name of the geometry
column), but I think that it is not obvious. A better hint in the
the tooltip would probably help.
Indeed it appears to be not documented.


This would just require an additional sentence in  the tooltip of the
Query panel, after the sentence "Any functions from SQLite or Spatialite
can then be used in the query.:

To add or access existing geometries of a table, you can use
"tablename.geometry", regardless of original geometry column's name.


4. Unique identifier column: If you join several tables, you often have
the issue that you need to create an artificial primary key. Could
we offer a preconfigured builtin pkey - something like a rowid  for
such cases?
Good point. An autoincremented id is already generated on the feature.
That may not be a problem to add a "rowid" column in that case.


That would be cool to have.


5. What is the exact purpose of the "Embedded Layers" where you can
add/import/remove layers? I noticed that existing layers of the
project work anyway without adding/importing them first. Is the idea
that you can work on layers that aren't in the project?
Yes it is.
You can for example embed layers from the project, save the virtual
layer to a QLR and reload it in a new project, the referenced layers
would not need to be already loaded.
There may be some documentation needed as well here.


Maybe we could add another tooltip here, explaining that one can add
layers that are not in the project - and that you need to "embed
existing layers", if you want to save to a qlr and load it in a
different project.


Should I open feature request tickets for these or are there already
plans to address one or the other of the above issues?
Unfortunately, no plan yet.
Thanks for your tests and feedback !

Re: [Qgis-developer] mirroring ubuntugis repo

[Bernhard Ströbl]

Hi Richard,

thank you for your effort. ubuntu.qgis.org is working now

regards

Bernhard

Am 22.01.2016 um 18:58 schrieb Richard Duivenvoorde:

On 22-01-16 11:09, Bernhard Ströbl wrote:

Hi,

we are trying to mirror the ubuntugis repository so users can install
and update from this (inhouse) mirror.
However trying to mirror with "debmirror" a 403 error is returned.
Further analysis revealed that "CloudFlare" at qgis.org refuses
debmirror's user agent.

Question 1: bug or feature?
Question 2: if feature how can we convince debmirror to mirror the repo?


Hi Bernhard,

I enabled cloudflare recently to speed up docs.qgis.org and qgis.org
sites. I understand that CF is sometimes pickey with things...

We can 'circumvent' (that is in the Cloudflare interface I can tell to
not use cloudflare) them if we use a hostnames for purposes as this.

So ubuntu.qgis.org now is pointing to the same host as qgis.org, BUT
without going via cloudflare I think.

Can you please test and let me know if it works like this?

Then we can maybe best fix url's on download page too (plz do or remind
me if your test was successfull...)

Regards,

Richard Duivenvoorde



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





__ Information from ESET Mail Security, version of virus signature 
database 12920 (20160125) __

The message was checked by ESET Mail Security.
http://www.eset.com


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

[Qgis-developer] mirroring ubuntugis repo

[Bernhard Ströbl]

Hi,

we are trying to mirror the ubuntugis repository so users can install 
and update from this (inhouse) mirror.
However trying to mirror with "debmirror" a 403 error is returned. 
Further analysis revealed that "CloudFlare" at qgis.org refuses 
debmirror's user agent.


Question 1: bug or feature?
Question 2: if feature how can we convince debmirror to mirror the repo?

regards

Bernhard


__ Information from ESET Mail Security, version of virus signature 
database 12909 (20160122) __

The message was checked by ESET Mail Security.
http://www.eset.com


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

Re: [Qgis-developer] Authentification use from Python

[Bernhard Ströbl]

Hi Larry,

thanks for pointing these things out, however I am not sure how to continue.

My situation is as follows: I have some 100 users that connect to our 
central PostgreSQL DB. Most of them have a personal DB account granting 
them write access to certain tables. Keeping their password in a secure 
place is essential and I thus adviced them to not store it with QGIS nor 
to share projects that contain layers loaded with their personal 
account. The Authentication system seems to solve both problems.


However I have about 30 plugins for inhouse use that ease data access. 
Some of these plugins directly query the database for reporting. 
Furthermore I provide the plugin DataDrivenInputMask, that directly 
queries the DB, too. I use QtSql for that.


Security reasons in respect to PostgreSQL connections: Any Python plugin 
can currently access stored credentials either in QtSettings or in any 
loaded PostGIS layer, so accessing them through the authentication 
system is neither better nor worse from a user's perspective (IMHO) 
compared to the current (10+ years old) situation. Not providing access 
will increaese security, of course. So until the mentioned api is in 
place I would opt for only deprecating the direct access, maybe have the 
user allow access for the plugin (only once and store his answer in the 
auth-DB).


If direct access to PostgreSQL credentials cannot be granted it would be 
good if the future api could return a QtSqlDatabase object (which, of 
course, contains the credentials accessible through 
QtSqlDatabase.userName() and QtSqlDatabase.password() methods).


best regards

Bernhard

Am 12.01.2016 um 23:36 schrieb Larry Shaffer:

Hi Bernhard,

Please note that the Python support for direct access to the credentials
via the auth method config *may* be completely removed for security
reasons.

Ideally, the expansion of credentials within a given auth method config
would only be done within the core application and connection methods
(HTTP, etc.) would be offered through a Python API. In this way an
authcfg token can be passed in and the connection established without
access to credentials.

However, such support and an API are not currently available. It is
simple enough to add to QgsNetworkAccessManager for HTTP[S] connections,
but not so simple for other types of connections, e.g. database via a
library or client. Once completed this means a plugin would not be able
to access the credentials and pass them on to a different connection
method, e.g. Python HTTP lib, etc.

Once such an API is available (or even now, with some work), plugins
could be 'authorized' by the user for access to credentials using
revocable access tokens or signed/revokable certificates.

Until then, the continued Python access to the auth system credentials
means security is not good for the user. It should be considered for
deprecation or just complete removal in 2.14 release.

Regards,

Larry Shaffer
Dakota Cartography
Black Hills, South Dakota

QGIS Support/Development | Boundless
lshaf...@boundlessgeo.com <mailto:lshaf...@boundlessgeo.com>

On Tue, Jan 12, 2016 at 8:14 AM, Bernhard Ströbl
mailto:bernhard.stro...@jena.de>> wrote:

Hi Luigi,

many thanks! That was the key.

I now have

am = QgsAuthManager.instance()
myAuthMethodConfig = QgsAuthMethodConfig()
am.loadAuthenticationConfig(mykey,myAuthMethodConfig,True)
myAuthMethodConfig.configMap()


Bernhard


Am 12.01.2016 um 15:58 schrieb Luigi Pirelli:

Hi Bernhard

be inspired by Boundless qgis-geoserver-plugin


https://github.com/boundlessgeo/qgis-geoserver-plugin/blob/master/src/geoserverexplorer/gui/gsexploreritems.py#L502

I hope it's enough

cheers
Luigi Pirelli


**
* Boundless QGIS Support/Development: lpirelli AT boundlessgeo
DOT com
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Stackexchange:
http://gis.stackexchange.com/users/19667/luigi-pirelli
* GitHub: https://github.com/luipir
* Mastering QGIS:
https://www.packtpub.com/application-development/mastering-qgis

**


    On 12 January 2016 at 12:47, Bernhard Ströbl
mailto:bernhard.stro...@jena.de>> wrote:

Hi all,

my goal is that my users do not save their PostgreSQL
passwords in clear
text but that they use the new Authentification system to do
so. For my
plugins I would need access to the PostgreSQL username and
password, though.
Is this generally possible in spite of security
considerations as mentioned
in the QGEP? If yes, how would I do 

Re: [Qgis-developer] Authentification use from Python

[Bernhard Ströbl]

Hi Luigi,

many thanks! That was the key.

I now have

am = QgsAuthManager.instance()
myAuthMethodConfig = QgsAuthMethodConfig()
am.loadAuthenticationConfig(mykey,myAuthMethodConfig,True)
myAuthMethodConfig.configMap()


Bernhard

Am 12.01.2016 um 15:58 schrieb Luigi Pirelli:

Hi Bernhard

be inspired by Boundless qgis-geoserver-plugin

https://github.com/boundlessgeo/qgis-geoserver-plugin/blob/master/src/geoserverexplorer/gui/gsexploreritems.py#L502

I hope it's enough

cheers
Luigi Pirelli

**
* Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT com
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* GitHub: https://github.com/luipir
* Mastering QGIS:
https://www.packtpub.com/application-development/mastering-qgis
**


On 12 January 2016 at 12:47, Bernhard Ströbl  wrote:

Hi all,

my goal is that my users do not save their PostgreSQL passwords in clear
text but that they use the new Authentification system to do so. For my
plugins I would need access to the PostgreSQL username and password, though.
Is this generally possible in spite of security considerations as mentioned
in the QGEP? If yes, how would I do it?

what I have so far is:

am = QgsAuthManager.instance()
myAuthMethodConfig = am.availableAuthMethodConfigs()[mykey]
myAuthMethodConfig.configMap() # returns an empty dict :-(


QGIS 2.12.2

any help appreciated

regards

Bernhard

[1]
https://github.com/dakcarto/QGIS-Enhancement-Proposals/blob/auth-system/qep-14-authentication-system.rst


__ Information from ESET Mail Security, version of virus signature
database 12855 (20160112) __

The message was checked by ESET Mail Security.
http://www.eset.com


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



__ Information from ESET Mail Security, version of virus signature 
database 12856 (20160112) __

The message was checked by ESET Mail Security.
http://www.eset.com




--
Bernhard Ströbl
Anwendungsbetreuer GIS

Kommunale Immobilien Jena
Am Anger 26
07743 Jena

Tel.: 03641 49- 5190
E-Mail: bernhard.stro...@jena.de
Internet: www.kij.de


Kommunale Immobilien Jena
Eigenbetrieb der Stadt Jena
Werkleiter: Karl-Hermann Kliewe


__ Information from ESET Mail Security, version of virus signature 
database 12856 (20160112) __

The message was checked by ESET Mail Security.
http://www.eset.com


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

[Qgis-developer] Authentification use from Python

[Bernhard Ströbl]

Hi all,

my goal is that my users do not save their PostgreSQL passwords in clear 
text but that they use the new Authentification system to do so. For my 
plugins I would need access to the PostgreSQL username and password, 
though. Is this generally possible in spite of security considerations 
as mentioned in the QGEP? If yes, how would I do it?


what I have so far is:

am = QgsAuthManager.instance()
myAuthMethodConfig = am.availableAuthMethodConfigs()[mykey]
myAuthMethodConfig.configMap() # returns an empty dict :-(


QGIS 2.12.2

any help appreciated

regards

Bernhard

[1] 
https://github.com/dakcarto/QGIS-Enhancement-Proposals/blob/auth-system/qep-14-authentication-system.rst



__ Information from ESET Mail Security, version of virus signature 
database 12855 (20160112) __

The message was checked by ESET Mail Security.
http://www.eset.com


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

Re: [Qgis-developer] QGIS Web Client: WSGI search capabilities using multiple databases

[Bernhard Ströbl]

Hi,

workaround: use dblink to mirror the relations from the other dbs into 
the "main" db


Bernhard

Am 25.11.2015 um 22:03 schrieb Tony Pham:

Hi all,

For the WSGI Search capabilities on QGIS Web Client, is it possible to
establish search capabilities using multiple databases (i.e., tables
within multiple databases)?

I have QGIS projects which utilize different PostGIS databases and would
like to be able to list all the various databases in my qwc_connect.py
Python file but realize that the DB_CONN_STRING only allows for the
connection to a single database.

Has anyone employed or developed a workaround for this?

Regards,
-Tony


__ Information from ESET Mail Security, version of virus
signature database 12624 (20151125) __

The message was checked by ESET Mail Security.
http://www.eset.com


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





__ Information from ESET Mail Security, version of virus signature 
database 12626 (20151126) __

The message was checked by ESET Mail Security.
http://www.eset.com


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

Re: [Qgis-developer] Quick fixes and error communication for ftools

[Bernhard Ströbl]

Hi all,

Am 24.11.2015 um 11:01 schrieb Marco Hugentobler:

Hi Alessandro, Matthias

 >Is there no requirement for multi types?

Afaik, the problem for f-tools are not the multi types, but only the
geometry collections (containing geometries with different shape type).
In my experience, if geos returns a geometry collection, it usually
contains one 'expected' geometry and the others are slivers (@strk,
please correct me if wrong).


There *could* be another problem, too [1]: 2.5D geometries, although I 
did not investigate this it should be checked because users cannot see 
the difference between them and regular 2D geometries.


Bernhard

[1] http://hub.qgis.org/issues/13167



 >Based on what indicator should be chosen what to extract? Try polygons
first, if there are none try lines, if there are none take points?

One possibility would be to pass the expected shapetype (Point / Line /
Polygon) to the function and take the best candidate (e.g. longest line,
largest polygon area).

 >How much effort (in time) do you think is required to implement this fix?

Difficult to estimate. It seems straightforward to implement the
extraction function. Then it needs to be called by the f-tools
internally and be tested with a few examples. If unit tests are required
(as mentioned by Alessandro), this seems to be the most time consuming
task to me.

Regards,
Marco

On 24.11.2015 10:42, Matthias Kuhn wrote:

Hi Marco

Good to have your feedback, you probably know the problem best.

On 11/24/2015 09:28 AM, Marco Hugentobler wrote:

Hi

>ad issue 1: update fTools to warn users when some features cause
problems
>ad issue 2: quick fix fTools to convert geometry collections to
single geometry types

A function that takes a geometry type and extracts the longest line /
the largest polygon / the first point from the geometry collection
should be straightforward to do.


Is there no requirement for multi types?
Based on what indicator should be chosen what to extract? Try polygons
first, if there are none try lines, if there are none take points?



>These fixes/updates would be made available as fTools updates via
the plugin installer asap

If the fix does not take too long, we probably don't need a warning
at all.


How much effort (in time) do you think is required to implement this fix?

Regards,
Matthias



Regards,
Marco

On 23.11.2015 21:35, Anita Graser wrote:

Hi,

If you are following the psc list, you've probably seen the thread
discussing current shortcomings of ftools
(http://lists.osgeo.org/pipermail/qgis-psc/2015-November/003623.html)

In short, the key issues are:
1. When ftools encounter issues with certain features, warning
messages get written to the log but this is largely hidden from
users since they would actively have to actively monitor the log.
The problematic features are then missing from the results but this
is not always obvious.
2. The above issue is more common now (since 2.10) since underlying
libraries more often (and correctly so) produce geometry collections
as outputs. These geometry collections are not handled well by the
current ftools code which is much older.

To address these issues, the following suggestions have been made so
far:
ad issue 1: update fTools to warn users when some features cause
problems
ad issue 2: quick fix fTools to convert geometry collections to
single geometry types

For the warnings, there's already a first PR draft
https://github.com/qgis/QGIS/pull/2432 which needs to be fleshed out.

These fixes/updates would be made available as fTools updates via
the plugin installer asap.

If you have ideas how to handle this efficiently or have already
implemented code that addresses similar issues, let us know.

It would be good to have a quick discussion in order to be able to
provide improvements fast.

Best wishes,
Anita


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



--
Dr. Marco Hugentobler
Sourcepole -  Linux & Open Source Solutions
Weberstrasse 5, CH-8004 Zürich, Switzerland
marco.hugentob...@sourcepole.ch  http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee


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


--
Matthias Kuhn
OPENGIS.ch -https://www.opengis.ch
Spatial • (Q)GIS • PostGIS • Open Source


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



--
Dr. Marco Hugentobler
Sourcepole -  Linux & Open Source Solutions
Weberstrasse 5, CH-8004 Zürich, Switzerland
marco.hugent

Re: [Qgis-developer] Quick fixes and error communication for ftools

[Bernhard Ströbl]

Am 24.11.2015 um 10:47 schrieb Alessandro Pasotti:

2015-11-24 10:42 GMT+01:00 Matthias Kuhn mailto:matth...@opengis.ch>>:

Hi Marco

Good to have your feedback, you probably know the problem best.

On 11/24/2015 09:28 AM, Marco Hugentobler wrote:

Hi

>ad issue 1: update fTools to warn users when some features cause
problems
>ad issue 2: quick fix fTools to convert geometry collections to
single geometry types

A function that takes a geometry type and extracts the longest
line / the largest polygon / the first point from the geometry
collection should be straightforward to do.


Is there no requirement for multi types?
Based on what indicator should be chosen what to extract? Try
polygons first, if there are none try lines, if there are none take
points?


Hi,

I've had a quick look to this issue in Las Palmas, the multi-geom issue
doesn't seem particularly hard to fix,  a possible solution is to keep
only geometry types of the same (simple or multi) type of the original
layer, transforming the multi to simple and feeding the original fTools
with simple geometries.


Hi everybody,

maybe I am misstaken but I doubt it is that easy: If you intersect a 
line and a polygon layer you would expect a line layer as output, If you 
intersect two polygon layers the output could be polygons or lines 
(partially identical boundary) or points (only one identical boundary 
vertex) but you would expect polygons, wouldn't you?
So maybe the rule is: If both input layers are of the same type the 
output layer should be of this type, if both are of different type, 
output should be the lowest input type (low -> high = point -> line -> 
polygon).


Bernhard





>These fixes/updates would be made available as fTools updates via
the plugin installer asap

If the fix does not take too long, we probably don't need a
warning at all.


How much effort (in time) do you think is required to implement this
fix?

Regards,
Matthias



My  quick and dirty estimation is 4-5 days, Python tests included (the
tests are really not a an option in this case I guess).



--
Alessandro Pasotti
w3: www.itopen.it 


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





__ Information from ESET Mail Security, version of virus signature 
database 12614 (20151124) __

The message was checked by ESET Mail Security.
http://www.eset.com


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

Re: [Qgis-developer] Improving ftools geoprocessing tools

[Bernhard Ströbl]

What what be a suitable format? It should
1) support all geometry types needed
2) be fast
3) support spatial indices?
4) support long (unlimited) field names
5) support all necessary field types
6) store its data on local hd

anything else?

Bernhard

Am 22.10.2015 um 16:14 schrieb Victor Olaya:

shp is the default format for temp files, and as such it is used in
the modeler for intermediate results. That is, however, very easy to
change, so if we agree on any other format, it can be changed and set
as the default for Processing

2015-10-22 16:08 GMT+02:00 Bernhard Ströbl :

Hi Andreas,

AFAIK processing uses shp for in between results in a model, too. So if you
build a model you loose your fields, no matter which output format you
choose. IMHO it should therefore be considered to change processing's data
source. Maybe SpatialLite is an option? Users can still export to shp if
needed.

Bernhard



Am 22.10.2015 um 15:48 schrieb Andreas Neumann:


Bernhard,

I agree that these tools should be QGIS algorithms - maybe even ported
from another GIS (if feasible).

One major annoyance with fTools and some processing algorithms is that
reliance on ESRI shapefile as output. That way I always loose my columns
- or they are truncated to be meaningless. For that reason I often don't
use QGIS, but FME for analysis. Or try to do the processing with SQL in
Postgis.

If we renovate these algorithms in the vector menu we'd have to make
sure that the output could be any chosen vector format, or at least
supports geopackage/spatialite/postgres as output.

Andreas

On 22.10.2015 15:26, Bernhard Ströbl wrote:


IMHO all ftools should be replaced by native QGIS processing
algorithms. For "simple" users it may be not feasible (or not allowed)
to install additional software. Therefore native QGIS algorithms
should be improved to be fast, robust and offering choices the users
need (see recent discussion on dissolve)

Bernhard

Am 22.10.2015 um 15:13 schrieb Andreas Neumann:


If we'd replace the ftools (vector and raster menu) through processing.
What would replace them? Would we do research and see which of the
alternative processing providers provides best speed/reliability - if
there are multiple versions? It may be, that for Algorithm A, Saga works
best, whereas for algorithm B GRASS is better and for C GDAL or the QGIS
builtin in mechanism.

Andreas

On 22.10.2015 14:59, Victor Olaya wrote:


   * Why is the processing toolbox not an option for your users? (Do
you
require shortcuts (menu entries) to the tools? Is it the parameter
interface which is more fine-tuned? Missing functionality?)



If what you need is to have the tools in a menu, we have been
discussing that before, and the idea is to mantain the same menu
structure if the users wants that, but have the algorithms based on
Processing to avoid redundant (and more difficult to mantain) code. As
I said, this has already been discussed, but it is not yet
implemented. Maybe your funding could help us do it?

And if algorithms are not performant enough, it's clearly better to
put your effort in the Processing ones (which, in general, are just a
copy of the ftools ones), and have them exposed through the menus, as
explained above.

Regards



__ Information from ESET Mail Security, version of virus signature 
database 12448 (20151022) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Improving ftools geoprocessing tools

[Bernhard Ströbl]

Hi Andreas,

AFAIK processing uses shp for in between results in a model, too. So if 
you build a model you loose your fields, no matter which output format 
you choose. IMHO it should therefore be considered to change 
processing's data source. Maybe SpatialLite is an option? Users can 
still export to shp if needed.


Bernhard


Am 22.10.2015 um 15:48 schrieb Andreas Neumann:

Bernhard,

I agree that these tools should be QGIS algorithms - maybe even ported
from another GIS (if feasible).

One major annoyance with fTools and some processing algorithms is that
reliance on ESRI shapefile as output. That way I always loose my columns
- or they are truncated to be meaningless. For that reason I often don't
use QGIS, but FME for analysis. Or try to do the processing with SQL in
Postgis.

If we renovate these algorithms in the vector menu we'd have to make
sure that the output could be any chosen vector format, or at least
supports geopackage/spatialite/postgres as output.

Andreas

On 22.10.2015 15:26, Bernhard Ströbl wrote:

IMHO all ftools should be replaced by native QGIS processing
algorithms. For "simple" users it may be not feasible (or not allowed)
to install additional software. Therefore native QGIS algorithms
should be improved to be fast, robust and offering choices the users
need (see recent discussion on dissolve)

Bernhard

Am 22.10.2015 um 15:13 schrieb Andreas Neumann:

If we'd replace the ftools (vector and raster menu) through processing.
What would replace them? Would we do research and see which of the
alternative processing providers provides best speed/reliability - if
there are multiple versions? It may be, that for Algorithm A, Saga works
best, whereas for algorithm B GRASS is better and for C GDAL or the QGIS
builtin in mechanism.

Andreas

On 22.10.2015 14:59, Victor Olaya wrote:

  * Why is the processing toolbox not an option for your users? (Do
you
require shortcuts (menu entries) to the tools? Is it the parameter
interface which is more fine-tuned? Missing functionality?)


If what you need is to have the tools in a menu, we have been
discussing that before, and the idea is to mantain the same menu
structure if the users wants that, but have the algorithms based on
Processing to avoid redundant (and more difficult to mantain) code. As
I said, this has already been discussed, but it is not yet
implemented. Maybe your funding could help us do it?

And if algorithms are not performant enough, it's clearly better to
put your effort in the Processing ones (which, in general, are just a
copy of the ftools ones), and have them exposed through the menus, as
explained above.

Regards



__ Information from ESET Mail Security, version of virus signature 
database 12448 (20151022) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Improving ftools geoprocessing tools

[Bernhard Ströbl]

IMHO all ftools should be replaced by native QGIS processing algorithms. 
For "simple" users it may be not feasible (or not allowed) to install 
additional software. Therefore native QGIS algorithms should be improved 
to be fast, robust and offering choices the users need (see recent 
discussion on dissolve)


Bernhard

Am 22.10.2015 um 15:13 schrieb Andreas Neumann:

If we'd replace the ftools (vector and raster menu) through processing.
What would replace them? Would we do research and see which of the
alternative processing providers provides best speed/reliability - if
there are multiple versions? It may be, that for Algorithm A, Saga works
best, whereas for algorithm B GRASS is better and for C GDAL or the QGIS
builtin in mechanism.

Andreas

On 22.10.2015 14:59, Victor Olaya wrote:

  * Why is the processing toolbox not an option for your users? (Do you
require shortcuts (menu entries) to the tools? Is it the parameter
interface which is more fine-tuned? Missing functionality?)


If what you need is to have the tools in a menu, we have been
discussing that before, and the idea is to mantain the same menu
structure if the users wants that, but have the algorithms based on
Processing to avoid redundant (and more difficult to mantain) code. As
I said, this has already been discussed, but it is not yet
implemented. Maybe your funding could help us do it?

And if algorithms are not performant enough, it's clearly better to
put your effort in the Processing ones (which, in general, are just a
copy of the ftools ones), and have them exposed through the menus, as
explained above.

Regards
___
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




__ Information from ESET Mail Security, version of virus signature 
database 12448 (20151022) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] How should the dissolve tool in Processing work?

[Bernhard Ströbl]

Hi Victor,

Am 19.10.2015 um 17:46 schrieb Victor Olaya:

I think the best soultion would be to add an extra parameter with the
fields to keep and the stats for them, so if it's empty, it behaves as
it does now


Do you mean drop fields (as is now but in debate) or keep first value 
(as it used to be before)?




The trick here is that there is no support for a parameter such as
this (which should be entered in a table and probably internally
represented as a dict or array of tuples). Should be easy to implement
it using a string, but then a custom UI should be created, otherwise
it will be cumbersome to type in the parameter value


How would you enter the value? I could imagine a LineEdit where you 
input e.g. a comma-separated list of fields to keep and another one 
where you input a comma-separated list of the stats to apply? To apply 
several stats on one field you would need multiple entries in LineEdit1?


I will take care of moving the logic from Julie's plugin into
processing, and then work on the UI. Shouldn't take long, and I think
this will be a nice improvement


Would be nice to have. On the other hand there is a work-around by first 
applying "Statistics by categories" and then "Join attributes table". 
Would work on one field only because we lack an algorithm to rename or 
drop fields, if I am not misstaken.


Bernhard



Let me know if you have more ideas

2015-10-19 17:38 GMT+02:00 Matthias Kuhn :

Hi

On 10/19/2015 05:11 PM, Anita Graser wrote:

Hi Victor,

On Mon, Oct 19, 2015 at 1:15 PM, Victor Olaya  wrote:


Hi Anit
a

nice discussion you bring up
Shouldn't it behave like the ftools dissolve tool currently does?



Yes, it used to behave exactly like ftools still does. But the arguments
behind the latest changes to the script are that the (ftoos) behavior is not
what users expect.


The current behavior is not deterministic and therefore in the long run
probably not the most desirable behavior. Reading Bernhard's comments in the
issue, it's quite hard to improve without considerably extending parameter
handling in processing.

Best solution IMO:

  * Keep the current/old behavior for the moment
  * Add new parameter possibilities (e.g. a table/array of string (attribute
name) -> combobox (aggregate function) mappings)
  * Use the current behavior as default setting for fields where the
aggregate funtion is undefined

+ Full backwards compatibility
+ Full control (/as soon as it gets done)
+ One tool for one job (as opposed to "old dissolve" vs. "new dissolve"
tools)
- The default behavior may not be optimal (Can still be changed for 3.0 if
it's considered to be better)

-- Matthias

___
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



--
Bernhard Ströbl
Anwendungsbetreuer GIS

Kommunale Immobilien Jena
Am Anger 26
07743 Jena

Tel.: 03641 49- 5190
E-Mail: bernhard.stro...@jena.de
Internet: www.kij.de


Kommunale Immobilien Jena
Eigenbetrieb der Stadt Jena
Werkleiter: Karl-Hermann Kliewe


__ Information from ESET Mail Security, version of virus signature 
database 12434 (20151020) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] How should the dissolve tool in Processing work?

[Bernhard Ströbl]

hi Alexandre

Am 19.10.2015 um 14:21 schrieb Alexandre Neto:

Hi,

I think this is a bit of feature request, but I would say it should be
possible to have some control over the remaining attributes. Trimming
all attributes seems poor to me, but keeping the attributes with "first
attribute found" without informing the user it's also not good.


Harrissou Santanna mentioned the Dissolve with Stats Plugin.
That's the way ArgGIS does it, you can have stats or even
join/concatenate of the non-dissolved attributes.


Could you elaborate on that? Does it do stats for every suitable field? 
This would multiply the number of fields in the output, besides there 
could be problems with field names (dbf has 10 signs if I recall 
correctly) or can you choose the which field to run the stats on? How 
many fields?


Bernhard




Victor Olaya mailto:vola...@gmail.com>> escreveu no
dia seg, 19/10/2015 às 12:15:

Hi Anita

nice discussion you bring up

Shouldn't it behave like the ftools dissolve tool currently does?

2015-10-19 13:10 GMT+02:00 Anita Graser mailto:anitagra...@gmx.at>>:
 > Hi,
 >
 > I'm asking for your input on a discussion concerning the
Processing dissolve
 > tool here: http://hub.qgis.org/issues/13502
 >
 > How should it ideally work, i.e. how should the attributes of the
dissolved
 > features be treated? Given the current Processing limitations,
how should
 > the options look like?
 >
 > Thanks in advance! Best wishes
 > Anita
 >
 > ___
 > Qgis-developer mailing list
 > Qgis-developer@lists.osgeo.org
<mailto:Qgis-developer@lists.osgeo.org>
 > http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org <mailto: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



--
Bernhard Ströbl
Anwendungsbetreuer GIS

Kommunale Immobilien Jena
Am Anger 26
07743 Jena

Tel.: 03641 49- 5190
E-Mail: bernhard.stro...@jena.de
Internet: www.kij.de


Kommunale Immobilien Jena
Eigenbetrieb der Stadt Jena
Werkleiter: Karl-Hermann Kliewe


__ Information from ESET Mail Security, version of virus signature 
database 12430 (20151019) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] New API for labeling Engine?

[Bernhard Ströbl]

Hi Martin,

Am 24.09.2015 um 10:56 schrieb Martin Dobias:

Hi Tim

On Thu, Sep 24, 2015 at 4:20 PM, Tim Sutton mailto:t...@kartoza.com>> wrote:

Hi

Labelling raster cells would be awesome!


Indeed - identify tool or value tool are often not good enough when one
wants to investigate values of many cells.

Very nice to see labelling get some love! I could add my wish to
your list:

* allow canvas border to be treated as a labelling impediment to
prevent partial labels


If I understand your wish correctly, this is already possible: in vector
layer's properties - Labels page - click the upper-right button to open
(global) labeling engine configuration - uncheck "Show partial labels".


Will this work in QGIS server, too? I mean: when a map is requested 
through WMS a bbox is sent in the request. Won't there be any partial 
labels at the edge of the bbox?


Thanks

Bernhard




Cheers
Martin





__ Information from ESET Mail Security, version of virus signature 
database 12303 (20150924) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS news startscreen proxy aware?

[Bernhard Ströbl]

Hallo Andreas,

do you mean the splash screen at startup? It shows ok for current master 
on Ubuntu behind a proxy.


Bernhard

Am 18.09.2015 um 15:02 schrieb Andreas Neumann:

Hi,

I noticed that the new QGIS startscreen from QGIS master works without a
proxy, but not with a proxy. Is this new start screen really proxy-aware?

Can others who use QGIS behind a proxy test and report if it works?

Thanks,
Andreas
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer




__ Information from ESET Mail Security, version of virus signature 
database 12284 (20150921) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] fTools - Processing (again)

[Bernhard Ströbl]

Hi Arnaud,

I would like add two things to (the end of) your list:
* Have a way to add icons to the algorithms
* Improve (and translate) algorithms' documentation

Bernhard

Am 14.09.2015 um 10:30 schrieb Arnaud Morvan:

Normally, I would be present at next hackfest and interested in working
on this.

 From my point of view, the task would be:

  * Create a customizable vector menu based on Processing like proposed
by Victor at Nodebo
  * List fTools menu entries, with candidates Processing algorithms, and
differences that need to be solved.
  * Porting algorithms that has not yet been ported
  * Complete some algorithms with new parameters or createcustom dialogs
close to fTools ones when need.
  * Get processing plugin fully translated (already working on this)

Arnaud

Le 11/09/2015 13:53, Victor Olaya a écrit :

I think Arnaud also raised the question sometime ago (my fault for not
commenting on that at the time...), and it should be easy to add those
shortcuts, but I haven't had much time lately for working on
Processing.

I wont be attending the next Hackfest, but sounds like a task that can
be accomplished in those days, and I will be happy to help remotely or
take it completely and try to develop a subsystem in Processing to
customize the menus and toolbars with Processing algorithms.

Hope this helps

2015-09-11 12:52 GMT+02:00 Paolo Cavallini:

Il 11/09/2015 11:29, kimaidou ha scritto:

+1 for this !

Hi all,
thanks for raising this point, IMHO a serious one. I'm very much in
favour of removing redundancy. In this case, however, I think we better
be careful before removing fTools, because:

* people are used to it, and for one-shot analyses it is (slightly)
easier to run than Processing (weak argument)
* we do not have enough development resources to make Processing
bulletproof, particularly for 3rd party backends; therefore, we
encounter occasional problems, and we cannot guarantee a smooth user
experience in all cases (strong argument).

First issue can be solved, as suggested, by adding menu shortcuts to
Processing analyses, to mimic existing situation.
Second one is more serious: IMHO we really need a dedicated developer in
this area: any power user (=larger institutions) are willing to take it?
Similar things may be said for GDALTools.
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





__ Information from ESET Mail Security, version of virus signature 
database 12248 (20150914) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] fTools - Processing (again)

[Bernhard Ströbl]

Hi Matthias,

sorry, I was not aware that new algorithms currently get implemented in 
both, fTools and Processing (same for bug fixes). This may be because of 
my ignorance, as I only adressed Processing with both, bug fixes and new 
algorithms since it had been introduced.


Bernhard

Am 14.09.2015 um 09:48 schrieb Matthias Kuhn:

Hi Bernhard


On 09/14/2015 09:39 AM, Bernhard Ströbl wrote:

Hi Matthias,

Am 14.09.2015 um 09:31 schrieb Matthias Kuhn:

Hi Bernhard,

The current code redundancy does have some severe issues like:

   * Algorithms may give different results from the vector menu and
processing (although both labelled similar, [QGIS] Geoprocessing)


I would need hints on tickets addressing such problems. If that is
really the case who is going to decide what the "right" result is?
Alternatively we could keep both but label them differently.

I don't know, maybe Paolo has some experiences?

For now, I would just dump one of the two implementations and if
problems surface decide case-by-case about the procedure (duplication or
introduction of an additional parameter).




   * Bugs need to be fixed twice


are they currently?


   * Features need to be implemented twice


are they currently?

My comments were targetting the current situation ;)

-- Matthias


Bernhard


If I remember right, somebody was working on a C++ implementation of
fTools recently. Does that ring a bell somewhere? It would be a pitty if
you work on this and a new implementation is merged at the same time.

After this question has been answered, a big +1 from my side to work on
this.
And another +1 if we get some unittests for the algorithms. They are
actually perfect candidates for unittests.

Kind regards
Matthias

On 09/14/2015 09:05 AM, Bernhard Ströbl wrote:

Hi Paolo,

just a thought: AFAIK fTools does not use 3rd party backends, so the
question of bulletproofness in conjunction with fTools IMHO should
only be raised for those algorithms that are currently in "QGIS
geoalgorithms". (Otherwise I fully agree: the rest should work
flawlessly)
As I said I would be willing to port what has not been ported yet
and/or look over algorithms that do not work as expected.
In spring the question of icons has been raised, too. This should not
be forgetten, either.

Bernhard

Am 11.09.2015 um 12:52 schrieb Paolo Cavallini:

Il 11/09/2015 11:29, kimaidou ha scritto:

+1 for this !


Hi all,
thanks for raising this point, IMHO a serious one. I'm very much in
favour of removing redundancy. In this case, however, I think we
better
be careful before removing fTools, because:

* people are used to it, and for one-shot analyses it is (slightly)
easier to run than Processing (weak argument)
* we do not have enough development resources to make Processing
bulletproof, particularly for 3rd party backends; therefore, we
encounter occasional problems, and we cannot guarantee a smooth user
experience in all cases (strong argument).

First issue can be solved, as suggested, by adding menu shortcuts to
Processing analyses, to mimic existing situation.
Second one is more serious: IMHO we really need a dedicated
developer in
this area: any power user (=larger institutions) are willing to
take it?
Similar things may be said for GDALTools.
All the best.





__ Information from ESET Mail Security, version of virus
signature database 12248 (20150914) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer







__ Information from ESET Mail Security, version of virus
signature database 12248 (20150914) __

The message was checked by ESET Mail Security.
http://www.eset.com









__ Information from ESET Mail Security, version of virus signature 
database 12248 (20150914) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] fTools - Processing (again)

[Bernhard Ströbl]

Hi Matthias,

Am 14.09.2015 um 09:31 schrieb Matthias Kuhn:

Hi Bernhard,

The current code redundancy does have some severe issues like:

  * Algorithms may give different results from the vector menu and
processing (although both labelled similar, [QGIS] Geoprocessing)


I would need hints on tickets addressing such problems. If that is 
really the case who is going to decide what the "right" result is? 
Alternatively we could keep both but label them differently.



  * Bugs need to be fixed twice


are they currently?


  * Features need to be implemented twice


are they currently?

Bernhard


If I remember right, somebody was working on a C++ implementation of
fTools recently. Does that ring a bell somewhere? It would be a pitty if
you work on this and a new implementation is merged at the same time.

After this question has been answered, a big +1 from my side to work on
this.
And another +1 if we get some unittests for the algorithms. They are
actually perfect candidates for unittests.

Kind regards
Matthias

On 09/14/2015 09:05 AM, Bernhard Ströbl wrote:

Hi Paolo,

just a thought: AFAIK fTools does not use 3rd party backends, so the
question of bulletproofness in conjunction with fTools IMHO should
only be raised for those algorithms that are currently in "QGIS
geoalgorithms". (Otherwise I fully agree: the rest should work
flawlessly)
As I said I would be willing to port what has not been ported yet
and/or look over algorithms that do not work as expected.
In spring the question of icons has been raised, too. This should not
be forgetten, either.

Bernhard

Am 11.09.2015 um 12:52 schrieb Paolo Cavallini:

Il 11/09/2015 11:29, kimaidou ha scritto:

+1 for this !


Hi all,
thanks for raising this point, IMHO a serious one. I'm very much in
favour of removing redundancy. In this case, however, I think we better
be careful before removing fTools, because:

* people are used to it, and for one-shot analyses it is (slightly)
easier to run than Processing (weak argument)
* we do not have enough development resources to make Processing
bulletproof, particularly for 3rd party backends; therefore, we
encounter occasional problems, and we cannot guarantee a smooth user
experience in all cases (strong argument).

First issue can be solved, as suggested, by adding menu shortcuts to
Processing analyses, to mimic existing situation.
Second one is more serious: IMHO we really need a dedicated developer in
this area: any power user (=larger institutions) are willing to take it?
Similar things may be said for GDALTools.
All the best.





__ Information from ESET Mail Security, version of virus
signature database 12248 (20150914) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer







__ Information from ESET Mail Security, version of virus signature 
database 12248 (20150914) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] fTools - Processing (again)

[Bernhard Ströbl]

Hi Paolo,

just a thought: AFAIK fTools does not use 3rd party backends, so the 
question of bulletproofness in conjunction with fTools IMHO should only 
be raised for those algorithms that are currently in "QGIS 
geoalgorithms". (Otherwise I fully agree: the rest should work flawlessly)
As I said I would be willing to port what has not been ported yet and/or 
look over algorithms that do not work as expected.
In spring the question of icons has been raised, too. This should not be 
forgetten, either.


Bernhard

Am 11.09.2015 um 12:52 schrieb Paolo Cavallini:

Il 11/09/2015 11:29, kimaidou ha scritto:

+1 for this !


Hi all,
thanks for raising this point, IMHO a serious one. I'm very much in
favour of removing redundancy. In this case, however, I think we better
be careful before removing fTools, because:

* people are used to it, and for one-shot analyses it is (slightly)
easier to run than Processing (weak argument)
* we do not have enough development resources to make Processing
bulletproof, particularly for 3rd party backends; therefore, we
encounter occasional problems, and we cannot guarantee a smooth user
experience in all cases (strong argument).

First issue can be solved, as suggested, by adding menu shortcuts to
Processing analyses, to mimic existing situation.
Second one is more serious: IMHO we really need a dedicated developer in
this area: any power user (=larger institutions) are willing to take it?
Similar things may be said for GDALTools.
All the best.





__ Information from ESET Mail Security, version of virus signature 
database 12248 (20150914) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] fTools - Processing (again)

[Bernhard Ströbl]

Hi all,

I recently recoded Processing's Dissolve. The changes fundamentally 
reduced the runtime of the algorithm. In the pull request discussion [1] 
Matthias and I came to a point where we were wondering about the future 
of fTools and Processing. I found this discussion from May [2]. What is 
the current status and road map in this respect?


If you can name algorithms to be ported I am willing to do it.

IMHO it would be great if we could get rid of the redundancy in the next 
LTR release.


regards

Bernhard

[1] https://github.com/qgis/QGIS/pull/2307
[2] 
http://osgeo-org.1560.x6.nabble.com/Processing-and-ftools-Proposal-for-hackfest-td5204324.html



__ Information from ESET Mail Security, version of virus signature 
database 12237 (20150911) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Updating field with a trigger

[Bernhard Ströbl]

Hi Yves,

Am 10.09.2015 um 09:27 schrieb Yves Jacolin:

Hello,

On Thursday, September 10, 2015 8:50:24 Bernhard Ströbl wrote:

Hi Yves,

I have only experience with PostgreSQL but I assume that sqlite behaves
similar. If you edit a feature in QGIS your layer is in edit mode
(allowing for undo/redo). Changes are committed only when you click on
the respective button. This results in an update statement sent to your
db which then calls your trigger. Thus field#2 is not changed when you
change #1 _in QGIS_. In order to have such behaviour AFAIK you would
have to do it in Python (which would be totally independent from the db
trigger then).

Thanks for confirmation.


Apart from that if
field#2 = field#1 + x
then field#2 is totally redundant. You could either create a view
containing this field or create a virtual field in QGIS.

I just simplified for the test case. This is more complicated but was not
useful to give such details ;)



still this should be considered an option to show the resulting value to 
the user instead of having it in a field of its own.




Thanks again Bernhard!


You're welcome

Bernhard



Y.


Am 09.09.2015 um 13:41 schrieb Yves Jacolin:

Hello,

I have a small project with a sqlite db. There is a layer with a trigger
on a field #1 to calculate an addition and put the result in another
field (#2).

When I edit the initial field #1, the second field #2 is not updated in
the
form. I need to close the form and open it again to see the result.

Do you think this is a known limitation or a bug?

My point of view is that it is a limitation, as QGIS don't know that a
trigger can change a value in the same feature server side.

I don't know if QGIS should or could get an update of the data server side
before display the form content.

In case there is no such plan, do you think we can add some logic in a
python script to force the form update (I can ask to Arnaud next week on
this topic).

Thanks,

Y.



__ Information from ESET Mail Security, version of virus signature 
database 12230 (20150910) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Updating field with a trigger

[Bernhard Ströbl]

Hi Yves,

I have only experience with PostgreSQL but I assume that sqlite behaves 
similar. If you edit a feature in QGIS your layer is in edit mode 
(allowing for undo/redo). Changes are committed only when you click on 
the respective button. This results in an update statement sent to your 
db which then calls your trigger. Thus field#2 is not changed when you 
change #1 _in QGIS_. In order to have such behaviour AFAIK you would 
have to do it in Python (which would be totally independent from the db 
trigger then).


Apart from that if
field#2 = field#1 + x
then field#2 is totally redundant. You could either create a view 
containing this field or create a virtual field in QGIS.


Bernhard


Am 09.09.2015 um 13:41 schrieb Yves Jacolin:

Hello,

I have a small project with a sqlite db. There is a layer with a trigger on a
field #1 to calculate an addition and put the result in another field (#2).

When I edit the initial field #1, the second field #2 is not updated in the
form. I need to close the form and open it again to see the result.

Do you think this is a known limitation or a bug?

My point of view is that it is a limitation, as QGIS don't know that a trigger
can change a value in the same feature server side.

I don't know if QGIS should or could get an update of the data server side
before display the form content.

In case there is no such plan, do you think we can add some logic in a python
script to force the form update (I can ask to Arnaud next week on this topic).

Thanks,

Y.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer





__ Information from ESET Mail Security, version of virus signature 
database 12230 (20150910) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Problems with utf-8 in attribute tables

[Bernhard Ströbl]

Hi Christian,

what type of layer are you writing in? Is the layer's source utf-8 
encoded and is its coding set to utf-8?
When I encountered encoding problems I found this [1] site very 
informative and also fun to read.


Bernhard

[1] http://www.joelonsoftware.com/articles/Unicode.html

Am 08.07.2015 um 11:39 schrieb Boehnke, Christian:

Hello,

we try to write non-ASCII characters inside of a QGIS python plugin.
There is no problem with the script but with the attribute table, where
the characters are not written in utf-8 or sth. else (see attachment).
Any suggestions?

Here is an example of our code to fill the attribute table. Row means a
list entry which is utf-8 coded.

for row in cursor.fetchall():

# add feature

feat = QgsFeature()

feat.setGeometry(
QgsGeometry.fromPoint(QgsPoint(row[3], row[4])) )


feat.setAttributes([row[1], row[2], row[3], row[4], self.path, row[0],
row[5]])

provider.addFeatures([feat])

Christian Böhnke



__ Information from ESET Mail Security, version of virus
signature database 11907 (20150708) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer


__ Information from ESET Mail Security, version of virus signature 
database 11907 (20150708) __

The message was checked by ESET Mail Security.
http://www.eset.com





__ Information from ESET Mail Security, version of virus signature 
database 11907 (20150708) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] crash when accessing geometry from Python console

[Bernhard Ströbl]

Hi Matthias,

thank you, this works:
feat = iface.activeLayer().selectedFeatures()[0]
g = QgsGeometry(feat.geometry())

Bernhard

Am 25.06.2015 um 10:36 schrieb Matthias Kuhn:

Hi,

The savest option is to use

QgsGeometry( feat.geometry() )

This does currently work and will continue to work in the future once
issue #777 is resolved,

Cheers,
Matthias

On 06/25/2015 09:10 AM, Bernhard Ströbl wrote:

Hi Martin,

I was not aware of this bug, thanks for pointing me towards it. As
posted previously I found a workaround but if I use
geometryAndOwnership() as proposed in #777 do I have to do anything like
g = None to destroy the geometry or will Python take care of that as
soon as my script has been finished?

thank you for your help

Bernhard

Am 25.06.2015 um 09:00 schrieb Martin Dobias:

Hi Bernhard

that's a long standing unresolved issue with python bindings:
http://hub.qgis.org/issues/777

Regards
Martin



On Thu, Jun 25, 2015 at 2:43 PM, Bernhard Ströbl
 wrote:

Hi everybody,

I try to do the following from the Python console:
g=iface.activeLayer().selectedFeatures()[0].geometry()
returns a QgsGeometry objekt but as soon as I want to do anything
with it
QGIS crashes (layer is a memory line layer but a PostGIS linestring
layer
behaves the same). Any request like
g.type()
g.length()
g.anything crashes QGIS
g.asPolyline() crash if the line has three vertices, with only two
vertices
it returns an empty array.

My goal is not the Python console but a plugin; the plugin crashes,
too :-(

tested with 2.8 on Win7 (64bit) and 2.8 & 2.9 on Ubuntu (64 bit) so it
should not be connected to the geometry overhaul I reckon.

any help appreciated

Bernhard





__ Information from ESET Mail Security, version of virus
signature database 11840 (20150625) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer




__ Information from ESET Mail Security, version of virus signature 
database 11840 (20150625) __

The message was checked by ESET Mail Security.
http://www.eset.com






__ Information from ESET Mail Security, version of virus signature 
database 11840 (20150625) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] crash when accessing geometry from Python console

[Bernhard Ströbl]

Hi Martin,

I was not aware of this bug, thanks for pointing me towards it. As 
posted previously I found a workaround but if I use 
geometryAndOwnership() as proposed in #777 do I have to do anything like
g = None to destroy the geometry or will Python take care of that as 
soon as my script has been finished?


thank you for your help

Bernhard

Am 25.06.2015 um 09:00 schrieb Martin Dobias:

Hi Bernhard

that's a long standing unresolved issue with python bindings:
http://hub.qgis.org/issues/777

Regards
Martin



On Thu, Jun 25, 2015 at 2:43 PM, Bernhard Ströbl
 wrote:

Hi everybody,

I try to do the following from the Python console:
g=iface.activeLayer().selectedFeatures()[0].geometry()
returns a QgsGeometry objekt but as soon as I want to do anything with it
QGIS crashes (layer is a memory line layer but a PostGIS linestring layer
behaves the same). Any request like
g.type()
g.length()
g.anything crashes QGIS
g.asPolyline() crash if the line has three vertices, with only two vertices
it returns an empty array.

My goal is not the Python console but a plugin; the plugin crashes, too :-(

tested with 2.8 on Win7 (64bit) and 2.8 & 2.9 on Ubuntu (64 bit) so it
should not be connected to the geometry overhaul I reckon.

any help appreciated

Bernhard





__ Information from ESET Mail Security, version of virus signature 
database 11840 (20150625) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] crash when accessing geometry from Python console

[Bernhard Ströbl]

Hm,

the following code returns the geometry ok:
for feat in iface.activeLayer().selectedFeatures():
  g=feat.geometry()
  break

Bernhard

Am 25.06.2015 um 08:43 schrieb Bernhard Ströbl:

Hi everybody,

I try to do the following from the Python console:
g=iface.activeLayer().selectedFeatures()[0].geometry()
returns a QgsGeometry objekt but as soon as I want to do anything with
it QGIS crashes (layer is a memory line layer but a PostGIS linestring
layer behaves the same). Any request like
g.type()
g.length()
g.anything crashes QGIS
g.asPolyline() crash if the line has three vertices, with only two
vertices it returns an empty array.

My goal is not the Python console but a plugin; the plugin crashes, too :-(

tested with 2.8 on Win7 (64bit) and 2.8 & 2.9 on Ubuntu (64 bit) so it
should not be connected to the geometry overhaul I reckon.

any help appreciated

Bernhard





__ Information from ESET Mail Security, version of virus signature 
database 11840 (20150625) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] crash when accessing geometry from Python console

[Bernhard Ströbl]

Hi everybody,

I try to do the following from the Python console:
g=iface.activeLayer().selectedFeatures()[0].geometry()
returns a QgsGeometry objekt but as soon as I want to do anything with 
it QGIS crashes (layer is a memory line layer but a PostGIS linestring 
layer behaves the same). Any request like

g.type()
g.length()
g.anything crashes QGIS
g.asPolyline() crash if the line has three vertices, with only two 
vertices it returns an empty array.


My goal is not the Python console but a plugin; the plugin crashes, too :-(

tested with 2.8 on Win7 (64bit) and 2.8 & 2.9 on Ubuntu (64 bit) so it 
should not be connected to the geometry overhaul I reckon.


any help appreciated

Bernhard



__ Information from ESET Mail Security, version of virus signature 
database 11840 (20150625) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QWC wsgi search

[Bernhard Ströbl]

Hi Marc,

in addition to what Andreas wrote: You should see in Apache's log file 
if something goes wrong with the database connection. Things that may go 
wrong in this respect are:
1) connection to the server is not allowed from the machine the wsgi 
script is located on with the method used (normally username + 
password); file pg_hba_conf

2) the user may connect to the server but not to the database in question
3) the user has no SELECT rights on one of the searchtables

You must have mod_wsgi installed and configured on your Apache server, 
of course.


To easily debug the wsgi-search you may want to enter the search URL 
directly in your browser like
http://my-page.de/wsgi/search.wsgi?query=wo&searchtables=&cb=stcCallback1001 


once you get an answer there you can try it from within QWC

Bernhard

Am 15.06.2015 um 20:33 schrieb Andreas Neumann:

Hi Marc,

Here is a wsgi search query from our server:

http://webgis.uster.ch/wsgi/search.wsgi?searchtables=&query=Werriker&cb=stcCallback1005


Note that there are builtin searchtables that are always used (things
like addresses, parcel numbers, building assurance numbers, geographic
names, etc.) - you can add additional searchtables e.g. for waste-water
pipes, etc.

The double query parameter is a mistake and stems from the fact that it
is by mistake also specified in GlobalOptions.js - look for a line with

Konsole output
varsearchBoxQueryURL = "/wsgi/search.wsgi?";

and remove the extra query parameter. But it is not a big deal, the
second parameter just replaces the empty one.

Other than that you must check the database permissions and if the login
parameters are correct.

In the file "search.js" you have to add the default searchtables array,
if you did not specify one in the URL - something like:

Konsole output
  searchtables =
['surveydata.searchtable_addresses','gisdata.searchtable_geographicnames'];

So please double check that your searchtables can be accessed with the
permissions of the web server user, if the login data is correct and if
the searchtables are specified and contain a valid structure.

Hope this helps,
Andreas

On 15.06.2015 17:46, Marc B wrote:

Hello List,

I am trying to connect the WSGI-Search to my PostGIS-Database.
Unfortunately I am reatively new to python and I dont really understand
which changes in the search.wsgi/qwc_connect.py I have to make.

I've created a DB-table like the one from the github instructions.
I've changed the DB_CONN_STRING in qwc_connect.py.

Some of my Questions are

1. Is there a way to easily test my DB-Connection in qwc_connect?
2. The generated URL with parameters is not how ist supposed to be:

https://my-page.de/wsgi/search.wsgi?query=&searchtables=&query=wo&cb=stcCallback1001


- Why are there 2 'query'-params, an empty and a correct one?
- the searchtables-parameter has no value, whether I put in a
  tablename in the search.wsgi or not ( searchtables =
  ['searchtable']; # enter your default searchtable(s) here ). Where
  does this parameter come from? What am i doing wrong?

If I paste the url in the url bar of chrome it says "error: no search
table". When I put a searchtable-value in the url i get a blank page.
It never says 'error: could not execute query'. So I guess, it doesnt
even get that far.

Thank you
Marc
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer





__ Information from ESET Mail Security, version of virus
signature database 11790 (20150615) __

The message was checked by ESET Mail Security.
http://www.eset.com




___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer


__ Information from ESET Mail Security, version of virus signature 
database 11790 (20150615) __

The message was checked by ESET Mail Security.
http://www.eset.com



--
Bernhard Ströbl
Anwendungsbetreuer GIS

Kommunale Immobilien Jena
Am Anger 26
07743 Jena

Tel.: 03641 49- 5190
E-Mail: bernhard.stro...@jena.de
Internet: www.kij.de


Kommunale Immobilien Jena
Eigenbetrieb der Stadt Jena


__ Information from ESET Mail Security, version of virus signature 
database 11792 (20150616) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] qgis-web-client: module wsgi

[Bernhard Ströbl]

Hi Enzo,

I did not realize you solved it in the meantime :-)

regards

Bernhard

Am 24.04.2015 07:42, schrieb Bernhard Ströbl:

Hi Enzo,

check Apache's error log (located e.g. in /var/log/apache2) and see if
there is some more information.

Bernhard

Am 23.04.2015 19:33, schrieb Enzo Cocca:

Hi Bernard,
I have followed
If I put the wsgi folder in /usr/lib/cgi-bin/ and set apache config like

   WSGIDaemonProcess gis processes=5 threads=15 display-name=%{GROUP}
   WSGIScriptAlias /wsgi/ /usr/lib/cgi-bin/wsgi/
   WSGIScriptAliasMatch ^/wsgi/([^/]+) /usr/lib/cgi-bin/wsgi/$1.wsgi

I have internal error 500. You  I'm not understand  again
sorry
E

2015-04-23 9:42 GMT+04:00 Bernhard Ströbl mailto:bernhard.stro...@jena.de>>:

Hi Enzo,

do not put it into html (see section 6 of the QWC documentation)
maybe in that location it is not run as a script but accessed by the
browser as any other html file (remember: I am no expert on this).
Basically you should not see the file at all in the browser, if an
error occurs it should be in Apache's error log.
Be sure ther is no space as the first character of the first line
(as was suggested before).

Bernhard

Am 22.04.2015 22:15, schrieb Enzo Cocca:

I continue to have the problem with mod_wsgi module. I not
understand  I have set the  apache config like suggest
bernhard and
I have put my wsgi folder in /var/www/html but I continue to
have the error:
illegal charcther #! /usr/bin/python

I have reinstalled libapache2-mod-wsgi, but nothing

I use ubuntu server 14.04 apache 2.4 python 2.7

Thanks at all for help

E

2015-04-22 16:32 GMT+04:00 Bernhard Ströbl
mailto:bernhard.stro...@jena.de>
<mailto:bernhard.stro...@jena.de
<mailto:bernhard.stro...@jena.de>>>:


 Hi Enzo,

 as I wrote in a previous post: Make sure the user running
the apache
 process has access to the wsgi directory. Try putting the
wsgi in
 /home/somthing e.g. in /var/www/wsgi

 Bernhard


 Am 22.04.2015 14:07, schrieb Enzo Cocca:

 Hi all,
 I looked for a solution but without results.

 After set the default file in apache like that:

 
 ServerAdmin webmaster@localhost
 ServerName 

 DocumentRoot /var/www/html/wms/site
 
   Options FollowSymLinks
   AllowOverride None
 
 
   DirectoryIndex index.php index.html
   Options Indexes FollowSymLinks MultiViews
   AllowOverride None
   Order allow,deny
   allow from all
   Require all granted
 

 ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
 
   AllowOverride None
   Options +ExecCGI -MultiViews -SymLinksIfOwnerMatch
   Order allow,deny
   Allow from all
   Require all granted
   SetEnv QGIS_LOG_FILE /tmp/qgislog.txt
 

 RewriteEngine On
 RewriteRule ^/cgi-bin/.*$ - [F]


 RewriteRule ^/wms/(.+)$

/cgi-bin/qgis_mapserv.fcgi?map=/var/www/html/wms/projects/$1.qgs
 [QSA,PT]

 RewriteRule ^/maps/?$ / [PT]

 RewriteRule ^/maps/([^\.]+)$ /qgiswebclient.html
[PT]

 RewriteRule ^/maps/(.*) /$1 [PT]

 #mod_wsgi
 #LoadModule wsgi_module
/usr/lib/apache2/modules/mod_wsgi.so
 WSGIDaemonProcess gis processes=5 threads=15
 display-name=%{GROUP}
 WSGIScriptAlias /wsgi/ /home/www/wsgi/
 WSGIScriptAliasMatch ^/wsgi/([^/]+)
/home/www/wsgi/$1.wsgi

 
   Order allow,deny
   Allow from all
 

 ErrorLog ${APACHE_LOG_DIR}/qgis-web-client-error.log
 CustomLog
${APACHE_LOG_DIR}/qgis-web-client-access.log combined

 

 and the GlobaOptions.js like that;
 //URL for custom search scriptsnull; //
 var searchBoxQueryURL =  "/wsgi/search.wsgi?query="; //
null:
 var searchBoxGetGeomURL =
"/wsgi/getSearchGeom.wsgi";//null; //

 The status is:
 NetworkError: 404 Not Found -

http://localhost/wsgi/search.wsgi?query=&searchtables=&

Re: [Qgis-developer] qgis-web-client: module wsgi

[Bernhard Ströbl]

Hi Enzo,

check Apache's error log (located e.g. in /var/log/apache2) and see if 
there is some more information.


Bernhard

Am 23.04.2015 19:33, schrieb Enzo Cocca:

Hi Bernard,
I have followed
If I put the wsgi folder in /usr/lib/cgi-bin/ and set apache config like

   WSGIDaemonProcess gis processes=5 threads=15 display-name=%{GROUP}
   WSGIScriptAlias /wsgi/ /usr/lib/cgi-bin/wsgi/
   WSGIScriptAliasMatch ^/wsgi/([^/]+) /usr/lib/cgi-bin/wsgi/$1.wsgi

I have internal error 500. You  I'm not understand  again
sorry
E

2015-04-23 9:42 GMT+04:00 Bernhard Ströbl mailto:bernhard.stro...@jena.de>>:

Hi Enzo,

do not put it into html (see section 6 of the QWC documentation)
maybe in that location it is not run as a script but accessed by the
browser as any other html file (remember: I am no expert on this).
Basically you should not see the file at all in the browser, if an
error occurs it should be in Apache's error log.
Be sure ther is no space as the first character of the first line
(as was suggested before).

Bernhard

Am 22.04.2015 22:15, schrieb Enzo Cocca:

I continue to have the problem with mod_wsgi module. I not
understand  I have set the  apache config like suggest
bernhard and
I have put my wsgi folder in /var/www/html but I continue to
have the error:
illegal charcther #! /usr/bin/python

I have reinstalled libapache2-mod-wsgi, but nothing

I use ubuntu server 14.04 apache 2.4 python 2.7

Thanks at all for help

E

2015-04-22 16:32 GMT+04:00 Bernhard Ströbl
mailto:bernhard.stro...@jena.de>
<mailto:bernhard.stro...@jena.de
<mailto:bernhard.stro...@jena.de>>>:


 Hi Enzo,

 as I wrote in a previous post: Make sure the user running
the apache
 process has access to the wsgi directory. Try putting the
wsgi in
 /home/somthing e.g. in /var/www/wsgi

 Bernhard


 Am 22.04.2015 14:07, schrieb Enzo Cocca:

 Hi all,
 I looked for a solution but without results.

 After set the default file in apache like that:

 
 ServerAdmin webmaster@localhost
 ServerName 

 DocumentRoot /var/www/html/wms/site
 
   Options FollowSymLinks
   AllowOverride None
 
 
   DirectoryIndex index.php index.html
   Options Indexes FollowSymLinks MultiViews
   AllowOverride None
   Order allow,deny
   allow from all
   Require all granted
 

 ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
 
   AllowOverride None
   Options +ExecCGI -MultiViews -SymLinksIfOwnerMatch
   Order allow,deny
   Allow from all
   Require all granted
   SetEnv QGIS_LOG_FILE /tmp/qgislog.txt
 

 RewriteEngine On
 RewriteRule ^/cgi-bin/.*$ - [F]


 RewriteRule ^/wms/(.+)$

/cgi-bin/qgis_mapserv.fcgi?map=/var/www/html/wms/projects/$1.qgs
 [QSA,PT]

 RewriteRule ^/maps/?$ / [PT]

 RewriteRule ^/maps/([^\.]+)$ /qgiswebclient.html [PT]

 RewriteRule ^/maps/(.*) /$1 [PT]

 #mod_wsgi
 #LoadModule wsgi_module
/usr/lib/apache2/modules/mod_wsgi.so
 WSGIDaemonProcess gis processes=5 threads=15
 display-name=%{GROUP}
 WSGIScriptAlias /wsgi/ /home/www/wsgi/
 WSGIScriptAliasMatch ^/wsgi/([^/]+)
/home/www/wsgi/$1.wsgi

 
   Order allow,deny
   Allow from all
 

 ErrorLog ${APACHE_LOG_DIR}/qgis-web-client-error.log
 CustomLog
${APACHE_LOG_DIR}/qgis-web-client-access.log combined

 

 and the GlobaOptions.js like that;
 //URL for custom search scriptsnull; //
 var searchBoxQueryURL =  "/wsgi/search.wsgi?query="; //
null:
 var searchBoxGetGeomURL =
"/wsgi/getSearchGeom.wsgi";//null; //

 The status is:
 NetworkError: 404 Not Found -

http://localhost/wsgi/search.wsgi?query=&searchtables=&query=qqq&cb=stcCallback1001

 So it not found the path of wsgi, but in default config
I have

Re: [Qgis-developer] qgis-web-client: module wsgi

[Bernhard Ströbl]

Hi Enzo,

do not put it into html (see section 6 of the QWC documentation) maybe 
in that location it is not run as a script but accessed by the browser 
as any other html file (remember: I am no expert on this).
Basically you should not see the file at all in the browser, if an error 
occurs it should be in Apache's error log.
Be sure ther is no space as the first character of the first line (as 
was suggested before).


Bernhard

Am 22.04.2015 22:15, schrieb Enzo Cocca:

I continue to have the problem with mod_wsgi module. I not
understand  I have set the  apache config like suggest bernhard and
I have put my wsgi folder in /var/www/html but I continue to have the error:
illegal charcther #! /usr/bin/python

I have reinstalled libapache2-mod-wsgi, but nothing

I use ubuntu server 14.04 apache 2.4 python 2.7

Thanks at all for help

E

2015-04-22 16:32 GMT+04:00 Bernhard Ströbl mailto:bernhard.stro...@jena.de>>:

Hi Enzo,

as I wrote in a previous post: Make sure the user running the apache
process has access to the wsgi directory. Try putting the wsgi in
/home/somthing e.g. in /var/www/wsgi

Bernhard


Am 22.04.2015 14:07, schrieb Enzo Cocca:

Hi all,
I looked for a solution but without results.

After set the default file in apache like that:


ServerAdmin webmaster@localhost
ServerName 

DocumentRoot /var/www/html/wms/site

  Options FollowSymLinks
  AllowOverride None


  DirectoryIndex index.php index.html
  Options Indexes FollowSymLinks MultiViews
  AllowOverride None
  Order allow,deny
  allow from all
  Require all granted


ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/

  AllowOverride None
  Options +ExecCGI -MultiViews -SymLinksIfOwnerMatch
  Order allow,deny
  Allow from all
  Require all granted
  SetEnv QGIS_LOG_FILE /tmp/qgislog.txt


RewriteEngine On
RewriteRule ^/cgi-bin/.*$ - [F]


RewriteRule ^/wms/(.+)$
/cgi-bin/qgis_mapserv.fcgi?map=/var/www/html/wms/projects/$1.qgs
[QSA,PT]

RewriteRule ^/maps/?$ / [PT]

RewriteRule ^/maps/([^\.]+)$ /qgiswebclient.html [PT]

RewriteRule ^/maps/(.*) /$1 [PT]

#mod_wsgi
#LoadModule wsgi_module /usr/lib/apache2/modules/mod_wsgi.so
WSGIDaemonProcess gis processes=5 threads=15
display-name=%{GROUP}
WSGIScriptAlias /wsgi/ /home/www/wsgi/
WSGIScriptAliasMatch ^/wsgi/([^/]+) /home/www/wsgi/$1.wsgi


  Order allow,deny
  Allow from all


ErrorLog ${APACHE_LOG_DIR}/qgis-web-client-error.log
CustomLog ${APACHE_LOG_DIR}/qgis-web-client-access.log combined



and the GlobaOptions.js like that;
//URL for custom search scriptsnull; //
var searchBoxQueryURL =  "/wsgi/search.wsgi?query="; // null:
var searchBoxGetGeomURL =  "/wsgi/getSearchGeom.wsgi";//null; //

The status is:
NetworkError: 404 Not Found -

http://localhost/wsgi/search.wsgi?query=&searchtables=&query=qqq&cb=stcCallback1001

So it not found the path of wsgi, but in default config I have
give the
alias

any idea?

E






__ Information from ESET Mail Security, version of virus
signature database 11515 (20150422) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org <mailto:Qgis-developer@lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/qgis-developer







__ Information from ESET Mail Security, version of virus signature 
database 11519 (20150423) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] qgis-web-client: module wsgi

[Bernhard Ströbl]

Hi Enzo,

as I wrote in a previous post: Make sure the user running the apache 
process has access to the wsgi directory. Try putting the wsgi in 
/home/somthing e.g. in /var/www/wsgi


Bernhard

Am 22.04.2015 14:07, schrieb Enzo Cocca:

Hi all,
I looked for a solution but without results.

After set the default file in apache like that:


   ServerAdmin webmaster@localhost
   ServerName 

   DocumentRoot /var/www/html/wms/site
   
 Options FollowSymLinks
 AllowOverride None
   
   
 DirectoryIndex index.php index.html
 Options Indexes FollowSymLinks MultiViews
 AllowOverride None
 Order allow,deny
 allow from all
 Require all granted
   

   ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
   
 AllowOverride None
 Options +ExecCGI -MultiViews -SymLinksIfOwnerMatch
 Order allow,deny
 Allow from all
 Require all granted
 SetEnv QGIS_LOG_FILE /tmp/qgislog.txt
   

   RewriteEngine On
   RewriteRule ^/cgi-bin/.*$ - [F]


   RewriteRule ^/wms/(.+)$
/cgi-bin/qgis_mapserv.fcgi?map=/var/www/html/wms/projects/$1.qgs [QSA,PT]

   RewriteRule ^/maps/?$ / [PT]

   RewriteRule ^/maps/([^\.]+)$ /qgiswebclient.html [PT]

   RewriteRule ^/maps/(.*) /$1 [PT]

   #mod_wsgi
   #LoadModule wsgi_module /usr/lib/apache2/modules/mod_wsgi.so
   WSGIDaemonProcess gis processes=5 threads=15 display-name=%{GROUP}
   WSGIScriptAlias /wsgi/ /home/www/wsgi/
   WSGIScriptAliasMatch ^/wsgi/([^/]+) /home/www/wsgi/$1.wsgi

   
 Order allow,deny
 Allow from all
   

   ErrorLog ${APACHE_LOG_DIR}/qgis-web-client-error.log
   CustomLog ${APACHE_LOG_DIR}/qgis-web-client-access.log combined



and the GlobaOptions.js like that;
//URL for custom search scriptsnull; //
var searchBoxQueryURL =  "/wsgi/search.wsgi?query="; // null:
var searchBoxGetGeomURL =  "/wsgi/getSearchGeom.wsgi";//null; //

The status is:
NetworkError: 404 Not Found -
http://localhost/wsgi/search.wsgi?query=&searchtables=&query=qqq&cb=stcCallback1001

So it not found the path of wsgi, but in default config I have give the
alias

any idea?

E







__ Information from ESET Mail Security, version of virus signature 
database 11515 (20150422) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] qgis-web-client: module wsgi

[Bernhard Ströbl]

Hi Enzo,

I am no Apache pro at all :-)

My config additionally contains the following:

Order allow,deny
Allow from all


I wonder if the user running the apache process can access /home/www, 
normally you would use something like /var/www/wsgi or /srv/www/wsgi

similar to where your HTML stuff is (and QWC)

Bernhard

Am 22.04.2015 10:12, schrieb Enzo Cocca:

Thanks Bernard

You are right, but now It not found the path wsgi folder

"The requested URL /wsgi/search.wsgi was not found on this server."

in globalOptions. js I set :

//URL for custom search scriptsnull; //
var searchBoxQueryURL =  "/wsgi/search.wsgi?query="; // null:
var searchBoxGetGeomURL =  "/wsgi/getSearchGeom.wsgi";//null; //
  and

in /etc/apache2/sites-available/default
I set
#mod_wsgi
   WSGIDaemonProcess gis processes=5 threads=15 display-name=%{GROUP}
   WSGIScriptAlias /wsgi/ /home/www/wsgi/
   WSGIScriptAliasMatch ^/wsgi/([^/]+) /home/www/wsgi/$1.wsgi

and than I restarted apache

Where I wrong?


2015-04-22 11:26 GMT+04:00 Bernhard Ströbl mailto:bernhard.stro...@jena.de>>:

Hi Enzo,

your error indicates that the script is not executed as a server
script but instead delivered to the client. Thjis should not happen,
as it is a high security risk (db internals are exposed).

Have you enabled mod_wsgi on your apache server as described in
section 6.2.1 of the QWC documentation?

You also should follow this line (section 6 the documentation): "It
is recommended to install the wsgi scripts in a separate directory,
e.g. /home/www/wsgi, a place that is not reachable by regular web
traffic."

Bernhard

Am 22.04.2015 09:15, schrieb Enzo Cocca:

Tahnks Bernhard,

I know, I have followed the procedure from official guideline
https://github.com/qgis/QGIS-Web-Client

but when execute a sample query in Firefox, like written in the
search.wsgi file, Firefox only visualize the file search.wsgi like a
text file.

and I have the error
"illegal character
#!/usr/bin/python"

So I not understand the problem

    Thanks!!



2015-04-22 10:51 GMT+04:00 Bernhard Ströbl
mailto:bernhard.stro...@jena.de>
<mailto:bernhard.stro...@jena.de
<mailto:bernhard.stro...@jena.de>>>:

 Hi,

 the wsgi-Script is a script to be run _on the server_, not
in the
 client.

 Bernhard

 Am 22.04.2015 08:47, schrieb Enzo Cocca:

 Hi,
 I have one questionç

 I try to write a searchtext in the client, Firebug
gives the error
 message:

 "illegal character
#!/usr/bin/python"

 Someone have a idea??

 thanks!!



 __ Information from ESET Mail Security, version of
virus
 signature database 11513 (20150422) __

 The message was checked by ESET Mail Security.
http://www.eset.com


 ___
 Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
<mailto:Qgis-developer@lists.osgeo.org>
<mailto:Qgis-developer@lists.osgeo.org
<mailto:Qgis-developer@lists.osgeo.org>>
http://lists.osgeo.org/mailman/listinfo/qgis-developer






__ Information from ESET Mail Security, version of virus
signature database 11513 (20150422) __

The message was checked by ESET Mail Security.
http://www.eset.com








__ Information from ESET Mail Security, version of virus signature 
database 11513 (20150422) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] AdvancedDigitizing and Python

[Bernhard Ströbl]

Hi all,

I wanted to start working on #12446 [1] however I did not find any 
documentation on how to use the new AdvancedDigitizing (CAD input queue) 
in Python.

Any help appreciated.

Bernhard

[1] http://hub.qgis.org/issues/12446


__ Information from ESET Mail Security, version of virus signature 
database 11513 (20150422) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] qgis-web-client: module wsgi

[Bernhard Ströbl]

Hi Enzo,

your error indicates that the script is not executed as a server script 
but instead delivered to the client. Thjis should not happen, as it is a 
high security risk (db internals are exposed).


Have you enabled mod_wsgi on your apache server as described in section 
6.2.1 of the QWC documentation?


You also should follow this line (section 6 the documentation): "It is 
recommended to install the wsgi scripts in a separate directory, e.g. 
/home/www/wsgi, a place that is not reachable by regular web traffic."


Bernhard

Am 22.04.2015 09:15, schrieb Enzo Cocca:

Tahnks Bernhard,

I know, I have followed the procedure from official guideline
https://github.com/qgis/QGIS-Web-Client

but when execute a sample query in Firefox, like written in the
search.wsgi file, Firefox only visualize the file search.wsgi like a
text file.

and I have the error
"illegal character
   #!/usr/bin/python"

So I not understand the problem

Thanks!!



2015-04-22 10:51 GMT+04:00 Bernhard Ströbl mailto:bernhard.stro...@jena.de>>:

Hi,

the wsgi-Script is a script to be run _on the server_, not in the
client.

Bernhard

Am 22.04.2015 08:47, schrieb Enzo Cocca:

Hi,
I have one questionç

I try to write a searchtext in the client, Firebug gives the error
message:

"illegal character
   #!/usr/bin/python"

Someone have a idea??

thanks!!



__ Information from ESET Mail Security, version of virus
signature database 11513 (20150422) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org <mailto:Qgis-developer@lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/qgis-developer







__ Information from ESET Mail Security, version of virus signature 
database 11513 (20150422) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] qgis-web-client: module wsgi

[Bernhard Ströbl]

Hi,

the wsgi-Script is a script to be run _on the server_, not in the client.

Bernhard

Am 22.04.2015 08:47, schrieb Enzo Cocca:

Hi,
I have one questionç

I try to write a searchtext in the client, Firebug gives the error
message:

"illegal character
  #!/usr/bin/python"

Someone have a idea??

thanks!!




__ Information from ESET Mail Security, version of virus signature 
database 11513 (20150422) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Thoughts about multi-type tables in QGIS

[Bernhard Ströbl]

Hi,

as a PostGIS user I followed this thread until now and want to add my 2 
cents:
The "OpenGIS Simple Features Specification For SQL, Revision 1.1" from 
1999 stated geometry being an abstract class, so the limitation is 
rather 16 years old (not 25), although I do not know if it has been 
influenced by the shape file format :-). The latest document from 2007 
does not contain this passage any more [1].

However I never put geometries of different types into the same table.
Here is an example (as it was asked for one previosly in this thread): I 
have compensating measures for development in the city. They can be 
polygon (e.g. a pond), linestring (e.g. a hedgerow) or even points (e.g. 
trees). My workaround in the database is to seperate geometries and 
attributes in different tables. So one table with attributes and three 
tables with geometries all drawing their primary key from the same 
sequence. Foreign keys and triggers ensure data consistency.
Even if QGIS supported different geometry types in the same table I 
doubt I would use such a feature as this would be too complicated for my 
users (they sometimes already have problems understanding the notion of 
multi-geometries).


IMHO this is not a pressing issue as these rare cases can be accomodated 
with database design. But it is worth thinking about as the distinction 
is in fact somewhat artificial, but any implementation must be 
accompanied with a _very_ good GUI design because the users are used to 
this distinction. A more important step (IMHO) would be to be able to 
apply a style to a different geometry-type layer than it was made for 
and/or have settings on the group level (e.g. color, min/max scale ...).


Bernhard

[1] http://www.opengeospatial.org/standards/sfs

Am 07.04.2015 07:26, schrieb Denis Rouzaud:

Instead of allowing mixed geometries, why not keeping the existing
behavior but allow for additional geometry columns.

Hence, current API remains: you're still waiting for a type of geometry,
and features have only one geometry.

But now, you allow to add additional geometries. They could be used in
symbolization by adding rules for the additional geometries.

Thoughts?



On 04/06/2015 09:59 PM, Matthias Kuhn wrote:

Hi

On 04/06/2015 12:08 PM, Nyall Dawson wrote:

Then, we could add a new "Add record" button to the attribute table
dialog for adding a new (empty) row, which would initially contain no
geometry. That fixes the first part of my issues with geometry
columns.

That button should already be there for non-geometry layers. I wonder if
it would be sufficient to remove an if-clause around it.

Matthias



___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer







__ Information from ESET Mail Security, version of virus signature 
database 11434 (20150407) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] wrong attribute values for postgis data in Feature attribute form

[Bernhard Ströbl]

Hi Raymond,

I thought it might be views because I never had any problems with 
tables. When defining views you should include a field

1) that is a primary key in the table it comes from and
2) whose values are unique in the view.

example: view with _one_ owner per parcel (parcels may be included 
several times if they have more than one owner)

a) use parcel-id => not unique, won't work
b) use owner-id => will work if no owner has more than one parcel (which 
would make the owner-id unique)

c) use id of the parcel-owner-relation table => should work

you still might need to carefully choose the id field when loading it 
into QGIS


Bernhard

Am 26.03.2015 11:15, schrieb Raymond Nijssen:

Thanks Bernhard. I just figured that. But my layer is not a table, it is
a view. And it seems that PostgreSQL cannot have constraints on views.

So, I think I just need to carefully select the right key field when
loading it.

(And maybe QGIS could be slightly smarter by not suggesting a boolean
field by default?)


On 26-03-15 11:07, Bernhard Ströbl wrote:

Hi Raymond,

Am 26.03.2015 10:57, schrieb Raymond Nijssen:

Thanks Regis, that was exactly the issue. The (boolean!) field
'inonderzoek' was used as a key. When I change that to 'gid' in the Add
PostGIS Table dialog, everything works correctly.

Can anyone tell me why QGIS picks that boolean field for most of my
tables? Can I change that behaviour by changing my database structure?


Maybe I can, but I would need the table definition statement for it. Can
you post it here.
Generally speaking you should define an integer field (use bigint if you
expect _many_ datasets) as primary key for the table like:

CREATE TABLE my_points
(
   gid integer NOT NULL,
   the_geom geometry(Point,my_srid),
   other_fields,
   CONSTRAINT my_points_pkey PRIMARY KEY (gid)
);

Bernhard



http://terglobo.nl/downloads/qgis_add_postgis_table_wrong_key.png

And how can the identify results be correct anyway?

Tnx,
Raymond


dbname='bag' host=localhost port=5432 user='postgres' sslmode=disable
key='inonderzoek' estimatedmetadata=true srid=28992 type=POLYGON
table="bagactueel"."pandactueelbestaand" (geovlak) sql=



On 26-03-15 10:34, Régis Haubourg wrote:

Hi, I have seen such troubles when the choosen primary key from qgis
side is
not unique .

Symptoms: selecting one feature select severals unrelated features of
the
same layer. relation with attributes is broken also.

Can you check in your layer's definition (general tab of layer
properties)
if you choose gid field as key, and check if it is really unique in
postgis?

Cheers
Régis



--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/wrong-attribute-values-for-postgis-data-in-Feature-attribute-form-tp5195518p5195523.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







__ Information from ESET Mail Security, version of virus
signature database 11379 (20150326) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer





__ Information from ESET Mail Security, version of virus signature 
database 11379 (20150326) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] wrong attribute values for postgis data in Feature attribute form

[Bernhard Ströbl]

Hi Raymond,

Am 26.03.2015 10:57, schrieb Raymond Nijssen:

Thanks Regis, that was exactly the issue. The (boolean!) field
'inonderzoek' was used as a key. When I change that to 'gid' in the Add
PostGIS Table dialog, everything works correctly.

Can anyone tell me why QGIS picks that boolean field for most of my
tables? Can I change that behaviour by changing my database structure?


Maybe I can, but I would need the table definition statement for it. Can 
you post it here.
Generally speaking you should define an integer field (use bigint if you 
expect _many_ datasets) as primary key for the table like:


CREATE TABLE my_points
(
  gid integer NOT NULL,
  the_geom geometry(Point,my_srid),
  other_fields,
  CONSTRAINT my_points_pkey PRIMARY KEY (gid)
);

Bernhard



http://terglobo.nl/downloads/qgis_add_postgis_table_wrong_key.png

And how can the identify results be correct anyway?

Tnx,
Raymond


dbname='bag' host=localhost port=5432 user='postgres' sslmode=disable
key='inonderzoek' estimatedmetadata=true srid=28992 type=POLYGON
table="bagactueel"."pandactueelbestaand" (geovlak) sql=



On 26-03-15 10:34, Régis Haubourg wrote:

Hi, I have seen such troubles when the choosen primary key from qgis
side is
not unique .

Symptoms: selecting one feature select severals unrelated features of the
same layer. relation with attributes is broken also.

Can you check in your layer's definition (general tab of layer
properties)
if you choose gid field as key, and check if it is really unique in
postgis?

Cheers
Régis



--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/wrong-attribute-values-for-postgis-data-in-Feature-attribute-form-tp5195518p5195523.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







__ Information from ESET Mail Security, version of virus signature 
database 11379 (20150326) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] PostGIS edition and foreign key

[Bernhard Ströbl]

Hi,

well, I tested and it is as you assumed: QGIS deletes both datasets and 
then issues an INSERT containing the new dataset. Therefore your foreign 
key constraint throws the error. I see two workarounds:
1) as proposed before: change the foreign key behaviour. If that is not 
possible

2) triggers might help you; possible outline:
a) preparation: add a field to operations and name it e.g. "was_parcel"
b) trigger 1, before delete:
 update operations set was_parcel = parcel_id, set parcel_id = NULL 
WHERE parcel_id = OLD.id (assuming parcel_id is the field with the 
foreign key constraint)

c) trigger 2, after insert:
 update operations set parcel_id = was_parcel, set parcel = NULL WHERE 
parcel = NEW.id


Bernhard

Am 04.03.2015 10:36, schrieb Thibaut Gheysen:

Hi,

I do the merge interactively by selecting the 2 parcels and clicking on
the button "merge selected features" from the advanced digitizing
toolbar. On the "merge features attributes" window, I select the
attributes of the parcel A as attributes of the new/merged parcel. Like
that the new/merged parcel as the same primary key than the past parcel A.

Regarding the possibility to create triggers to clean the merge, I have
to think about it but seems a little bit complex given the number of
tables linked to parcel table (not only operation one) and also the fact
that during an editing session we can make multiple merge on the same time.

Regarding the type of foreign key, I have well "ON DELETE NO ACTION".
Defining the foreign key to "ON DELETE CASCADE" or "ON DELETE SET NULL"
is unfortunately not possible.

Best regards,
Thibaut.



2015-03-03 12:10 GMT+01:00 Bernhard Ströbl mailto:bernhard.stro...@jena.de>>:

Hi,

the question is how you define your foreign key [1], namely what you
put for "ON DELETE" (you have either NO ACTION or RESTRICT, which
throw the error you receive) If you set ON DELETE CASCADE the
operation would be deleted, too, probably not what you want. Maybe
you should set ON DELETE SET NULL (make sure that the field can be
NULL!). Afterwards you reconnect the operation and the new parcel.

Bernhard


[1]

http://www.postgresql.org/__docs/current/static/ddl-__constraints.html#DDL-__CONSTRAINTS-FK

<http://www.postgresql.org/docs/current/static/ddl-constraints.html#DDL-CONSTRAINTS-FK>

Am 03.03.2015 11:14, schrieb Thibaut Gheysen:

Hi,

I would like to have your opinion in order to simplify as much as
possible our current workflow.

We have a table parcel and a table operation. The table operation
include a foreign key to the table parcel. We have 2 parcels (A
and B)
but only parcel A has operations link on it. I would like to
merge the 2
parcels by keeping the attributes of the parcel A. The merge is
doing
properly but impossible to save the edit (Provider errors:
PostGIS error
while deleting feature: ERROR: update or delete table "parcel"
violates
foreign key constraint"fk_parcel" on table "operation"). I guess
this is
due to the fact the Qgis first delete the 2 parcels (A and B) before
creating a new one (merged one).
This behaviour oblige us to export the table parcel into a
shapefile and
make the modifications on it. Once done, we import the shapefile
into
PostGIS and update the parcel geometry base on it.

Is there any chance to find an easier workflow, without developing a
plug-in ?

Thank for your help.

Best regards,
Thibaut.







_
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
<mailto:Qgis-developer@lists.osgeo.org>
http://lists.osgeo.org/__mailman/listinfo/qgis-__developer
<http://lists.osgeo.org/mailman/listinfo/qgis-developer>


__ Information from ESET Mail Security, version of virus
signature database 11260 (20150303) __

The message was checked by ESET Mail Security.
http://www.eset.com




__ Information from ESET Mail Security, version of virus
signature database 11260 (20150303) __

The message was checked by ESET Mail Security.
http://www.eset.com



_
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org <mailto:Qgis-developer@lists.osgeo.org>
http://lists.osgeo.org/__mailman/listinfo/qgis-__developer
<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


__ Information 

Re: [Qgis-developer] PostGIS edition and foreign key

[Bernhard Ströbl]

Hi,

the question is how you define your foreign key [1], namely what you put 
for "ON DELETE" (you have either NO ACTION or RESTRICT, which throw the 
error you receive) If you set ON DELETE CASCADE the operation would be 
deleted, too, probably not what you want. Maybe you should set ON DELETE 
SET NULL (make sure that the field can be NULL!). Afterwards you 
reconnect the operation and the new parcel.


Bernhard


[1] 
http://www.postgresql.org/docs/current/static/ddl-constraints.html#DDL-CONSTRAINTS-FK


Am 03.03.2015 11:14, schrieb Thibaut Gheysen:

Hi,

I would like to have your opinion in order to simplify as much as
possible our current workflow.

We have a table parcel and a table operation. The table operation
include a foreign key to the table parcel. We have 2 parcels (A and B)
but only parcel A has operations link on it. I would like to merge the 2
parcels by keeping the attributes of the parcel A. The merge is doing
properly but impossible to save the edit (Provider errors: PostGIS error
while deleting feature: ERROR: update or delete table "parcel" violates
foreign key constraint"fk_parcel" on table "operation"). I guess this is
due to the fact the Qgis first delete the 2 parcels (A and B) before
creating a new one (merged one).
This behaviour oblige us to export the table parcel into a shapefile and
make the modifications on it. Once done, we import the shapefile into
PostGIS and update the parcel geometry base on it.

Is there any chance to find an easier workflow, without developing a
plug-in ?

Thank for your help.

Best regards,
Thibaut.







___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer


__ Information from ESET Mail Security, version of virus signature 
database 11260 (20150303) __

The message was checked by ESET Mail Security.
http://www.eset.com





__ Information from ESET Mail Security, version of virus signature 
database 11260 (20150303) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] pyqgis add postgres table

[Bernhard Ströbl]

try:
uri.setDataSource('public', 'persones', None, '', 'id')

Bernhard

Am 23.02.2015 16:18, schrieb Alexandre Busquets:

Hi,

I can't add non geometry tables from postgres with pyqgis, this is my code

 uri = QgsDataSourceURI()
 uri.setConnection(bd_host, bd_port, bd_db, bd_user, bd_pass)
 uri.setDataSource('public', 'persones', '', '', 'id')
 taula = QgsVectorLayer(uri.uri(), 'persones', 'postgres')
 print taula.isValid()


What is the problem?


Thanks






__ Information from ESET Mail Security, version of virus signature 
database 11219 (20150223) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] guestimating plug-in dev time?

[Bernhard Ströbl]

Hi Andreas,

I do not think that multi-core rendering is the issue here as Remi 
mentions to have experienced crashes since QGIS 1.8.


Remi,
I am using QGIS with Postgres/PostGIS with some dozens of users on a 
central database _without_ any issues in QGIS (except the multi-core 
issue Andreas mentioned). So do share your problems together with 
relevent parts of your data base so they can beanalyzed.


Bernhard

Am 19.01.2015 13:19, schrieb Andreas Neumann:

Hi Remi,

Regarding crashes with Postgis: do you have multithreading with a lot of
CPU cores active? I am experiencing crashes if more than 2 cores are
active. Try limiting to 2 CPU cores and see if this helps.

Still trying to investigate this issue with the devs.

Besides the above issue, editing with Postgis works stable for me -
certainly not as many crashes as you say you have.

Please do not ignore the crashes but try to report them so that the devs
can do something about it.

Andreas

On 19.01.2015 11:57, Rémi Cura wrote:

I think a more global solution is possible.
After all when you load a postgis layer in qgis, if somebody else
changes it, the view is not refreshed, which is annoying (and
sometimes dangerous because you may edit old data).

It would be easy to ad this (which would also work for my case) using
the LISTEN / NOTIFY feature of postgres.

Basically when selecting a table as a new qgis layer, you
automatically add a triger to it.
The trigger will be fired at any change (create/delete/update).
The trigger would simply send a message to qgis via NOTIFY.
example : "NOTIFY qgis_change_ ;", where  is a unique id.
Of course qgis would be listening, which is very simple in python
(import psycopg2;
conn = psycopg.connect(my_database_string)
conn.autocommit(1)
curs = conn.cursor()
curs.execute("LISTEN qgis_change_;"))

Of course one would need a mechanism to remove this trigger when not
necessary (for instance, name the channel "qgis_change_/time_stamp/",
delete channel too old automatically, and change channel periodically
(20 in for instance)).

I don't know if from a security point of view it would be possibe
tough (would require the permission to create a trigger).
I don't know if typical qgis user have the right to create trigger on
database they use.

I use a lot of different version of QGIS and I can guarantee at least
a dozen crash a day with version 1.8 to 2.3,
plus pending transaction with postgis whenever the crash occurs.
I'm installing 2.6 to see if postgis layers are less fragile right now ^^

Cheers,
Rémi-C

2015-01-19 11:29 GMT+01:00 Martin Dobias mailto:wonder...@gmail.com>>:

I see - indeed QGIS would need to do quite some database
inspection to understand that layer A and layer B are related.
This should be however also easy to address in a custom plugin.

It is surprising to me that you say PostGIS layers are fragile in
QGIS - they are very commonly used by lots of people and we
haven't heard about crashes in the issue tracker. If you do
experience crashes please consider filing reports on hub.qgis.org
 with instructions on how to replicate them.

Regards
Martin


On Mon, Jan 19, 2015 at 5:18 PM, Rémi Cura mailto:remi.c...@gmail.com>> wrote:

Thanks Martin,
one day to several days feel like a very reasonnable order of
magnitude.

QGis is not refreshing the view because when editing layer A
the postgis data base automatically also edit layer B.
I don't think qgis has a mechanism of tracking dbchanges (it
would be possible tough).
Morevover PostGIS layer are still "fragile" in qgis (crashes
often).

Thanks for the help,
Cheers
Rémi-C

2015-01-19 10:56 GMT+01:00 Martin Dobias mailto:wonder...@gmail.com>>:

Hi Remi

Such plugin should be quite easy to write - I would assume
up to one day of work for an experienced pyqgis developer.
For a newcomer it may take few more days to get familiar
with the API, tools, environment and so on.

For the refresh of rendering after geometry editing - that
should work out of the box and I would consider it a bug
if it does not.

Regards
Martin


On Mon, Jan 19, 2015 at 3:16 PM, Rémi Cura
mailto:remi.c...@gmail.com>> wrote:

Hello dear list.
I'm usually active on the postgis or postgres list,
but today I would like to ask a question regarding dev
time.

In your opinion,
How much time would be needed to write a plugin for
multiple versions of qgis (2.2 to current 2.6) doing 3
simple things :
 - auto commit the edition of geometry when in edition
mode (no need to click on save  changes each time)
 - 

Re: [Qgis-developer] python code in form

[Bernhard Ströbl]

Hi Luca,

this is a bit off topic but when you store your data in PostgreSQL you 
might want to try out the DataDrivenInputMask plugin [1] which has a lot 
of (database) intelligence in the form and can be customized to hold 
even more. Maybe you do not need to customize QGIS' forms any more.


Bernhard

[1] http://plugins.qgis.org/plugins/DataDrivenInputMask/

Am 04.01.2015 22:39, schrieb Luca Lanteri:

Hi,

I'm using the init python function in order to add python code into my
QGIS forms. This is a great function because I can add intelligence to
my form without write a plugin, but I still have some problems:
- I want to store qml and .ui file directly into Postgres so that when
my users load a layer from postrgres they've my forms and styles,
without pass to us a qgis project, but in this way I loose the python
code. Is there a way to store also the python code in postgres or into qml?
- when I change my python code, qgis can't auto reload it. I have to
save the file with a different name and I have to change the name in the
layer properties. Is there a way to force autoreload of the code, also
only for debugging?

I also thought to move my code in a plugin to bypass those problems but
I think I've to rewrite all useful function that come with the forms
properties, eg: the combo population. is It right or there's a way to
include the QGIS forms add-on into a plugin?

Sorry for my newbie's question and thanks in advance.
Luca






__ Information from ESET Mail Security, version of virus signature 
database 10965 (20150105) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Concurrent editing- postGIS/Oracle Spatial

[Bernhard Ströbl]

Hi,

no solution but some thoughts. You could store all changes of each user 
into a separate table and create a dedicated view for each user 
combining the changed datasets in his/her user table and those unchanged 
by this user from the original table.
The user table would have a field user_action::char(1) with values i, u 
or d for (INSERT, UPDATE, DELETE)


CREATE VIEW userview AS
SELECT data FROM usertable
WHERE user_action != 'd'
UNION
SELECT data FROM originaltable
WHERE id not in (SELECT DISTINCT id FROM usertable);
--assuming id is the primary key

The user would edit this view and the view would be made editable 
through rules [1].


Once the job is completed the changes can be applied to the original 
table and deleted from the user table (by means of a DB function). You 
would have to make sure that deletes are executed first, then inserts 
and then updates. Maybe a timestamp of the change is useful to have only 
the last update executed for each dataset.


The main problem I see is concurrent editing of the same feature (e.g. 
user A changes feature 1 and in the meanwhile user B deletes it, then 
the application of A's changes has no effect). There used to be a plugin 
by Horst Düster called "PG Version" to handle this but I could not just 
find it.


Hope this helps

Bernhard

[1] http://www.postgresql.org/docs/9.3/static/rules.html

Am 02.12.2014 09:05, schrieb Manoj:

Hello All,

unable to post from original id, so trying my luck with another.


I need a suggestion to implement a workflow in QGIS.

Requirement is that edits are not visible to other user until field work
is over which means edits for a user is stored in temp table or in the
same table differentiated by a attribute.


So say I have road layer which is visible to all.

Any user work on road layer, their edits are stored in road_temp table.
Only owner user is allowed to see the new edits. The entry in db is
having user’s job id to find out.


Once he marks the job completion then others can also see.

So how I can make QGIS to show a combined view of two tables based on
the job opened or just existing +job data  if stored in a same table?

For example-


Existing data is – A, B, C, D

User A-  Job1- Created – E, Deleted C

So he his map showing- A,B, D, E

UserB comes- He still sees A, B, C, D.

He created another job- and added F.
So userB in his map viewing- A,B, C, D, F

User A- marked his job to complete.

Now UserB  in his map should see- A,B, D,E, F

Or which library is rendering the feature by getting from db (postGIS or
oracle)?


Thanks






__ Information from ESET Mail Security, version of virus signature 
database 10811 (20141202) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] PostGIS tables with missing gemoetries: how to handle them?

[Bernhard Ströbl]

Hi,

I wasn't aware of this. Although I do not understand why one should put 
points and lines in the _same_ table, geometries are allowed to be NULL 
if the field does not have a NOT NULL constraint. I see two possible 
solutions

1) mark the dataset as having no geometry
2) (preferred) do only load datasets which have a geometry

reasoning: As one can load any relation geometryless I would assume when 
loading the relation _with geometries_ there are geometries contained.


I am aware that solution 2) can be achieved with the user applying a 
filter like "geom_column" IS NOT NULL to the layer but 
that's for advanced users only


Bernhard



Am 20.11.2014 14:07, schrieb Paolo Cavallini:

Hi all.
If one has a pg table with records with a missing geometry (e.g. there are 
records
with a geom in a point column, others in a line column, others with both), the 
table
will show only the records with a geom; if I click on Show all, I also get 
records
without a geom. Of course, selecting a record like this and clicking on Zoom to
selected does nothing.
I'm unsure this is the least confusing behaviour for the user: opinions?
All the best.





__ Information from ESET Mail Security, version of virus signature 
database 10754 (20141120) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] 2.6.1 Windows patch?

[Bernhard Ströbl]

Hi Nathan,

which ticket are you refering to?
I was about to roll out QGIS 2.6 for Windows (both 32 and 64 bit).

thanks

Bernhard

Am 12.11.2014 12:00, schrieb Nathan Woodrow:

Hey,

Mainly for Jurgen.  Is there any possibility of getting a patched 2.6.1
into the Windows installers and binaries. The bug that Martin fixed just
after release that corrupted project files is a pretty nasty one that I
think could do with a patched 2.6.1 if we can.

Pretty please...

Regards,
Nathan


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer





__ Information from ESET Mail Security, version of virus signature 
database 10711 (20141112) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Re : Show area of a polygon while editing with node tool

[Bernhard Ströbl]

Hi,

just a question: are you trying to superimpose this on top of the 
out-of-the-box node tool or are you planning on creating a new tool that 
copies the node tool?


The first is not so simple I assume, the second either (plus it does not 
make too much sense to rewrite core functionality in Python). Apart from 
that I would be sceptical because with mouse moves the users will never 
achieve their target area.


I see two possible solutions apart from making a plugin of your own:
1) label the polygon with its area; after a node is moved the label is 
updated so users can approximate their desired target area.
2) try DigitizingTools plugin; there is a function to move a node or a 
polygon side to achieve a target area. If you need other funtionality 
there you are invited to contribute.


Bernhard

Am 16.10.2014 12:56, schrieb Junior:

Hi
Isn't there already such plugin? I haven't used it yet but you can give
a look to CalcArea plugin and see how it deals with that.

Envoyé depuis mon HTC

- Reply message -
De : "Michael Pfeiffer" 
Pour : 
Objet : [Qgis-developer] Show area of a polygon while editing with node tool
Date : jeu., oct. 16, 2014 09:38

Hi everybody,

I'm developing a python plugin.
Now the users of the plugin want to see the area of a polygon while editing
it with the node tool because they need to have polygons with a specific
area.
Means they move a node and the area changes while moving the node.
Is there an easy way to manage this? Are there already any examples?

Thx for your help

regards

Michael







__ Information from ESET Mail Security, version of virus signature 
database 10572 (20141016) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Virtual Fields - Allow adding fields out of edit mode

[Bernhard Ströbl]

Hi Matthias,

Am 14.10.2014 09:56, schrieb Matthias Kuhn:

Hi Bernhard


- shouldn't "create virtual field" be the default when layer is not in
edit mode?


I think it's more predictable (and therefore increases usability) for
users if it's either always on or always off by default. Don't you
think?


Ok, agreed, so I opt for "always on" because it will always work


It should be "always on" for providers that do not allow to add
attributes.


But thus the behaviour is not predictable either (from a user's point of 
view, who is just loading data into his/her project). Virtual field will 
_always_ work, no matter which provider.


For others both options always work and I prefer to keep the

previous behavior (without broad agreement that this should be changed,
if you convince some people I may change my mind ;-) ).


Anybody has an opinion on this?

Bernhard







- could the check box "create virtual field" be placed to the right of
"create a new field"?


"Create a new field" is a group box.
Would you create another group box with all field type widgets?


No of course not :-) I was not aware of the group box. I just had the
impression it should be there, so moving it on top seems adequate.


Done!

Cheers
Matthias





__ Information from ESET Mail Security, version of virus signature 
database 10558 (20141014) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Virtual Fields - Allow adding fields out of edit mode

[Bernhard Ströbl]

Hi Matthias,

Am 14.10.2014 09:15, schrieb Matthias Kuhn:

Hi Bernhard,

On 14.10.2014 07:36, Bernhard Ströbl wrote:

Hi Matthias,

thank you for your work!


Thank you for the review

However I have some small issues and a bug [1]
- I do not see any notification when not in edit mode but my action
requires edit mode (edit mode is turned on, though, when clicking OK)


That was just fixed

- shouldn't "create virtual field" be the default when layer is not in
edit mode?


I think it's more predictable (and therefore increases usability) for
users if it's either always on or always off by default. Don't you think?


Ok, agreed, so I opt for "always on" because it will always work




- could the check box "create virtual field" be placed to the right of
"create a new field"?


"Create a new field" is a group box.
Would you create another group box with all field type widgets?


No of course not :-) I was not aware of the group box. I just had the 
impression it should be there, so moving it on top seems adequate.


I doubt

it's easy to place it in the group box header as well. But I could
easily take it to the top, just below the header.

Best regards
Matthias


thanks

Bernhard



__ Information from ESET Mail Security, version of virus signature 
database 10558 (20141014) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Virtual Fields - Allow adding fields out of edit mode

[Bernhard Ströbl]

Hi Matthias,

thank you for your work!
However I have some small issues and a bug [1]
- I do not see any notification when not in edit mode but my action 
requires edit mode (edit mode is turned on, though, when clicking OK)
- shouldn't "create virtual field" be the default when layer is not in 
edit mode?
- could the check box "create virtual field" be placed to the right of 
"create a new field"?


all the best

Bernhard

[1] http://hub.qgis.org/issues/11403

Am 13.10.2014 18:11, schrieb Matthias Kuhn:

Hi all,

The changes have been merged to master today.

  * Virtual fields are now defined from the field calculator.
  * The field calculator is always available, regardless of provider
support and edit mode.
  * If an action from the field calculator requires to turn edit mode
on, the user will be notified on the field calculator dialog that this
will happen automatically when clicking ok.

Please test this and open issue reports if things are not working as
expected. Thank you very much.

Matthias



__ Information from ESET Mail Security, version of virus signature 
database 10558 (20141014) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer