[QGIS-Developer] Identify tool misalignment in QGIS master

[Neumann, Andreas]

Hi, 

We are starting to use QGIS 3 in production because we need some of the
newer features. 

The one major annoying issue is the misalignment of the highlight
geometry of the identify tool. 

Can we please, please fix this issue? 

See https://issues.qgis.org/issues/16824 

It would help us a lot! 

Thanks, 

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

Re: [QGIS-Developer] Question on signed windows installers

[Neumann, Andreas]

Hi Jürgen, 

Thanks a lot for the explanations, your work and efforts around signing
and fixing the weeklies! 

Another step in order to make QGIS more professional. 

Andreas 

On 2017-08-22 10:41, Jürgen E. Fischer wrote:

> Hi Andreas,
> 
> On Tue, 22. Aug 2017 at 09:39:48 +0200, Neumann, Andreas wrote: 
> 
>> I noticed that the Windows all-in-one installers are now signed (Open
>> Source Geospatial Foundation). Is 2.18.12 the first signed version or
>> were the previous versions also signed?
> 
> Yes, it's the first one.
> 
>> In any case - wanted to report back that our AV scanner did not complain
>> about 2.18.12, whereas it "swallowed" the QGIS 3 weekly without even
>> visibly notifying (only in the log file one could see that QGIS 3 was
>> sent to quarantine and the original installer file removed). Perhaps
>> signing installers builds trust with AV software? Installing over
>> OSGEO4W installer is always fine.
> 
> The weeklies apparently weren't built for a while.  Did anyone else notice?
> 
> I added signing for the weekly yesterday.  Requires wine and in turn xvfb -
> because we need to produce an extra installer that installs an uninstaller, so
> we can sign it and include it in the actual installer - runs fine locally (but
> w/o xvfb), but currently the final step crashes with a bus error on qgis2...
> 
> Jürgen 
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Question on signed windows installers

[Neumann, Andreas]

Hi Jürgen, 

I noticed that the Windows all-in-one installers are now signed (Open
Source Geospatial Foundation). Is 2.18.12 the first signed version or
were the previous versions also signed? 

In any case - wanted to report back that our AV scanner did not complain
about 2.18.12, whereas it "swallowed" the QGIS 3 weekly without even
visibly notifying (only in the log file one could see that QGIS 3 was
sent to quarantine and the original installer file removed). Perhaps
signing installers builds trust with AV software? Installing over
OSGEO4W installer is always fine. 

Greetings, 

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

[QGIS-Developer] Issue with $scale in QGIS 3

[Neumann, Andreas]

Hi, 

I use the function $scale in a data-defined label property (letter
spacing property). The expression worked fine in QGIS 2.18 but fails in
QGIS 3. 

Did something change in the expression context in QGIS master, so that
$scale can't be used in label settings context anymore - or is this a
bug? 

The reason I still use $scale and not @map_scale is that we still have
QGIS servers on 2.18 around, and QGIS server in the 2.x branch can't use
the @map_scale variable. 

Thanks if you know about this issue, 

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

[QGIS-Developer] User defined env vars on QGIS Master Windows

[Neumann, Andreas]

Hi, 

I use Postgis service definitions and define them centrally in a
pg_service.conf file. This concerns QGIS master on Windows. 

While this works fine on QGIS 2.18, I have issues in master - only if I
define PGSYSCONFDIR centrally in the Windows operating system, this
variable is honored, not if I define them in QGIS under Settings -->
Options --> System --> Environment. In this latter case, the env var is
ignored. 

I am pretty sure, this issue is rather recent, because it already worked
with older QGIS master builds. 

Maybe this has somehow to do with the "Add layer" refactoring in QGIS
master? Just a wild guess - perhaps it is some different issue. 

In any way, I would like to know if I am the only one experiencing this
problem. 

Thanks, 

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

Re: [QGIS-Developer] Exporting large GeoTIFF files from print composer

[Neumann, Andreas]

Hi Richard, 

Yes - using Linux for that purpose would be my fallback. But it is a bit
more complicated, because my Win machine is in the corporate network,
while the Linux machine is my private machine, and not part of the
network - where I have access to Postgis, and everything. 

The question is, if that error message is just an assumption, that the
export would fail - not giving the user even a chance to try, or if it
would really be a problem. 

Let's see if Matthias can find out something. 

Thanks, 

Andreas 

On 2017-07-26 14:23, Richard Duivenvoorde wrote:

> On 26-07-17 09:35, Neumann, Andreas wrote: 
> 
>> Hi,
>> 
>> I would like to export a large format QGIS print composer to a GeoTIFF file.
>> 
>> Page format is 2.4 x 1.9 m and I would like to export at 300 dpi. It is
>> for sending to a copy shop to print out for a trade fair in our province.
>> 
>> I can successfully export at 270 dpi, but if I go beyond, QGIS tells me
>> that I may experience a "memory overflow".
>> 
>> My machine is 64bit (Win 7) and has 16GB of memory.
>> 
>> Is this an arbitrary artificial threshold value where QGIS refuses to
>> export? Would it potentially work, if the barrier wouldn't exist? Could
>> I somehow bypass this barrier?
>> 
>> Thanks if you have any idea.
> 
> Hi Andreas,
> 
> Just a shot in the dark, but years ago I was not able to create a A0 pdf
> at 300dpi on a Windows (XP?) machine (memory problems), while on a Linux
> machine it just worked. Hopefully Windows has changed this, but it is
> worth trying?
> 
> Regards,
> 
> Richard___
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] Exporting large GeoTIFF files from print composer

[Neumann, Andreas]

Hi Matthias, 

Here is more info: 

First, I receive a warning saying: "To create image 28346x22440 requires
about 1908 MB of memory. Proceed?" with an OK / Cancel button. 

Then I press "OK" 

A dialog appears where I can choose where to store the raster file. 

Then a dialog titled "Image export options" appears, where I could do
various settings, like - again selecting the dpi, width and height and I
could "Crop to content". 

I leave all settings as they are by default and press "Save". 

Then the final and blocking error message dialog is: 

"Trying to create image #1 (28346x22440 @ 300dpi) may result in a memory
overflow. Please try a lower resolution or a smaller papersize". 

Then I can only press "OK" and the image isn't exported. 

Thanks for having a look at this, 

Andreas 

On 2017-07-26 14:48, Matthias Kuhn wrote:

> Hi Andreas, 
> 
> can you send us the warning literally (German or English)? 
> 
> I remember an issue report (or gis.se question) about an artificial limit 
> that was formulated like a warning but was indeed preventing from doing an 
> export. Sounds pretty much like what you are experiencing. 
> 
> Matthias 
> On 7/26/17 9:35 AM, Neumann, Andreas wrote: 
> 
>> Hi, 
>> 
>> I would like to export a large format QGIS print composer to a GeoTIFF file. 
>> 
>> Page format is 2.4 x 1.9 m and I would like to export at 300 dpi. It is for 
>> sending to a copy shop to print out for a trade fair in our province. 
>> 
>> I can successfully export at 270 dpi, but if I go beyond, QGIS tells me that 
>> I may experience a "memory overflow". 
>> 
>> My machine is 64bit (Win 7) and has 16GB of memory. 
>> 
>> Is this an arbitrary artificial threshold value where QGIS refuses to 
>> export? Would it potentially work, if the barrier wouldn't exist? Could I 
>> somehow bypass this barrier? 
>> 
>> Thanks if you have any idea. 
>> 
>> 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
> 
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Exporting large GeoTIFF files from print composer

[Neumann, Andreas]

Hi, 

I would like to export a large format QGIS print composer to a GeoTIFF
file. 

Page format is 2.4 x 1.9 m and I would like to export at 300 dpi. It is
for sending to a copy shop to print out for a trade fair in our
province. 

I can successfully export at 270 dpi, but if I go beyond, QGIS tells me
that I may experience a "memory overflow". 

My machine is 64bit (Win 7) and has 16GB of memory. 

Is this an arbitrary artificial threshold value where QGIS refuses to
export? Would it potentially work, if the barrier wouldn't exist? Could
I somehow bypass this barrier? 

Thanks if you have any idea. 

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

Re: [QGIS-Developer] Qgis master compilation core dump

[Neumann, Andreas]

Hi Eugenio, 

I had something similar. 

Did you have Ubuntu system libraries updates just recently? 

Apparently there had been libc library upgrades in Ubuntu just recently.
I also had these crashes. After the system upgrades, running ldconfig
(with sudo) and recompiling, the issues had been gone. 

Andreas 

On 2017-07-21 15:10, frippe12573 wrote:

> I have just compiled QGIS master with no errors in ubuntu 17.04, however, I
> have got the following core dump:
> 
> QGIS died on signal 11[New LWP 14035]
> [New LWP 14036]
> [New LWP 14037]
> [New LWP 14038]
> [New LWP 14040]
> [New LWP 14041]
> [New LWP 14043]
> [New LWP 14044]
> [New LWP 14045]
> [New LWP 14046]
> [New LWP 14047]
> [New LWP 14048]
> [New LWP 14049]
> [New LWP 14050]
> [New LWP 14051]
> [New LWP 14052]
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> 0x7efcace930aa in __GI___waitpid (pid=14053, stat_loc=0x7fff3c678764,
> options=0) at ../sysdeps/unix/sysv/linux/waitpid.c:29
> 29../sysdeps/unix/sysv/linux/waitpid.c: No such file or directory.
> [Current thread is 1 (Thread 0x7efcb1bd0300 (LWP 14034))]
> #0  0x7efcace930aa in __GI___waitpid (pid=14053,
> stat_loc=0x7fff3c678764, options=0) at
> ../sysdeps/unix/sysv/linux/waitpid.c:29
> resultvar = 18446744073709551104
> sc_cancel_oldtype = 0
> #1  0x55f0aac802ab in qgisCrash(int) ()
> #2  0x7efcacdfb7f0 in  () at
> /lib/x86_64-linux-gnu/libc.so.6
> #3  0x7efc09996604 in QBasicAtomicInt::ref() (this=) at
> ../../include/QtCore/../../src/corelib/arch/qatomic_x86_64.h:121
> #4  0x7efc09996604 in QList::QList()
> (this=0x7efc0a4d6538 ) at
> ../../include/QtCore/../../src/corelib/tools/qlist.h:121
> #5  0x7efc09996604 in QPrinterInfoPrivate::QPrinterInfoPrivate(QString
> const&) (name=..., this=Python Exception  maximum
> recursion depth exceeded while getting the str of an object: 
> 0x7efc0a4d6520 ) at
> painting/qprinterinfo_p.h:71
> #6  0x7efc09996604 in __static_initialization_and_destruction_0
> (__initialize_p=1, __priority=65535) at painting/qprinterinfo.cpp:35
> #7  0x7efc09996604 in _GLOBAL__sub_I_qprinterinfo.cpp(void) () at
> painting/qprinterinfo.cpp:163
> #8  0x7efcb1b0a9ca in call_init (l=, argc=argc@entry=1,
> argv=argv@entry=0x7fff3c67b068, env=env@entry=0x55f0ac2cab90) at
> dl-init.c:72
> j = 
> jm = 
> addrs = 
> init_array = 
> #9  0x7efcb1b0aadb in call_init (env=0x55f0ac2cab90,
> argv=0x7fff3c67b068, argc=1, l=) at dl-init.c:30
> preinit_array = 
> preinit_array_size = 
> i = 3
> #10 0x7efcb1b0aadb in _dl_init (main_map=main_map@entry=0x55f0acbc8e30,
> argc=1, argv=0x7fff3c67b068, env=0x55f0ac2cab90) at dl-init.c:120
> preinit_array = 
> preinit_array_size = 
> i = 3
> #11 0x7efcb1b0fa76 in dl_open_worker (a=a@entry=0x7fff3c679240) at
> dl-open.c:575
> args = 0x7fff3c679240
> file = 
> mode = 
> call_map = 
> dst = 
> new = 
> __PRETTY_FUNCTION__ = "dl_open_worker"
> r = 
> reloc_mode = 
> nmaps = 
> l = 
> maps = 
> relocation_in_progress = 
> any_tls = 
> first_static_tls = 
> #12 0x7efcb1b0a874 in _dl_catch_error
> (objname=objname@entry=0x7fff3c679230,
> errstring=errstring@entry=0x7fff3c679238,
> mallocedp=mallocedp@entry=0x7fff3c67922f,
> operate=operate@entry=0x7efcb1b0f720 ,
> args=args@entry=0x7fff3c679240) at dl-error.c:187
> errcode = 32767
> c = {objname = 0x7fff3c679230, errstring = 0x7fff3c679238, malloced
> = 0x7fff3c67922f, errcode = 0x7fff3c67910c, env = {{__jmpbuf =
> {140734206808912, -7974001656830896782, 2147483649, 94492178528696,
> 139623709428174, 139623780188224, -7974001656898005646,
> -7831271483816684174}, __mask_was_saved = -1311633048, __saved_mask = {__val
> = {139623777975664, 94492145718768, 44, 44, 139623344284312,
> 139623344285608, 139623777976658, 44, 139623344285608, 139623779553128,
> 140734206808680, 140734206808676, 139623777977995, 22521, 139623743018536,
> 0}
> catchp = 0x7efcb1bd02b8
> old = 
> #13 0x7efcb1b0f059 in _dl_open (file=0x55f0acbc39b8
> "/usr/local/lib/qgis/plugins/libzonalstatisticsplugin.so", mode=-2147483647,
> caller_dlopen=0x7efcad9a49ce, nsid=-2, argc=, argv= out>, env=0x55f0ac2cab90) at dl-open.c:660
> args = {file = 0x55f0acbc39b8
> "/usr/local/lib/qgis/plugins/libzonalstatisticsplugin.so", mode =
> -2147483647, caller_dlopen = 0x7efcad9a49ce, caller_dl_open = 0x7efca41baee9
> , map = 0x55f0acbc8e30, nsid = 0, argc = 1, argv =
> 0x7fff3c67b068, env = 0x55f0ac2cab90}
> objname = 0x7fff3c679264 "\360U"
> errstring = 0x55f0acbc3bf0
> "/usr/local/lib/qgis/plugins/libwmsprovider.so"
> malloced = false
> errcode = 
> __PRETTY_FUNCTION__ = "_dl_open"
> #14 0x7efca41baee9 in dlopen_doit (a=a@entry=0x7fff3c679470) at
> dlopen.c:66
> args = 0x7fff3c679470
> #15 0x7efcb1b0a874 in _dl_catch_error (objname=0x55f0abebbe10,
> errstring=0x55f0abebbe18, mallocedp=0x55f0abebbe08, operate=0x7efca41bae90
> , 

Re: [QGIS-Developer] About dialogue: QGIS code revision vs QGIS code branch

[Neumann, Andreas]

Hi Jürgen, 

I updated some system libs (C-stuff) in Kubuntu and now QGIS starts
again without a crash. The code revision displays fine again. 

So apparently it was a temporary problem in my local system and is fixed
now. 

Thanks again, 

Andreas 

On 2017-07-17 17:07, Neumann, Andreas wrote:

> Hi Jürgen, 
> 
> thx for the fix. 
> 
> Unfortunately I now get a crash during startup after I compiled the newest 
> version ;-) 
> 
> QGIS died on signal 11. Could not attach to process. There is some more stuff 
> in the error message. Not sure if it is relevant. 
> 
> I did a "ninja clean" to make sure there is no old stuff around that may 
> cause the crash. 
> 
> Andreas 
> 
> On 2017-07-17 15:32, Jürgen E. Fischer wrote: 
> Hi Andreas,
> 
> On Mon, 17. Jul 2017 at 14:16:36 +0200, Neumann, Andreas wrote: I noticed, on 
> another machine, a self compiled QGIS, that I don't see
> the code revision, but it only displays a "QGIS code branch" instead,
> with "Release 2.99" as the value. 
> Please verify with bcc8e90640d.
> 
> Jürgen 
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

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

Re: [QGIS-Developer] About dialogue: QGIS code revision vs QGIS code branch

[Neumann, Andreas]

Hi Jürgen, 

thx for the fix. 

Unfortunately I now get a crash during startup after I compiled the
newest version ;-) 

QGIS died on signal 11. Could not attach to process. There is some more
stuff in the error message. Not sure if it is relevant. 

I did a "ninja clean" to make sure there is no old stuff around that may
cause the crash. 

Andreas 

On 2017-07-17 15:32, Jürgen E. Fischer wrote:

> Hi Andreas,
> 
> On Mon, 17. Jul 2017 at 14:16:36 +0200, Neumann, Andreas wrote: 
> 
>> I noticed, on another machine, a self compiled QGIS, that I don't see
>> the code revision, but it only displays a "QGIS code branch" instead,
>> with "Release 2.99" as the value.
> 
> Please verify with bcc8e90640d.
> 
> Jürgen 
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] About dialogue: QGIS code revision vs QGIS code branch

[Neumann, Andreas]

Hi, 

In the QGIS about dialogue I can see the QGIS code revision (e.g. on the
QGIS master nightlies). 

I noticed, on another machine, a self compiled QGIS, that I don't see
the code revision, but it only displays a "QGIS code branch" instead,
with "Release 2.99" as the value. 

Does this mean something is busted with my git repo? "git log" shows
that I am at the newest revision, but I would really like to know what
exact code revision my self-compiled version is running, to double check
if I am really running the very latest revision. 

Thanks, 

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

[QGIS-Developer] Enhance expression editor with list of relations and tables present in project?

[Neumann, Andreas]

Hi, 

I think it would be good if the expression editor could show a list of: 

a) relations (group could be called "Relations") 

b) other tables (group could be called "Tables") 

Just like the "Fields and values" group, it would be a list of existing
relations and tables. 

Otherwise it is a bit complicated spelling relation names and table
names correctly. 

The relation_aggregate expression and the get_feature function would be
much easier to use with this enhancement. 

I would also assume that in the future, there will be more expression
functions that make use of other tables and relations. 

Which developer could work on that? 

I created a ticket: https://issues.qgis.org/issues/16879 

Thanks, 

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

Re: [QGIS-Developer] QGIS expression: Formatting numbers with leading zeros

[Neumann, Andreas]

Hi Matthieu, 

It works, but slightly simpler ;-) 

We don't need the calculation "n-length("my_number"), because the second
parameter is the total string length. 

Anyway, it works now for me and it is rather easy with lpad. 

Thanks, 

Andreas 

On 2017-07-12 10:16, Mathieu Pellerin wrote:

> Andreas, 
> 
> I think you're looking for: lpad("my_number",n - length("my_number"),0) 
> 
> Math 
> 
> On Wed, Jul 12, 2017 at 3:02 PM, Neumann, Andreas <a.neum...@carto.net> wrote:
> 
>> Hi, 
>> 
>> Is there a way in a QGIS expression to format numbers with leading zeros up 
>> to n places before the decimal point? E.g. 1 should be 1, 10 should be 
>> 00010, etc. 
>> 
>> I would need this for correct sorting. 
>> 
>> I know, I could probably write a python expression, or something complicated 
>> with CASE WHEN, but I'd like to avoid that. 
>> 
>> Perhaps something is already existing? 
>> 
>> Andreas 
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer [1]
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer [1]

 

Links:
--
[1] https://lists.osgeo.org/mailman/listinfo/qgis-developer___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] QGIS expression: Formatting numbers with leading zeros

[Neumann, Andreas]

Hi, 

Is there a way in a QGIS expression to format numbers with leading zeros
up to n places before the decimal point? E.g. 1 should be 1, 10
should be 00010, etc. 

I would need this for correct sorting. 

I know, I could probably write a python expression, or something
complicated with CASE WHEN, but I'd like to avoid that. 

Perhaps something is already existing? 

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

Re: [QGIS-Developer] Incremental drawing possible?

[Neumann, Andreas]

Hi, 

I tested it on Linux with WMTS and Postgis layers. It worked fine for
it. I would like to test it on Windows as well, but I can't compile it
on Windows  if it would be in master, I could test the nightlies. 

Performancewise it worked fine on Linux. 

I am not so sure, if it should be enabled for WMS layers, because there
would most likely be issues with labels ... if there would be additional
tiles at the previous canvas border. I think for WMS the user should be
able to decide whether he wants to enable/disable. It may make sense for
unproblematic layers (e.g. Orthoimages) - but anything with dynamic
labels may have issues. But I think it is disabled for WMS anyway,
currently. 

Andreas 

On 2017-07-12 00:57, Nyall Dawson wrote:

> On 12 July 2017 at 06:21, Andreas Neumann  wrote: 
> 
>> Hi Nyall,
>> 
>> I compiled your branch / pull request. Quite impressive! I like it.
>> 
>> Is it planned to land in master, or are there issues with this improvement?
> 
> Well - from my use case I consider it ready. But there's some
> outstanding questions which need solving (see the PR discussion):
> 
> - should this be normal behavior?
> - should it be enabled for all layer types? wmts only (as per
> sourcepole's original implementation)? local layers only (for those of
> us on crap/expensive internet connections)? rasters only? vectors
> only?
> - is the cpu utilisation for rendering these possibly unseen tiles an
> issue? or is cpu use so cheap nowdays that it's not a factor?
> - should the rendering of the adjacent tiles only begin when a pan
> starts? (would lose the zoom out benefits this brings, plus add a
> delay in showing the nearby area when pan starts)
> 
> My 2c: just enable it for everything and let everyone get the benefits
> without any configuration hassle. But... all my workstations are at
> least 4 cores and lots of memory. So I'm probably not in the best
> position to make this call ;)
> 
> Nyall___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Incremental drawing possible?

[Neumann, Andreas]

Nice - I will test that branch. 

Andreas 

On 2017-07-11 11:26, Nyall Dawson wrote:

> On 11 July 2017 at 19:22, Neumann, Andreas <a.neum...@carto.net> wrote: 
> 
>> Hi Martin,
>> 
>> Sounds interesting. Of course this is not urgent. We now need to concentrate
>> on all the stuff that requires refactoring and API changes in the master
>> branch.
>> 
>> But it would really be nice, if such rendering improvements could be
>> introduced in a future 3.x version. Maybe something for the next QGIS grants
>> program?
> 
> Andreas - do you compile master builds? I'd love it if you could give
> the branch from https://github.com/qgis/QGIS/pull/4777 a test and give
> feedback on the open questions in that PR. I suspect you'll be pleased
> with the behavior with that change.
> 
> Full credit for the changes goes to Sourcepole - I've just forward
> ported the feature from their fork and modernised the code for 3.0.
> 
> Nyall
> 
>> Andreas
>> 
>> On 2017-07-11 10:48, Martin Dobias wrote:
>> 
>> Hi Andreas
>> 
>> On Tue, Jul 11, 2017 at 9:38 AM, Neumann, Andreas <a.neum...@carto.net>
>> wrote:
>> 
>> Hi Martin,
>> 
>> I noticed that loading and redraw only happens when the mouse button is
>> released after the panning operation. While I understand the reasoning for
>> this (definitely on the safe side and no unnecessary redraws), I wonder, if
>> for WMTS, loading and display could already happen while panning and the
>> mouse button isn't yet released, e.g. triggered whenever a certain threshold
>> of panning distance (e.g. in percent of the last extent) was surpassed.
>> 
>> This would be even nicer than the current behaviour. Or are there technical
>> reasons, not to do that? Google maps works like this. It redraws while
>> panning.
>> 
>> Good news - there are no technical reasons that would prohibit us from
>> such improvement. Background rendering could start earlier, we just
>> need to add logic for such behavior. There is already a pending pull
>> request from Nyall to render adjacent parts of map canvas once
>> rendering of the visible area has finished - that may already be a
>> sufficient solution - I have not had time to play with it yet though.
>> Maybe these two approaches (render on map dragging, render outside of
>> current view) can be combined somehow for the best UX while keeping
>> overhead of extra rendering low.
>> 
>> We could even think about moving more towards tile-based approach to
>> rendering of map canvas, with the advantage of being able to cache map
>> tiles from previous canvas redraws for the same scale. This would
>> allow instant appearance of areas previously rendered with lower CPU
>> use at the expense of consuming more memory and having more
>> complicated logic for labeling.
>> 
>> Regards
>> Martin___
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] Incremental drawing possible?

[Neumann, Andreas]

Hi Martin, 

Sounds interesting. Of course this is not urgent. We now need to
concentrate on all the stuff that requires refactoring and API changes
in the master branch. 

But it would really be nice, if such rendering improvements could be
introduced in a future 3.x version. Maybe something for the next QGIS
grants program? 

Andreas 

On 2017-07-11 10:48, Martin Dobias wrote:

> Hi Andreas
> 
> On Tue, Jul 11, 2017 at 9:38 AM, Neumann, Andreas <a.neum...@carto.net> 
> wrote: 
> 
>> Hi Martin,
>> 
>> I noticed that loading and redraw only happens when the mouse button is
>> released after the panning operation. While I understand the reasoning for
>> this (definitely on the safe side and no unnecessary redraws), I wonder, if
>> for WMTS, loading and display could already happen while panning and the
>> mouse button isn't yet released, e.g. triggered whenever a certain threshold
>> of panning distance (e.g. in percent of the last extent) was surpassed.
>> 
>> This would be even nicer than the current behaviour. Or are there technical
>> reasons, not to do that? Google maps works like this. It redraws while
>> panning.
> 
> Good news - there are no technical reasons that would prohibit us from
> such improvement. Background rendering could start earlier, we just
> need to add logic for such behavior. There is already a pending pull
> request from Nyall to render adjacent parts of map canvas once
> rendering of the visible area has finished - that may already be a
> sufficient solution - I have not had time to play with it yet though.
> Maybe these two approaches (render on map dragging, render outside of
> current view) can be combined somehow for the best UX while keeping
> overhead of extra rendering low.
> 
> We could even think about moving more towards tile-based approach to
> rendering of map canvas, with the advantage of being able to cache map
> tiles from previous canvas redraws for the same scale. This would
> allow instant appearance of areas previously rendered with lower CPU
> use at the expense of consuming more memory and having more
> complicated logic for labeling.
> 
> Regards
> Martin___
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] Incremental drawing possible?

[Neumann, Andreas]

Hi Martin, 

I noticed that loading and redraw only happens when the mouse button is
released after the panning operation. While I understand the reasoning
for this (definitely on the safe side and no unnecessary redraws), I
wonder, if for WMTS, loading and display could already happen while
panning and the mouse button isn't yet released, e.g. triggered whenever
a certain threshold of panning distance (e.g. in percent of the last
extent) was surpassed. 

This would be even nicer than the current behaviour. Or are there
technical reasons, not to do that? Google maps works like this. It
redraws while panning. 

Thanks, 

Andreas

> Since QGIS 2.18 the instant preview works also with WMTS rasters:
> https://www.qgis.org/en/site/forusers/visualchangelog218/index.html#feature-preview-of-raster-tiles-wmts-and-xyz-layers
> 
> Regards
> Martin
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] QGIS Server 2.x: issue with @map_scale variable vs. $scale

[Neumann, Andreas]

Hi, 

In a QGIS project that should be published with QGIS Server, I used the
@map_scale variable to define the font size with an expression,
depending on the map scale. It works fine on QGIS Desktop, but on QGIS
server GetMap requests it fails - the font-size (defined in map units)
is constant and doesn't react to my scale dependent rule. The
interesting thing, is, that the same rule works fine in GetPrint
requests. 

If I change my rule to use $scale instead of @map_scale, my label rule
works fine. 

Could it be that the @map_scale variable doesn't work in QGIS server
GetMap requests? 

Here is my expression: 

CASE
   WHEN @map_scale <= 251 THEN 1
   WHEN @map_scale > 251 AND @map_scale <= 501 THEN 2
   WHEN @map_scale > 501 AND @map_scale <= 1001 THEN 3
   WHEN @map_scale > 1001 AND @map_scale <= 2001 THEN 4
   WHEN @map_scale > 2001 AND @map_scale <= 3001 THEN 6
   WHEN @map_scale > 3001 AND @map_scale <= 4001 THEN 7
   WHEN @map_scale > 4001  THEN 8
END 

Thanks for your ideas. 

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

Re: [QGIS-Developer] Trouble compiling QGIS on CentOS - WFS provider related

[Neumann, Andreas]

Thanks a lot for the fix - it compiles fine now. 

Sorry for having such an old qt version! 

Andreas 

On 2017-07-03 13:27, Even Rouault wrote:

> On lundi 3 juillet 2017 13:20:26 CEST Neumann, Andreas wrote: 
> 
>> Hi, 
> 
>> 
> 
>> I am trying to compile the latest 2.18 branch on CentOS 7 but fail to 
> 
>> build. The error message is: 
> 
>> 
> 
>> --- 
> 
>> 
> 
>> /home/svc/dev/QGIS/src/providers/wfs/qgswfsprovider.cpp: In member 
> 
>> function 'bool QgsWFSProvider::readAttributesFromSchema(QDomDocument&, 
> 
>> const QString&, 
> 
>> /home/svc/dev/QGIS/src/providers/wfs/qgswfsprovider.cpp:1283:69: error: 
> 
>> 'QStringLiteral' was not declared in this scope 
> 
>> QString ref = attributeElement.attribute( QStringLiteral( "ref" ) 
> 
>> ); 
> 
>> ^ 
> 
>> make[2]: *** 
> 
>> [src/providers/wfs/CMakeFiles/wfsprovider.dir/qgswfsprovider.cpp.o] 
> 
>> Error 1 
> 
>> make[1]: *** [src/providers/wfs/CMakeFiles/wfsprovider.dir/all] Error 2 
> 
>> make: *** [all] Error 2 
> 
>> 
> 
> Ah sorry for that. I just pushed a fix. 
> 
> Even 
> 
> -- 
> 
> Spatialys - Geospatial professional services 
> 
> http://www.spatialys.com___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Trouble compiling QGIS on CentOS - WFS provider related

[Neumann, Andreas]

Hi, 

I am trying to compile the latest 2.18 branch on CentOS 7 but fail to
build. The error message is: 

--- 

/home/svc/dev/QGIS/src/providers/wfs/qgswfsprovider.cpp: In member
function 'bool QgsWFSProvider::readAttributesFromSchema(QDomDocument&,
const QString&,
/home/svc/dev/QGIS/src/providers/wfs/qgswfsprovider.cpp:1283:69: error:
'QStringLiteral' was not declared in this scope
 QString ref = attributeElement.attribute( QStringLiteral( "ref" )
);
 ^
make[2]: ***
[src/providers/wfs/CMakeFiles/wfsprovider.dir/qgswfsprovider.cpp.o]
Error 1
make[1]: *** [src/providers/wfs/CMakeFiles/wfsprovider.dir/all] Error 2
make: *** [all] Error 2 

--- 

Probably related to the latest fix
https://github.com/qgis/QGIS/commit/bc49b5ea84aee01fdc7e0613595317767d58603e
? 

Thanks if you have any ideas. 

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

Re: [QGIS-Developer] Processing 3.0: Possible change to the Convex Hull algorithm

[Neumann, Andreas]

Hi, 

I also think that the logical solution would be to aggregate the
attributes when grouping and allow the user to specify which aggregate
function to use for each attribute. 

Just randomly using the attributes of the first feature doesn't really
makes sense to me. In 99% of the  

Now that we have aggregate functionality in QGIS - are there technical
reasons for not using these aggregate functions? 

Just a hint, because about 1 year ago we paid Nyall for these aggregate
functions and of course we are interested that these are used more and
more in QGIS ;-) 

BTW: FME from safe software has an aggregate widget/functionality
available whenever something is grouped. QGIS should do the same. I
don't see why not. 

Andreas 

On 2017-06-30 07:47, Matthias Kuhn wrote:

> On 6/29/17 10:21 AM, G. Allegri wrote: 
> 
> 1. Allowing multiple field selection for grouping
> 2. Keeping attributes of first feature when grouping 
> 
> I will accept this criteria, obviously, if it's the preferred solution for 
> the mosts.  
> I just want to report that many users (partecipants to courses or customers) 
> say they find having the "first feature value" misleading.  
> I agree with them. I would set the field values only for the grouping fields, 
> having the same value within the group, and set null for the other fields. 
> 
> The problem raises during a long workflow. At some point you obtain a dataset 
> with unconsisten field values, and it's not always obvious to know when 
> and.which field value was set miningless.

In the long run the most flexible solution will be to allow specifying
the aggregate function applied to each field individually ("first/any",
"mean", "mode", "max"...).

No worries if it's not implemented right now, but please keep the code
modular enough to introduce this easily later down the road. Without
manually editing each algorithm that supports grouping.

A possible approach to this would be a parameter
"ParamterFieldAggregation" that offers a standard gui to configure the
aggregation behavior (fieldA: min; fieldB: mean; fieldC: any; fieldD:
mean(expression("numBirds2017 - numBirds2000")) ). 

Matthias

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

[QGIS-Developer] Expression question: formatting a decimal nr to a defined format

[Neumann, Andreas]

Hi, 

In a QGIS expression I wanted to format a decimal nr to a fixed format:
4 digits (with leading zeros) before the decimal point and then a fixed
3 decimal places with trailing zeros if necessary. 

e.g. 

4.5 should become 0004.500 

78.45 should become 0078.450 

Is there an existing expression function for that or would I have to
create my own custom Python expression using the format() method in
Python? 

Thanks, 

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

Re: [QGIS-Developer] Backporting support for relative SVG paths in project files

[Neumann, Andreas]

Hi Victor, 

Sounds like a useful improvement for QGIS 2.18 that I'd like to see
back-ported! I think relative-path support should be everywhere. If not,
it can be regarded a bug. 

Please make sure they don't break anything in QGIS server! 

Andreas 

On 2017-06-22 08:51, Victor Olaya wrote:

> Hi all,
> 
> I would like to know your opinion about backporting the support for
> relative paths for marker files in project files to 2.18. It's an
> interesting feature that would be good to have without having to
> depend on QGIS 3.
> 
> Not sure if it is supposed to be working  in 2.18 (It is not, at the
> moment, but I don't know if it's a bug), so that's why I am asking
> 
> Thanks!
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Keyword args for python bindings?

[Neumann, Andreas]

+1 

As an occasional Python developer I would welcome this improvement in
readability of the code. 

Andreas 

On 2017-06-22 04:33, Nyall Dawson wrote:

> Hi all,
> 
> Been thinking about this lately, with all the excellent work which is
> being done on sipify and improving the usability of the PyQGIS through
> docstrings and such... do we want to also turn on named argument
> support for PyQGIS methods?
> 
> I gather it's just a matter of adding the annotation KeywordArgs=All
> to function definitions. We should be able to code this into sipify to
> handle this automatically.
> 
> I'd see the big benefit here would be readability of python code - no
> more someMethod( True,False, 5, None) deciphering!
> 
> The downside would be that the argument names would become part of
> stable API. We've still gots lots of unhelpful argument names (things
> like 's', 'c', ), so that's a potential downside if these get
> locked in (although maybe we can fix them before freeze).
> 
> Thoughts?
> 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___
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] Variable syntax: $ vs @

[Neumann, Andreas]

Hi Nathan, 

Thank you for the explanation. Makes sense. I will pass this on in the
workshop. 

Andreas 

On 2017-06-19 14:12, Nathan Woodrow wrote:

> Hey Andreas, 
> 
> They are really two different things.  $geometry is really a function that 
> takes no arguments. This has been deprecated in favour calling with () e.g 
> geometry().  @ is only for variables. 
> 
> So you can explain it that $ used to be a shorthand way of calling a function 
> that took no arguments which has now been replaced with () at the end to call 
> it. $area = area().  This becomes important because now we support optional 
> arguments meaning you can take 0 to N arguments. 
> 
> - Nathan  
> 
> On Mon, Jun 19, 2017 at 9:53 PM, Neumann, Andreas <a.neum...@carto.net> wrote:
> 
>> Hi, 
>> 
>> While preparing for a workshop on expressions I wonder how to explain why 
>> some variables are referenced with the $ sign (like $geometry) while other 
>> variables start with the @ sign, like @row_number, @layer_name. 
>> 
>> I know that it has historical reasons and that variables with the @ sign are 
>> newer and are implemented using a different technology. 
>> 
>> But are there plans to get rid of the old $ sign notation and move 
>> everything to the @ sign notation? 
>> 
>> Just wonder how I best explain this to the participants of the workshop. 
>> 
>> Thanks for your reply, 
>> 
>> Andreas
>> 
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer [1]
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer [1]

  

Links:
--
[1] https://lists.osgeo.org/mailman/listinfo/qgis-developer___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Variable syntax: $ vs @

[Neumann, Andreas]

Hi, 

While preparing for a workshop on expressions I wonder how to explain
why some variables are referenced with the $ sign (like $geometry) while
other variables start with the @ sign, like @row_number, @layer_name. 

I know that it has historical reasons and that variables with the @ sign
are newer and are implemented using a different technology. 

But are there plans to get rid of the old $ sign notation and move
everything to the @ sign notation? 

Just wonder how I best explain this to the participants of the workshop.


Thanks for your reply, 

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

Re: [QGIS-Developer] Geodesic Measure Tool With Bearing Information

[Neumann, Andreas]

+1 for getting these improvements in QGIS core, rather than in a plugin.


fyi: https://map.geo.admin.ch/ has an interesting "all-in-one" measure
tool, which could server as an inspiration for QGIS. 

If you start with a new measure line, you first get a circle with
distance and bearing. It also shows markers with labels along the line
with round distances (e.g. 500m, 1000m, etc.). If you close the polygon
by going back to the first vertex, it autosnaps and shows the area. So
it is really just one single tool, but it helps to show distances,
bearings and areas - along with an elevation profile. 

Greetings, 

Andreas 

On 2017-06-12 10:27, Nyall Dawson wrote:

> On 10 June 2017 at 02:30, C Hamilton  wrote: 
> 
>> Several weeks ago I had proposed a geodesic measure tool that also includes
>> the bearing from point A to B and bearing from B to A. Nyall suggested that
>> this capability be added to the QGIS measure tool. The question is would you
>> want this with the QGIS measure tool or should it be a separate plugin?
> 
> My strong vote would be towards extending the QGIS measure tool. To me
> that's a better solution then requiring users to download a plugin,
> and having to reimplement all the (complex) logic of the measure tool
> again in a python plugin.
> 
>> 1. Where the current measure tool has 'Segments' there would be two more
>> columns with 'Bearing to' and 'Bearing from'.
> 
> Sounds good!
> 
>> 2. I would like to see a check box or selection widget of some sort that
>> chooses between using Geodesic math or the current method of calculating the
>> distances which I am still unsure on how it is doing its calculations.
> 
> If you expand down the info box you'll get a detailed description of
> exactly how QGIS is calculating the distances. Is there something
> missing there?
> 
>> Right now it could use the Vincinty algorithms in QGIS to calculate the
>> distances, but eventually I would like to see the geographiclib algorithms
>> used.
> 
> I'd start with the bearing changes (since they are self contained, and
> the methods for calculating bearing are already present in the QGIS
> api). Then using geographiclib could be discussed as a separate set of
> changes, to be decided on its own merit. If you mix these two changes
> it's likely to get bogged down as one or other part of the changes are
> debated.
> 
>> If this is of interest then I will attempt to get a QGIS development
>> environment running to help make the changes to the core measure tool;
>> otherwise, I will just create a plugin to do this. If I create a plugin I
>> will use the geographiclib python library to do the calculations.
>> 
>> Thoughts?
> 
> Go the core! Let us know if you need help setting up a dev
> environment. It's actually much easier for 3.0 then it was for 2.x
> (especially on windows).
> 
> 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___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] QGIS 3: feedback on Save As Image / PDF

[Neumann, Andreas]

Hi, 

The new Save as Image / PDF function in the project menu in QGIS 3 is
very useful! Thanks for developing it! 

I have, however, a suggestion for improvement: it would be very useful
if the user could interactively select an extent in the map canvas. I
believe such an extent picker widget already exists in the QGIS code
base. I think it is used in the various places where users have to
select an extent, e.g. in the gdal raster clipper tool. 

And even more useful would it be if such an interactive selection could
be restricted to a certain width / height ratio. 

Use case: you want to copy map extents for a presentation. You know that
you export for a 4:3 ratio or 16:9 ratio. Wouldn't it be handy if you
could interactively choose your extent and restrict it to that ratio? It
would save us from the extra step, that I would have to open it in
Gimp/Photoshop and select the extent in there. 

Any thoughts? 

Thanks, 

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

[QGIS-Developer] QGIS 3 migration: issue with projection

[Neumann, Andreas]

Hi, 

I noticed that with the current nightly QGIS 3 builds, that my 2.18
projects open with "no projection" instead of my national projection
(EPSG:2056)  

As a result, the map scale is totally bogus and symbology messed up. 

Am I the only one having this issue? Do you have any idea how this can
be fixed? 

Thanks, 

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

Re: [QGIS-Developer] Split QGIS Server into it's own repo?

[Neumann, Andreas]

I agree with most other responses. I would like to see QGIS server
remain in the main repo. One of the reasons of the 3Liz refactoring is
to remove redundant code from Server and rely more on the core parts of
the QGIS API, to be better compatible. 

Andreas 

On 2017-05-22 15:26, Giovanni Manghi wrote:

> At the moment I think it would be best for QGIS Server to live in it's own
> repo mainly because it means the development process and cycle can be
> different to desktop if that is needed.
> 
> That's exactly what I would *not* like to see.

completely agree with Alessandro.

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___
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] multi-layered pdf, attribute support in pdf outputs

[Neumann, Andreas]

Hi Hilpers, 

I'll explain why this isn't so easy to solve - even with GDAL. 

QGIS has a very rich set of symbology and labeling options. For PDF
generation it relies on the qt libraries - which did not support
attributes and layered PDFs so far - at least in version 4 that QGIS
used so far. I don't know if qt5 improved in that respect. GDAL/OGR has
a quite limited set of feature styling options. There is no easy
translation between the two - and in 95% of the cases your map would
look different when translating to OGR/GDAL - unless you rasterize all
layers - which is probably not what you want. 

So unless either qt supports output in layered PDF and supports
attributes, it won't happen any time soon. Alternatively, QGIS could use
an alternative PDF library, which probably isn't trivial either. 

Unless someone would heavily invest in development time or money, or
better both - this probably won't happen. 

Your best option would be to try to improve qt5, so that it supports
layered PDFs and attributes or try to switch to a different PDF renderer
- not sure how feasible that would be. 

Andreas 

On 2017-05-12 08:18, hilpers wrote:

> Hello everyone, 
> 
> i am wondering whether it is going to be possible to generate multi-layered
> pdfs using print composer anytime soon. While GDAL supports that QGIS does
> not seem to do so yet. For making maps available to the public it would be
> practival to implement layer attributes within pdf (similarly to ArcGIS). Is
> this technically possible using GDAL?
> 
> Thanks, 
> hilpers
> 
> --
> View this message in context: 
> http://osgeo-org.1560.x6.nabble.com/multi-layered-pdf-attribute-support-in-pdf-outputs-tp5320273.html
> Sent from the QGIS - Developer mailing list archive at Nabble.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 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] Troubles with Python init script for forms

[Neumann, Andreas]

Hi, 

Problem solved. I forgot to specify the "Function Name" in the widget.
After doing that, it works fine. 

On the other issue: it seems like it "autoloads" the code every time I
did some changes in the code. So that seems to work well either. 

Andreas 

On 2017-05-08 17:40, Neumann, Andreas wrote:

> Hi, 
> 
> It's been a long time since I last wrote python init scripts for forms. 
> 
> Now I have troubles writing even the simplest code. Nothing happens if I 
> click on a feature. The form opens, but no error messages and no reaction to 
> my code ... This is on QGIS 2.18.7. I use the mode "Provide code in this 
> dialog" and add the code in the "Python init code" widget of the "Fields" 
> tab. 
> 
> Below is my really simple code that should write something to the message bar 
> when the form is loaded: 
> 
> -- 
> 
> # -*- coding: utf-8 -*-
> """
> QGIS-Formulare können eine Python-Funktion haben, die beim Öffnen des 
> Formulars gestartet wird. 
> 
> Hier kann dem Formular Extra-Logik hinzugefügt werden. 
> 
> Der Name der Funktion wird im Feld "Python-Init-Function" angegeben.
> Ein Beispiel:
> """
> from PyQt4.QtGui import QWidget
> 
> def my_form_open(dialog, layer, feature):
> msgBar = iface.messageBar()
> msgBar.pushInfo("Message from init script: ","Hi There") 
> 
>  
> 
> My other question: 
> 
> If I change the code in the "Fields" widget - would it "auto-load" or do I 
> have to do something to trigger a reload of the script? 
> 
> -- 
> 
> Thank you for your help, 
> 
> 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___
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] Troubles with Python init script for forms

[Neumann, Andreas]

Hi, 

It's been a long time since I last wrote python init scripts for forms. 

Now I have troubles writing even the simplest code. Nothing happens if I
click on a feature. The form opens, but no error messages and no
reaction to my code ... This is on QGIS 2.18.7. I use the mode "Provide
code in this dialog" and add the code in the "Python init code" widget
of the "Fields" tab. 

Below is my really simple code that should write something to the
message bar when the form is loaded: 

-- 

# -*- coding: utf-8 -*-
"""
QGIS-Formulare können eine Python-Funktion haben, die beim Öffnen des
Formulars gestartet wird. 

Hier kann dem Formular Extra-Logik hinzugefügt werden. 

Der Name der Funktion wird im Feld "Python-Init-Function" angegeben.
Ein Beispiel:
"""
from PyQt4.QtGui import QWidget

def my_form_open(dialog, layer, feature):
msgBar = iface.messageBar()
msgBar.pushInfo("Message from init script: ","Hi There") 

 

My other question: 

If I change the code in the "Fields" widget - would it "auto-load" or do
I have to do something to trigger a reload of the script? 

-- 

Thank you for your help, 

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

[QGIS-Developer] Per Project Python custom expressions in QGIS 3.0?

[Neumann, Andreas]

Hi, 

My recent custom Python expressions I developed. clearly belong to a
specific project and can't be used in the context of a different project
- because they rely on the presence of specific data layers. 

Question: could we introduce "per project" custom Python expresssions in
QGIS 3.0 as opposed to per user ones? The idea would be to store them in
the project file. This would make the deployment of the project much
easier, as I wouldn't have to also distribute the expression functions
to the users who want to use this specific project. 

Thanks for your feedback/discussion, 

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

Re: [QGIS-Developer] Python example with aggregate calculation

[Neumann, Andreas]

Hi,

Finally, with the support from Matthias, I got a working example of my 
custom Python expression:


@qgsfunction(args='auto', group='Custom', usesgeometry=False)
def get_ews_anlage_nr(gemeinde, feature, parent):
AnlageLayer = 
QgsMapLayerRegistry.instance().mapLayersByName('Anlage')[0]

aggParams = QgsAggregateCalculator.AggregateParameters()
aggParams.filter = 'substr("anlage_nr",1,2) = \''+gemeinde+'\''
maxVal = 
AnlageLayer.aggregate(QgsAggregateCalculator.Max,'to_int(substr("anlage_nr",4,4))',aggParams)[0]

return maxVal

When I define the QgsAggregateCalculator.AggregateParameters() upfront 
separately it works fine. First I was trying to set the parameter 
directly within AnlageLayer.aggregate() but failed to find the direct 
syntax of the QgsAggregateCalculator.AggregateParameters() parameters. 
There are hardly any examples out there. But hey - finally it works!


Have a nice weekend!
Andreas

On 2017-05-05 15:55, Neumann, Andreas wrote:


Hi,

I have a basic example using aggregates:

--

@qgsfunction(args='auto', group='Custom', usesgeometry=False)
def get_ews_anlage_nr(gemeinde, feature, parent):
AnlageLayer = 
QgsMapLayerRegistry.instance().mapLayersByName('Anlage')[0]

maxVal = AnlageLayer.aggregate(4,'to_int(substr("anlage_nr",4,4))')[0]
return maxVal

---

But I still have two questions:

1. I still struggle to define a filter. I can't find the correct syntax 
how to define that filter string.


2. the first parameter "4" stands for "Max" aggregate (according to 
http://qgis-python.kartoza.com/docs/core/other/QgsAggregateCalculator.html#class-qgsaggregatecalculator 
). Could this code be written more "readable" by specifying "Max" 
instead of 4?


Thanks,

Andreas

On 2017-05-05 14:31, Neumann, Andreas wrote:


Hi,

Does someone have an example how to use QgsVectorLayer.aggregate() 
from Python?


How would the syntax for the parameters in the 
QgsAggregateCalculator.calculate() method look like in Python?


Thanks,

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


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

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

Re: [QGIS-Developer] Python example with aggregate calculation

[Neumann, Andreas]

Hi, 

I have a basic example using aggregates: 

-- 

@qgsfunction(args='auto', group='Custom', usesgeometry=False)
def get_ews_anlage_nr(gemeinde, feature, parent):
AnlageLayer =
QgsMapLayerRegistry.instance().mapLayersByName('Anlage')[0]
maxVal = AnlageLayer.aggregate(4,'to_int(substr("anlage_nr",4,4))')[0]
return maxVal 

--- 

But I still have two questions: 

1. I still struggle to define a filter. I can't find the correct syntax
how to define that filter string. 

2. the first parameter "4" stands for "Max" aggregate (according to
http://qgis-python.kartoza.com/docs/core/other/QgsAggregateCalculator.html#class-qgsaggregatecalculator
). Could this code be written more "readable" by specifying "Max"
instead of 4? 

Thanks, 

Andreas 

On 2017-05-05 14:31, Neumann, Andreas wrote:

> Hi, 
> 
> Does someone have an example how to use QgsVectorLayer.aggregate() from 
> Python? 
> 
> How would the syntax for the parameters in the 
> QgsAggregateCalculator.calculate() method look like in Python? 
> 
> Thanks, 
> 
> 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___
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] Python example with aggregate calculation

[Neumann, Andreas]

Hi, 

Does someone have an example how to use QgsVectorLayer.aggregate() from
Python? 

How would the syntax for the parameters in the
QgsAggregateCalculator.calculate() method look like in Python? 

Thanks, 

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

[QGIS-Developer] Custom python expression question

[Neumann, Andreas]

Hi, 

If one creates a custom python expression, one gets a reference to the
"feature" and the "parent". 

Question: what is "parent" referring to? What object type is it? 

Is it somehow possible in the Python script to get a reference to the
layer the feature is part of? Would there be some example Python code
around that shows how one can get access to the layer the feature
belongs to? 

Thank you for any hints, 

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

[Qgis-developer] quickfinder plugin: No module named qgsfieldexpressionwidget

[Neumann, Andreas]

Hi, 

I am trying to get QGIS quickfinder running (the version from github,
not the packaged version), because I want to test the new Postgres
search functionality. 

I checked out the source from https://github.com/3nids/quickfinder (the
master_2 version) and also the qsettingsmanager. I changed the Makefile
to reflect my Pythonpath. The make and make deploy went fine, but when I
load the plugin I get the error message 

 

2017-05-03T09:55:09 1 Traceback (most recent call last): 

File "C:/Program Files/OSGEO4~1/apps/qgis/./python\qgis\utils.py", line
333, in startPlugin 

plugins[packageName] = package.classFactory(iface) 

File "C:/Users/nend/.qgis2/python/plugins\quickfinder\__init__.py", line
28, in classFactory 

from .quickfinder_plugin import QuickFinder 

File "C:/Program Files/OSGEO4~1/apps/qgis/./python\qgis\utils.py", line
607, in _import 

mod = _builtin_import(name, globals, locals, fromlist, level) 

File
"C:/Users/nend/.qgis2/python/plugins\quickfinder\quickfinder_plugin.py",
line 36, in  

from gui.configuration_dialog import ConfigurationDialog 

File "C:/Program Files/OSGEO4~1/apps/qgis/./python\qgis\utils.py", line
607, in _import 

mod = _builtin_import(name, globals, locals, fromlist, level) 

File
"C:/Users/nend/.qgis2/python/plugins\quickfinder\gui\configuration_dialog.py",
line 38, in  

from project_search_dialog import ProjectSearchDialog 

File "C:/Program Files/OSGEO4~1/apps/qgis/./python\qgis\utils.py", line
607, in _import 

mod = _builtin_import(name, globals, locals, fromlist, level) 

File
"C:/Users/nend/.qgis2/python/plugins\quickfinder\gui\project_search_dialog.py",
line 29, in  

from ..ui.ui_projectsearch import Ui_ProjectSearch 

File "C:/Program Files/OSGEO4~1/apps/qgis/./python\qgis\utils.py", line
607, in _import 

mod = _builtin_import(name, globals, locals, fromlist, level) 

File
"C:/Users/nend/.qgis2/python/plugins\quickfinder\ui\ui_projectsearch.py",
line 123, in  

from qgsfieldexpressionwidget import QgsFieldExpressionWidget 

File "C:/Program Files/OSGEO4~1/apps/qgis/./python\qgis\utils.py", line
607, in _import 

mod = _builtin_import(name, globals, locals, fromlist, level) 

ImportError: No module named qgsfieldexpressionwidget 

 --- 

Is qgsfieldexpressionwidget a separate Python plugin or why is not
found? 

Thank you for any hints, 

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

[Qgis-developer] No module named

[Neumann, Andreas]

Hi, 

I am trying to get QGIS quickfinder running (the version from github,
not the packaged version), because I want to test the new Postgres
search functionality. 

I checked out the source from https://github.com/3nids/quickfinder (the
master_2 version) and also the qsettingsmanager. I changed the Makefile
to reflect my Pythonpath. The make and make deploy went fine, but when I
load the plugin I get the error message 

 

2017-05-03T09:55:09 1 Traceback (most recent call last): 

File "C:/Program Files/OSGEO4~1/apps/qgis/./python\qgis\utils.py", line
333, in startPlugin 

plugins[packageName] = package.classFactory(iface) 

File "C:/Users/nend/.qgis2/python/plugins\quickfinder\__init__.py", line
28, in classFactory 

from .quickfinder_plugin import QuickFinder 

File "C:/Program Files/OSGEO4~1/apps/qgis/./python\qgis\utils.py", line
607, in _import 

mod = _builtin_import(name, globals, locals, fromlist, level) 

File
"C:/Users/nend/.qgis2/python/plugins\quickfinder\quickfinder_plugin.py",
line 36, in  

from gui.configuration_dialog import ConfigurationDialog 

File "C:/Program Files/OSGEO4~1/apps/qgis/./python\qgis\utils.py", line
607, in _import 

mod = _builtin_import(name, globals, locals, fromlist, level) 

File
"C:/Users/nend/.qgis2/python/plugins\quickfinder\gui\configuration_dialog.py",
line 38, in  

from project_search_dialog import ProjectSearchDialog 

File "C:/Program Files/OSGEO4~1/apps/qgis/./python\qgis\utils.py", line
607, in _import 

mod = _builtin_import(name, globals, locals, fromlist, level) 

File
"C:/Users/nend/.qgis2/python/plugins\quickfinder\gui\project_search_dialog.py",
line 29, in  

from ..ui.ui_projectsearch import Ui_ProjectSearch 

File "C:/Program Files/OSGEO4~1/apps/qgis/./python\qgis\utils.py", line
607, in _import 

mod = _builtin_import(name, globals, locals, fromlist, level) 

File
"C:/Users/nend/.qgis2/python/plugins\quickfinder\ui\ui_projectsearch.py",
line 123, in  

from qgsfieldexpressionwidget import QgsFieldExpressionWidget 

File "C:/Program Files/OSGEO4~1/apps/qgis/./python\qgis\utils.py", line
607, in _import 

mod = _builtin_import(name, globals, locals, fromlist, level) 

ImportError: No module named qgsfieldexpressionwidget 

 --- 

Is qgsfieldexpressionwidget a separate Python plugin or why is not
found? 

Thank you for any hints, 

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

Re: [Qgis-developer] Are there plans to create a unique "Add layer" tool?

[Neumann, Andreas]

Hi Alexandre, 

hm - I don't think we can allow more docking space for additional panels
taking more away from the  

Assuming you work on a small Netbook screen: if you have the layer panel
on the left and the styling panel on the right, you have a few pixels
left for the map itself. If you add another column for the browser
panel, you won't even have enough space for all the panels. 

Now you could say, one shouldn't use a Netbook for QGIS - but how many
times did you have to present on a video projector that only supports
1024x768, or even worse 800x600. It would be nightmare if there is an
additional panel. 

Andreas 

On 2017-05-02 16:10, Alexandre Neto wrote:

> Looking into the proposal, makes me wonder if it would be possible to add the 
> Browser panel (that will need to be big enough for the dialogs) to the right 
> of the Layers Panel (assuming the default). That would imply a new area to 
> allow docking panels. 
> 
> Alexandre Neto  escreveu no dia segunda, 1/05/2017 às 
> 00:02: 
> Great, thanks for the update!  
> 
> Anita Graser  escreveu no dia domingo, 30/04/2017 às 
> 21:19: 
> 
> Hi, 
> 
> We just finished our discussion on the unified add layer dialog and we are 
> optimistic that it will make its way into 3.0. You can find a short summary 
> of the planned steps at the end of the doc: 
> 
> https://docs.google.com/document/d/1aMX9jOfl10q8oETRzOHSHnRpHCc7UJ1dDnCCq3VyTAY/edit?usp=sharing
>  
> 
> Please feel free to ask if there are any questions. 
> 
> Best wishes, 
> Anita 
> 
> On Fri, Apr 28, 2017 at 1:28 PM, Stéphane Henriod  
> wrote:
> 
> Very good! 
> 
> Looking forward to hearing the outcome of these discussions! 
> 
> Cheers and thanks for your support here 
> 
> Stéphane 
> 
> "When you travel, remember that a foreign country is not designed to make you 
> comfortable. It is designed to make its own people comfortable." -- Clifton 
> Fadiman
> 
> 2017-04-27 22:54 GMT+06:00 Alexandre Neto :
> 
> Hi, 
> 
> Some of my colleagues will be in Essen for QGIS Developers meeting. They will 
> bring this up, and try to get the opinion of other developers. I'm sure 
> everyone there will be interested in contributing with ideas for it.
> 
> So, let's wait for now.
> 
> Thanks for your work. 
> 
> Stéphane Henriod  escreveu no dia quinta, 27/04/2017 
> às 09:42: Hi all 
> 
> I would be more than happy to help push this new feature forward but I am not 
> really sure what is needed now? 
> 
> Alexandre, I think you mentioned that your company might be interested to 
> implement this unique "Add layer" button. Does the Gdoc now contain 
> sufficient information for you to move on and identify what can realistically 
> be done? Or is there a need for more polishing?
> 
> Thanks in advance! 
> 
> Stéphane 
> 
> Le vendredi 21 avril 2017, Stéphane Henriod  a écrit :
> 
> Done! 
> 
> https://docs.google.com/document/d/1aMX9jOfl10q8oETRzOHSHnRpHCc7UJ1dDnCCq3VyTAY/edit?usp=sharing
>  
> 
> "When you travel, remember that a foreign country is not designed to make you 
> comfortable. It is designed to make its own people comfortable." -- Clifton 
> Fadiman
> 
> 2017-04-20 14:47 GMT+06:00 Alexandre Neto :
> 
> Fine with me.  
> 
> Stéphane Henriod  escreveu no dia terça, 18/04/2017 às 
> 05:46: Hi all 
> 
> Harrissou has quite intensively re-organised the doc, which is now, IMO, much 
> clearer. Thanks for that! 
> 
> But lots of changes are in "suggestion mode". I'd like to accept all those 
> changes to increase the clarity and readability. Any objection on this? 
> 
> Thanks and cheers 
> 
> Stéphane 
> 
> Le mercredi 12 avril 2017, Alexandre Neto  a écrit :
> 
> Hi Stéphane, 
> 
> I believe it's a great starting point, very complete (I would not 
> remember/consider some types of data).
> 
> We still need to fill the second page and discuss the possible UI/UX 
> implementation. Then, we will need some developers (I'm not a developer) to 
> consider the requests and filter what would be hard or impossible to tackle. 
> 
> Our best chance to have this implemented is by doing baby steps. I would not 
> consider more data format/providers than the ones we have in the manage 
> layers toolbar in this first phase. 
> 
> Thanks! 
> 
> Stéphane Henriod  escreveu no dia terça, 11/04/2017 às 
> 12:57: Hi Alexandre 
> 
> this is indeed great! 
> 
> Is the gdoc as it is now helpful enough for you to design a possible 
> implementation? Or, if not, what other inputs / comments would be necessary? 
> 
> Cheers 
> 
> Stéphane 
> 
> Le lundi 10 avril 2017, Alexandre Neto  a écrit :
> 
> Hello all,
> 
> At Boundless we are planning to put some development time in this "unified 
> add layer" button/feature. As others already did, our idea was to use the 
> browser 

Re: [Qgis-developer] PostGIS Rasters

[Neumann, Andreas]

Hi Rob, 

Thanks for testing. Good to know that pyramids now work fine with
postgis raster. It was a while back since I last tested. 

If you can log the SQL queries on the server by increasing the logging
level, than it you can prove which tables QGIS is querying. 

Andreas 

On 2017-04-11 15:29, Robert Hewlett wrote:

> Hi, 
> 
> I am using 2.18.5. and the performance seems okay to good.  
> 
> The ortho data in the DB are tiled and have overviews built. 
> 
> When working with the data within QGIS it seems that the overviews are 'in 
> play'. 
> 
> I will see if I can write some SQL to prove one way or the other.  
> 
> The test vm on the back-end: CentOS 7, Postgres 9.6 with PostGIS 2.3.2 (all 
> repo based). 
> 
> The front-end will move to 2.18.6 later today. 
> 
> Rob 
> 
> On Mon, Apr 10, 2017 at 10:56 PM, Neumann, Andreas <a.neum...@carto.net> 
> wrote:
> 
> Hi, 
> 
> If there will be a new Postgis raster provider for QGIS, it should also 
> support the pyramid tables (separate tables) - which as far as I know - is 
> not yet supported. If you add a layer from DB-manager you load a fixed 
> resolution and the other pyramid tables won't be used. Thats one of the 
> reasons, rasters in Postgis display quite slow in QGIS. 
> 
> Andreas
> 
> On 2017-04-11 04:16, Robert Hewlett wrote: 
> 
> Hi, 
> 
> Are there plans to build a plugin for PostGIS rasters similar to the vector 
> plugin. I know how to add the rasters from the DB manager but the 
> experience/workflow is much different and the connections go 'stale'. 
> 
> I am willing to help code it. 
> 
> Regards, 
> 
> Rob 
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer [1]
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer [1]

  

Links:
--
[1] https://lists.osgeo.org/mailman/listinfo/qgis-developer___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] PostGIS Rasters

[Neumann, Andreas]

Hi, 

If there will be a new Postgis raster provider for QGIS, it should also
support the pyramid tables (separate tables) - which as far as I know -
is not yet supported. If you add a layer from DB-manager you load a
fixed resolution and the other pyramid tables won't be used. Thats one
of the reasons, rasters in Postgis display quite slow in QGIS. 

Andreas 

On 2017-04-11 04:16, Robert Hewlett wrote:

> Hi, 
> 
> Are there plans to build a plugin for PostGIS rasters similar to the vector 
> plugin. I know how to add the rasters from the DB manager but the 
> experience/workflow is much different and the connections go 'stale'. 
> 
> I am willing to help code it. 
> 
> Regards, 
> 
> Rob 
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS X3D processing

[Neumann, Andreas]

Hi, 

My knowledge is a bit limited - but from what I know the three
approaches are completely different: 

* QGIS2threejs: uses WebGL. Goal is to publish a small scene to the web,
independent from QGIS. QGIS is only used to prepare the scene.
WebGLS/ThreeJS is quite a low-level technology compared to X3D 

* X3D approach: more descriptive, human readable files. Similar to VRML
or SVG. Goal ist also publication of smaller scenes to the web. X3D
viewer may render either natively or through WebGL. X3D, compared to
WebGL/Threejs lowers the barrier for script or XML people to further
process the file after an export. The X3D concepts are easier to
understand than raw WebGL. 

* qt53D: Based on OpenGL. could lead to a good integration into QGIS
core. Not meant to be published to the web. 

Andreas 

On 2017-03-27 14:49, Andreas Plesch wrote:

> Let me share a project for interactive 3d visualization of qgis content on 
> the web using the geospatial component of the standardized X3D format. Code 
> and examples are on GitHub: 
> 
> https://github.com/andreasplesch/QGIS-X3D-Processing [1] 
> 
> This effort is similar to QGIS2Threejs but is just starting out and will use 
> quite a different approach. 
> 
> On the user list Paolo mentioned plans to use native qt5 3d facilities for 
> qgis3 as well (see below). Is there a repository or documentation to learn 
> more about this ? For example, it may be beneficial to use webGL enabled 
> webkit (perhaps in the processing results viewer). 
> 
> Any pointer or other feedback is very welcome, 
> 
> Andreas 
> 
> Date: Mon, 27 Mar 2017 08:15:36 +0200
> From: Paolo Cavallini 
> To: qgis-u...@lists.osgeo.org, qgis-developer
> 
> Subject: Re: [Qgis-user] QGIS X3D processing
> Message-ID: <6dab7995-95d0-21c6-c8b3-347f18ade...@faunalia.it>
> Content-Type: text/plain; charset=utf-8
> 
> Il 27/03/2017 01:52, Andreas Plesch ha scritto:
>> Hi Paolo,
>> 
>> 
>> Date: Sun, 26 Mar 2017 20:22:06 +0200
>> From: Paolo Cavallini > >
>> 
>> Il 26/03/2017 00:27, Andreas Plesch ha scritto:
>>> I would like to share a project for 3d visualization of Qgis
>> content by
>> ...
>>> This effort is similar to QGIS2Threejs but is just starting out
>> and will
>>> use quite a different approach.
>>>
>>> Any comment, feedback or thought is welcome,
>> 
>> Cool, thanks. AFAIK there are plans to use native Qt5 3D facilities,
>> have you had a look to this too?
>> 
>> 
>> I looked into using qt webkit and found that qt5 webkit supports webgl
>> (and probably a modern js engine?). That would be very interesting as it
>> would be possible to rely just on webkit and perhaps have some tighter
>> integration with the Qgis gui.
>> 
>> What would be a good place to learn more about QGIS3 plans to use native
>> Qt5 3d facilities ?
> 
> Hi Andreas,
> I do not know much. You can probably have a look to the work of Minoru
> Akagi, who started some early development on this.
> However, I think some core devs may be interested in joining the discussion.
> 
> -- 
> Andreas Plesch
> 39 Barbara Rd.
> Waltham, MA 02453 
> ___
> 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

  

Links:
--
[1] https://github.com/andreasplesch/QGIS-X3D-Processing
___
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] Creating crop marks / fold marks in print composer - drawing exact lines in print composer

[Neumann, Andreas]

Hi, 

We are trying to exactly (numerically) place lines (arrows or polylines)
in print composer - but it seems almost impossible: 

The two main problem are: 

* one cannot numerically edit vertices of an arrow or polyline element
* the lines box is larger than the actual line, which means the line
doesn't really end where the box ends. This makes it impossible to
numerically place and scale arrows lines. Also snapping doesn't work,
because of this.

Some other related problems: 

* neither arrows nor polyline snap to guide lines
* while arrows can be constrained to exact angles by pressing the
"shift" key, this doesn't seem to work with polylines.
* My crop marks could be points with the usual QGIS simple markers,
but I can't place a point in my print composer

My questions are: 

* is there an alternative that works now (in QGIS 2.18)? E.g. a plugin
that draws crop marks and fold marks?
* Are there any improvements planned for QGIS 3.0 in this respect?
* Can the issue that the selection box doesn't match the dimensions of
the arrows be fixed in QGIS 3.0?

Thanks, 

Andr

  ___
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] Changing behaviour of "show selected features" mode for attribute table

[Neumann, Andreas]

Hi Paolo, 

I am a -1 on having "show only selected features" on by default. I think
that huge/gigantic tables with performance issues are more an exception
than the rule. Of course in such cases the "show selected only" makes
sense and the project should probably retain this state. But in the
majority of other cases the tables are small enough that this is not an
issue and it would be annoying that one has to select features first for
seeing all the features. 

I also don't think we need any warnings. The top window bars clearly
shows the status of total / filtered / selected features. No need for
extra warnings. 

Andreas 

On 2017-03-07 08:08, Paolo Cavallini wrote:

> Il 07/03/2017 05:28, Nyall Dawson ha scritto:
> 
>> Does anyone object to this change landing for 3.0 and 2.18?
> 
> Of course it's a +1 from me.
> I wonder if it would be good to also:
> * set "show selected features" on by default
> * add a warning "no elemenent selected, please do a selection" or
> similar, to avoid the user to think the table is empty.
> All the best.

  ___
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] Changing behaviour of "show selected features" mode for attribute table

[Neumann, Andreas]

Hi Nyall, 

I am fine with your proposal. 

In fact, the current behaviour as you described it, can be regarded as a
bug. I agree with you. 

Andreas 

On 2017-03-07 05:28, Nyall Dawson wrote:

> Hi all,
> 
> I'd like to raise discussion about changing the behaviour of the "show
> selected features" mode in the attribute table.
> 
> Over the last couple of weeks I've pushed fixes to both 3.0 and
> (shortly) 2.18 to improve the performance of the attribute table when
> this mode is selected (Thanks to Faunalia and ENEL for sponsoring
> this!). With these changes *only* the selected features are fetched
> from providers to show in the attribute table, vs the current
> behaviour of fetching *everything* and then filtering out to the
> selection. It makes a huge difference for working with large layers.
> 
> Now - there's one last piece of this I'd like to land, but it changes
> the behaviour of this mode. Currently if you have the table set to
> "show selected features", but there's nothing selected, then ALL
> features are shown.
> 
> This kills the benefit of setting the table to show in this mode. If
> you accidentally open the table for a large layer with no selection,
> it'll force every feature to be fetched again.
> 
> I'd like to change this, so that no selection = nothing shows in the
> table. This means that users can safely set the attribute table to
> always show in "selected features" mode and be confident that they'll
> never hit the situation where every feature is fetched (unless of
> course they have selected *every* feature!).
> 
> Does anyone object to this change landing for 3.0 and 2.18?
> 
> 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

  ___
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] How do datum transformations work?

[Neumann, Andreas]

Hi, 

I am struggling to find out how datum transformations work -
specifically also under QGIS Server. 

I have a .gsb file (CHENYX06a.gsb) for Swiss datum transformations. It
is located under /usr/local/shar/proj/ where all the other .gsb files
are. 

I also set the DEFAULT_DATUM_TRANSFORM variable variable in my
fcgid.conf file: 

  FcgidInitialEnv DEFAULT_DATUM_TRANSFORM
"EPSG:21781/EPSG:2056/11/-1;EPSG:2056/EPSG:21781/-1/11" 

I checked the entries in the srs.db on the server in the table
tbl_datum_transform which has an entry: 

wkt_geom coord_op_code epsg_nr source_crs_code target_crs_code
coord_op_method_code p1 p2 p3 p4 p5 p6 p7 remarks scope preferred
deprecated area_of_use_code
NULL 11 15486 4149 4150 9615 0 

But how does QGIS know that it should use the CHENYX06a.gsb file as
grid-shift file? 

Where exactly does it find this information? 

Thank you for shedding some light on this mystery. 

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

Re: [Qgis-developer] Outline/border -> stroke?

[Neumann, Andreas]

Hi, 

+1 for renaming to "stroke". "stroke" is also used as the term in SVG /
PDF specifications - the two most important vector graphic standards. 

As a consequence, we would have related terms, such as "stroke-width",
"stroke-linecap", "stroke-dasharray", etc. See
https://www.w3.org/TR/2011/REC-SVG11-20110816/painting.html#StrokeProperties
 

Another candidate would be renaming everything "transparency" with
"opacity" - but I guess it would be more controversial ;-) And it would
mean that sliders would have to be reversed, as 100% opacity = 0%
transparency. 

Andreas 

On 2017-02-07 09:52, Nyall Dawson wrote:

> Hi all,
> 
> Following up on one of the points raised by John Hawkison (author of
> the famous "my first weekend with QGIS" email), I'd like to raise
> discussion about renaming all use of outline/border throughout QGIS to
> "stroke".
> 
> I've been thinking about this and I'm personally in favour.
> 
> Why?
> - the terms border, outline and pen are used inconsistently throughout
> QGIS. Eg a polygon fill has an outline, a simple line has a pen.
> - the API is even worse... these terms are thrown around with no
> logical pattern. Even within single classes we mix and match
> - stroke is a good replacement for all these terms. It's also commonly
> used by most design software instead of border or outline.
> 
> Any opinions here? Any objections if I made this change?
> 
> 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

  ___
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] Area calculation issues

[Neumann, Andreas]

Dear Nyall, 

Thank you so much for analyzing the issue and also thank you in advance
for porting the fix to 2.18! 

I opened the sample project with 2.14 and I can confirm that the area
values of both planimetric and ellipsoidic area calculations are very
close for all features. 

It is very much appreciated! 

Thanks, 

Andreas 

On 2017-02-03 01:36, Nyall Dawson wrote:

> On 1 February 2017 at 19:55, Neumann, Andreas <a.neum...@carto.net> wrote: 
> 
>> Hi Nyall,
>> 
>> Thanks for the explanations. I should have read the explanations of the help 
>> text more closely. It explains it all.
>> 
>> However, there still seem to be issues. Consider the following results 
>> below. First column is the result of $area, second column is area($geometry).
>> 
>> Sometimes the results are very close, in other cases the difference is 
>> massive. Like in the very first row. 32'087 vs 190'605'589 square meters. 
>> This can't be explained with ellipsoidical vs. planimetric. In this first 
>> row, the result of area($geometry) (planimetric) seems correct, while the 
>> ellipsoidical result ($area) is massively wrong.
>> 
>> How can this huge difference be explained?
> 
> Ok - I've looked into this. It's not an issue in 2.14 or 3.0, just 2.18.
> 
> It was most likely fixed by:
> https://github.com/qgis/QGIS/commit/abc0919 "Fix area calculation of
> compoundcurve rings if they contain a 2-vertex linestring"
> 
> Committed to 2.14 (with unit tests), I forward ported to 3.0, but it
> hasn't been applied to 2.18. I'll do this.
> 
> Nyall

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

Re: [Qgis-developer] Area calculation issues

[Neumann, Andreas]

Hi Nyall, 

Thanks for the explanations. I should have read the explanations of the
help text more closely. It explains it all. 

However, there still seem to be issues. Consider the following results
below. First column is the result of $area, second column is
area($geometry). 

Sometimes the results are very close, in other cases the difference is
massive. Like in the very first row. 32'087 vs 190'605'589 square
meters. This can't be explained with ellipsoidical vs. planimetric. In
this first row, the result of area($geometry) (planimetric) seems
correct, while the ellipsoidical result ($area) is massively wrong. 

How can this huge difference be explained? 

 

Regarding the second issue - yes, it makes sense that OTF has no
influence and that always the project CRS is used. 

Thanks! 

Andreas 

On 2017-02-01 10:30, Nyall Dawson wrote:

> On 1 February 2017 at 18:55, Neumann, Andreas <a.neum...@carto.net> wrote: 
> 
>> Hi,
>> 
>> Regarding field calculator:
>> 
>> I wonder what the difference between $area and area($geometry) is?
> 
> $area respects project settings like ellipsoid choice and area units.
> 
> area(geometry) is just a plain cartesian calculator.
> 
>> They deliver different results - sometimes quite close, but sometimes with a
>> hug difference.
> 
> The results will vary (sometimes by a huge amount) depending on the
> geometry's crs and ellipsoid choice. Eg area($geometry) for geometries
> in geographic coordinates in mostly meaningless, and the same for
> projections like web mercator.
> 
>> I have to add, that the data contains circular arcs.
> 
> Should not affect anything.
> 
>> Another user reported me that area calculation results are different
>> depending on OTF is on or off (I have to ask which QGIS version, he did not
>> tell).
> 
> Yes - switching off OTF will reset the ellipsoid to none. Switching it
> on resets the ellipsoid choice back to the ellipsoid matching the
> project CRS.
> 
> This was very confusing behaviour. The good news is that I changed
> this a week or so ago in qgis 3. Now OTF has no impact on area or
> length calculations, and that *only* depends on the project ellipsoid
> choice.
> 
> (There was talk at the time that we should totally remove the OTF off
> option. I'm in favour of this and will probably tackle it soon).
> 
> 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

[Qgis-developer] Area calculation issues

[Neumann, Andreas]

Hi, 

Regarding field calculator: 

I wonder what the difference between $area and area($geometry) is? 

They deliver different results - sometimes quite close, but sometimes
with a hug difference. 

I have to add, that the data contains circular arcs. 

Tested with 2.18.x. OTF off. 

Nyall - I remember that you dived into this issue in one of the past bug
fixing efforts? Can you explain it? I can deliver a small dataset
demonstrating the issue. 

--- 

Another user reported me that area calculation results are different
depending on OTF is on or off (I have to ask which QGIS version, he did
not tell). All data sets in the projects use a meter based system. The
data set of the assumedly wrong area calculations are in the same
coordinate system as the project. 

Thanks, 

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

Re: [Qgis-developer] QGIS Server - SSL handshake failed for cascading WMS

[Neumann, Andreas]

Hi Larry, 

Thank you for your reply! 

It is actually a chain with an intermediate CA. So maybe I just hit the
issue you also discovered? 

It is about this URL/certificate: https://services.geo.zg.ch/ 

Root CA: SwissSign Silver G2 Root CA
Intermediate CA: Swiss Sign Silver CA 2014 - G22
SSL Certificate: services.geo.zg.ch 

So I will try do have a look at the workaround or fall back to http only
- because I can control both servers. 

Thanks, 

Andreas 

On 2017-01-27 21:49, Larry Shaffer wrote:

> Hi Andreas, 
> 
> On Fri, Jan 27, 2017 at 8:48 AM, Neumann, Andreas <a.neum...@carto.net> wrote:
> 
>> Some more information on my server: 
>> 
>> Linux CentOS7 
>> 
>> qt 4.8.5 
>> 
>> The server only allows tls connections, no SSLv2/3 or such vulnerable stuff. 
>> Perhaps qt is too old to properly support tls ciphers? 
>> 
>> Can I add an SSL "do not check exception" for specific connections of QGIS 
>> server? 
>> 
>> If yes - how would I configure that for QGIS server?
> 
> Qt 4.8 can definitely use TLS, and can be configured (in a SSL Server 
> configuration) to connect to the WMS endpoint how you feel is appropriate, 
> including ignoring specific SSL errors. This assumes you are cascading by 
> configuring a QGIS project with a WMS layer and then, in turn, serving again 
> via WMS through QGIS Server. If so, you should be able to use the 
> authentication system to solve the connection issues. However, you will need 
> to have the authentication database available to QGIS Server as well, via env 
> variable, because the SSL Server configurations are stored in it. 
> 
> Recently (last week), I noticed a possible bug in the auth system whereby the 
> SSL endpoint connected to will throw an SSL error when the endpoint has 
> intermediate certificates that are not stored in QGIS's Authorities tab. 
> Usually, validation would not check for trust of intermediates, only whether 
> a given cert in the chain is valid for the particular use and the eventual 
> trustworthiness of its root Certificate Authority. Essentially, any 
> intermediates need to be trusted as roots CAs until this is fixed. 
> 
> In this case, for a workaround, you will need to either add the intermediate 
> certificates to OpenSSL's referenced trusted roots file/directory, or add 
> them to your Authorities tab in QGIS (which adds them to the authentication 
> database as trusted, by default) then ensure the auth database can be used by 
> QGIS Server for the project. 
> 
> I would need to know more about your particular SSL setup to give any further 
> suggestions here. Unfortunately, "SSL handshake failed" is a too vague, and I 
> am only guessing at the problem above. 
> 
> Regards, 
> 
> Larry Shaffer
> Dakota Cartography
> Black Hills, South Dakota 
> 
> Thanks for any hints, 
> 
> Andreas
> 
> On 2017-01-27 16:31, Neumann, Andreas wrote: 
> 
> Hi, 
> 
> I want to use a cascading WMS in QGIS server. I know it is not ideal, 
> perfomance wise, but it would be only for printing. 
> 
> Problem is that the WMS uses https and QGIS server can't connect. The QGIS 
> server log shows a connect error: 
> 
> Download of capabilities failed: SSL handshake failed 
> 
> curl or wget on the same server works fine with the same ssl connection. 
> 
> Anyone knows how I can overcome this SSL handshake issue? Do I need to set up 
> a separate certificat chain for QGIS server? I hope not ... 
> 
> Thanks for any hints, 
> 
> Andreas
> 
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer [1]
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer [1] 
> 
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer [1]
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer [1]

  

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

[Qgis-developer] QGIS Server WFS and CurvePolygon layers

[Neumann, Andreas]

Hi, 

In QGIS server (very recent 2x version) I noticed that for layers with
geometry type CurvePolygon (Postgis data source) that the geometry is
just omitted. 

Here is a very simple project with 2 features: 

https://services.geo.zg.ch/ows/Hydrologie/GWS?SERVICE=WFS=GetFeature=2.0.0=test_curve_polygon=EPSG:2056


Result: 

Features without a geometry, but a correct bounding box a the top of the
reponse. 

Anyone knows why the CurvePolygon is not supported? 

Thanks, 

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

[Qgis-developer] QGIS Server - SSL handshake failed for cascading WMS

[Neumann, Andreas]

Hi, 

I want to use a cascading WMS in QGIS server. I know it is not ideal,
perfomance wise, but it would be only for printing. 

Problem is that the WMS uses https and QGIS server can't connect. The
QGIS server log shows a connect error: 

Download of capabilities failed: SSL handshake failed 

curl or wget on the same server works fine with the same ssl connection.


Anyone knows how I can overcome this SSL handshake issue? Do I need to
set up a separate certificat chain for QGIS server? I hope not ... 

Thanks for any hints, 

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

Re: [Qgis-developer] Status of QGIS3

[Neumann, Andreas]

Hi Régis, 

No, we did not change our policy regarding earmarked sponsoring. 

However, looking at our expenses, bug fixing is the biggest item
(usually around 2/3 of the expenses). So you can easily claim that
someones sponsorship covers that ;-) In reality, of course, everything
goes into the pool. 

I also wrote "primarily" - that does not exclude that the money is also
used for other purposes. 

It was my argument to "sell" the sponsorship to our users. 

Andreas 

> Just a question, up to now, sponsoring could not be oriented and I see that 
> gold sponsor is dedicacted to bugfixing and QA. Did we change our policy? If 
> yes, that needs to be wide spread, we might gain some sponsors ! 
> 
> Régis  
> 
> 2017-01-27 9:27 GMT+01:00 Neumann, Andreas <a.neum...@carto.net>:
> 
> Hi Paolo, 
> 
> Here are the slides from our annual meeting: 
> https://docs.google.com/presentation/d/1d1ott7W5agb2vvUB8xSfv7x6gE843H-JLw4_OWqyTmc/edit?usp=sharing
>  [1] 
> 
> However, only a small nr of slides on QGIS 3 itself. 
> 
> Feel free to re-use, if you need something. 
> 
> Andreas 
> 
> On 2017-01-27 08:05, Paolo Cavallini wrote: 
> Il 27/01/2017 07:42, Nyall Dawson ha scritto: On 27 January 2017 at 16:30, 
> Neumann, Andreas <a.neum...@carto.net> wrote:
> 
> Obviously I missed a lot. I apologize. I was trying to be brief and
> concentrate on the very essential work necessary for QGIS 3. Every version
> obviously has plenty and numerous improvements, regardless if it is a major
> version change or not. Thanks a lot to all of the very active devs! 
> Just to clarify - I wasn't offended. I'm just very aware that there's
> a lot of "lurkers" on this list who could misinterpret your email and
> think that there's only been those changes so far. Next thing we know
> it's being shared on Twitter!

Thanks a lot Nyall, Andreas. This small incident IMHO highlights the
need for more communication to users, so our exercise may be useful.
Andreas, do you have slides to share?
Of course I'll also share mine.
All the best. 

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


  

Links:
--
[1]
https://docs.google.com/presentation/d/1d1ott7W5agb2vvUB8xSfv7x6gE843H-JLw4_OWqyTmc/edit?usp=sharing
[2] https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Status of QGIS3

[Neumann, Andreas]

Hi Paolo, 

Here are the slides from our annual meeting:
https://docs.google.com/presentation/d/1d1ott7W5agb2vvUB8xSfv7x6gE843H-JLw4_OWqyTmc/edit?usp=sharing


However, only a small nr of slides on QGIS 3 itself. 

Feel free to re-use, if you need something. 

Andreas 

On 2017-01-27 08:05, Paolo Cavallini wrote:

> Il 27/01/2017 07:42, Nyall Dawson ha scritto: On 27 January 2017 at 16:30, 
> Neumann, Andreas <a.neum...@carto.net> wrote:
> 
> Obviously I missed a lot. I apologize. I was trying to be brief and
> concentrate on the very essential work necessary for QGIS 3. Every version
> obviously has plenty and numerous improvements, regardless if it is a major
> version change or not. Thanks a lot to all of the very active devs! 
> Just to clarify - I wasn't offended. I'm just very aware that there's
> a lot of "lurkers" on this list who could misinterpret your email and
> think that there's only been those changes so far. Next thing we know
> it's being shared on Twitter!

Thanks a lot Nyall, Andreas. This small incident IMHO highlights the
need for more communication to users, so our exercise may be useful.
Andreas, do you have slides to share?
Of course I'll also share mine.
All the best. 

  ___
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] Status of QGIS3

[Neumann, Andreas]

Hi Nyall, 

On 2017-01-27 05:27, Nyall Dawson wrote:

> This is quite an incomplete list ;)
> 
> Check https://gist.github.com/nyalldawson/95738ec265c7f9bdb64b15672c210bb7
> for a better (albeit somewhat raw) list!
> 
> Nyall
> 
> What is already done:
> 
> Migration to qt5 and Python 3
> Python plugin update helper 2 to 3
> Inheritable flexible properties framework (QEP 22)
> Inbuilt task manager in QGIS for long running background tasks

Obviously I missed a lot. I apologize. I was trying to be brief and
concentrate on the very essential work necessary for QGIS 3. Every
version obviously has plenty and numerous improvements, regardless if it
is a major version change or not. Thanks a lot to all of the very active
devs! 

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

Re: [Qgis-developer] Symbolizing a discrete or a boolean raster

[Neumann, Andreas]

Hi Stéphane, 

Looks good! Go ahead and ask some devs for quotes. It may be that they
will have some feedback regarding your requirements. 

Regarding the crowd funding itself. Some devs already did successful
crowd funding campaigns and have some experience with it. You can ask
the devs about it and what their opinion is. It may make sense to ask
for a minimum amount of contribution. It doesn't make sense to collect
very small amounts (e.g. 10 EUR) as the administrative overhead may
become too much of a burden (or you have to pay a lot of fees to crowd
funding providers). If you still want to do small donations, you have to
factor in that a commercial crowd funding provider often keeps 5-10 % of
the contributions (in combination with credit card fees and currency
conversions). 

Thanks for taking the initiative! 

Andreas 

On 2017-01-16 04:17, Stéphane Henriod wrote:

> Hi all
> 
> I have seen that quite a few people had a look at this feature description 
> but only few commented or modified it. Can I assume that most agree with the 
> description as it is and would support / welcome such an implementation? 
> 
> If no major concern, I would love to ask a quote to a few devs by the end of 
> this week so that we can quickly evaluate the financial options. 
> 
> Thanks a lot in advance! 
> 
> Stéphane 
> 
> Le jeudi 12 janvier 2017, Stéphane Henriod  a écrit :
> Hi all 
> 
> upon advice from Andreas, I started a formal description of the requirements 
> for such a feature: 
> 
> https://docs.google.com/document/d/1cDemM2m88_mbs65sYzfBbVdHI_ObOjf_i35ne3OKsRs/edit?usp=sharing
>  [1] 
> 
> Please, anyone interested, do check, comment, add, correct,... Once we have a 
> "final" version, I will inquire a more precise financial estimation. Then 
> let's see how we can move forward! 
> 
> Thanks and cheers 
> 
> Stéphane 
> 
> Le jeudi 12 janvier 2017, Stéphane Henriod  a écrit :
> Hi Alexandre 
> 
> (also posting on user-) 
> 
> I 100% agree with you and I would love to somehow give back to QGIS (I did 
> already, but at a small scale). 
> 
> I mostly wanted to know if I am the only one to wish for this feature. 
> Apparently not the case: many have expressed the same wish! 
> 
> Now funding: I would love to have a rough idea what "not very expensive" 
> means. If there are any dev around who could have the interest / skills to 
> implement this feature, can we somehow go concrete and work together on a 
> feature description and tentative budget? The situation is obviously very 
> different if we talk about 1.000 or 20.000EUR 
> 
> Cheers 
> 
> Stéphane 
> 
> Le jeudi 12 janvier 2017, Alexandre Neto  a écrit :
> 
> Hello Stéphane, 
> 
> IMHO, since it seems that you are not able/willing to sponsor the feature 
> yourself, sounds like a good opportunity for a small crowdfunding. 
> 
> That way you would be able to contribute back to QGIS by giving your time in 
> finding a developer able to do it, setting up the crowdfunding, advertise it, 
> pay for part of it and so on. 
> 
> It looks like a simple feature. it should not be very expensive (much less 
> than an ArcGIS license for sure), and if you think many people need this, 
> then the money will be easy to raise. 
> 
> Alexandre Neto 
> 
> Stéphane Henriod  escreveu no dia quarta, 11/01/2017 
> às 11:37: One last message for today (sorry for spamming!) 
> 
> It seems that this feature would actually be wished by "many" people (see the 
> ticket and the talks on user-). I just gave a try to 2.99-nightly and, as far 
> as I can see, nothing has been done in this direction (yet?). 
> 
> I am wondering if there are massive challenges that I am overlooking or if 
> this could be implemented quite easily. In any case, do you think this is a 
> request that can be taken on to 3.0? 
> 
> Thanks a lot to all the devs here... I feel quite bad for asking for a new 
> feature while not having the competences to contribute a tiny bit to its 
> development but I really feel this is one of the few major missing features 
> in QGIS right now (and will be happy to help on the feature requirements, the 
> tests, etc.). 
> 
> All the best! 
> 
> Stéphane 
> 
> Le mercredi 11 janvier 2017, Stéphane Henriod  a écrit 
> :
> Hi again 
> 
> it seems that the requirements are related (although not 100% similar) to 
> this other open (and assigned) ticket: http://hub.qgis.org/issues/14449 [2] 
> 
> I really hope to see this very needed feature in a coming version of QGIS and 
> happy to help wherever I can! 
> 
> Cheers 
> 
> Stéphane 
> 
> Le mardi 10 janvier 2017, Stéphane Henriod  a écrit :
> Hi 
> 
> let me move here a request that has been shortly discussed on the 
> user-mailing list: 
> 
> http://lists.osgeo.org/pipermail/qgis-user/2017-January/038793.html [3] 
> http://lists.osgeo.org/pipermail/qgis-user/2017-January/038795.html [4] 
> 

[Qgis-developer] New mailing list for QGIS Web Client 2 (QWC2)

[Neumann, Andreas]

Hi all, 

QGIS Web Client 2 (QWC2) is the second generation QGIS web client and is
now in late alpha/early beta stage. This second version uses modern
libraries (OpenLayers3, React, nodejs) and is fully responsive. You can
use the same version for traditional desktop web clients and touch
devices (phones/tablets). The initial version was developed from
Sourcepole, but now is open to everyone for contributions. QWC2 is based
on the Mapstore2 project from GeoSolutions. 

There is a new mailing list about QWC2 at
https://lists.osgeo.org/mailman/listinfo/qgis-qwc2, where you can: 

- get help for initial setup 

- discuss issues and further development of QWC2 

You can find the QWC2 repo at https://github.com/qgis/qwc2-demo-app with
instructions about installation. Feel free to come up with pull requests
about further installation hints, should you find some improvements. 

If you have bug and feature requests, please create a new issue at
https://github.com/qgis/qwc2-demo-app/issues  

The reason why we split this mailing list from the regular QGIS-user
mailing list, is that discussions will at time be quite technical and
web-centric, with server setup, Apache, javascript, etc. - not the usual
stuff of the QGIS Desktop mailing list. 

With tomorrows website update, the list info should also appear at
http://www.qgis.org/en/site/getinvolved/mailinglists.html#qgis-mailinglists
 

Greetings, 

Andreas 

  ___
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] CI testing: the straight truth

[Neumann, Andreas]

Hi Matthias, 

Thanks a lot for dealing with this! 

Andreas 

On 2017-01-11 11:37, Matthias Kuhn wrote:

> Hi,
> 
> I have just received the confirmation from travis that they boosted our
> build times to 90 minutes.
> I think that should keep us alive for the foreseeable future.
> 
> Please let me use this opportunity to highlight the excellent support
> from their side!
> 
> Matthias
> 
> On 04/01/17 10:31, Matthias Kuhn wrote: Hi Andreas, Nyall
> 
> I would also prefer this, I just sent them a mail and will get back to
> you as soon as I get a response.
> 
> Mid-term we will still need to launch a project to update the system and
> get away from the pre-built dependencies in osgeo4travis to a system
> that is easier to maintain collectively but I'm happy if we can wait
> with this a bit.
> 
> @Tom Chadwin:
> agreed, that's a risk indeed
> 
> Best regards
> Matthias
> 
> On 01/04/2017 08:21 AM, Neumann, Andreas wrote: Hi all,
> 
> I agree with Nyall. We should try contracting the travis ci team and ask
> them if we could switch to unlimited build time. Even if this means
> paying a certain amount for the services (if it is a reasonable price).
> 
> Matthias - could you please take a lead in contacting them?
> 
> Thanks,
> Andreas
> 
> On 2017-01-03 23:40, Nyall Dawson wrote:
> 
> On 4 January 2017 at 07:59, Matthias Kuhn <matth...@opengis.ch
> <mailto:matth...@opengis.ch>> wrote: Hi René-Luc, hi all,
> 
> This is something I have been afraid of for a couple of weeks.
> 
> Short story: our builds just grew too big and a full build is taking
> more than 50 minutes to complete on the travis infrastructure. Argh... what a 
> pain! Still, I think in some ways this is a good
> reflection of the exponential growth in QGIS unit tests since your
> initial work introducing the CI infrastructure. I certainly would
> never want to go back to the pre-CI days!
> 
> Just wondering- is there any chance sending an email to the Travis
> crew could get an extension to this build time? I can't see anything
> on their publicised plans, but perhaps they have a cheaper unlimited
> build time option available for open source projects?
> 
> I'd like to see us exhaust these "easier" options first before
> requiring someone to donate time into tweaking/changing the CI
> infrastructure.
> 
> Nyall
> 
> What
> keeps us alive at the moment is the persistent ccache so a full build
> actually never happens. If the ccache gets lost, we will need some black
> magic to get the builds started again (it's possible to slowly get the
> cache warm but not straightforward).
> 
> What we could possibly do:
> 
> - Modularize the build: e.g. astyle could very well be moved to a
> separate job along with other static checks like spelling. That would
> even have the advantage of a faster feedback for these analyses.
> But I'm not sure how much time we can actually get out of that.
> 
> - Move dependencies into separate packages. We have some deps like
> qspatialite that are built as part of QGIS which I think could be
> installed as dependencies from a .deb. This will require quite a bit
> of work: moving travis out of the container based infrastructure to
> the sudo-enabled infrastructure, setting up a repo (e.g. ppa) with
> all sort of dependencies including qt 5 etc. This would be an option
> again since travis enabled caching also on sudo systems recently.
> This will be a quite large task to do.
> 
> - Move to another system (managed infrastructure or self-hosted, there
> are a couple of services like circle ci, drone.io, jenkins, gitlab
> ci ...).
> This will be a quite large task to do with the risk that we run into
> yet another timeout, other technical issue or run a self-hosted
> infrastructure for which nobody really has the resources to maintain.
> 
> Apart from this, there is also the dependency on some pre-compiled
> libraries in the osgeo4a repository. Keeping these up to date is not
> something we will want in the long term (I was hoping that travis would
> ship a more recent distro than trusty but haven't seen many hints in
> this direction yet).
> 
> Bottomline: I don't think there's an easy fix but I think it's time to
> start thinking about the future.
> 
> Matthias
> 
> On 01/02/2017 03:03 PM, René-Luc Dhont wrote: Hi Devs,
> 
> I would like to merge a PR https://github.com/qgis/QGIS/pull/3897 but
> Travis cannot ccomplete the tests.
> 
> Would it be simple to fix travis ?
> 
> Regards,
> René-Luc
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org <mailto:Qgis-developer@lists.osgeo.org>
> L

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

[Neumann, Andreas]

Hi, 

Jürgen is the release manager and ultimately proposes/decides when to
release 3.0. So I don't know what his opinion is. 

My personal opinion is in line with Nyall. Core devs should have enough
time to properly prepare everything and do at least the API
changes/redesign/refactoring properly. After 3.0 there won't be API
breaks for a longer time, so it is better to have enough time to do
things properly. 

A double dev cycle, followed by a double test cycle (testing and bug
fixing) would be useful. If we stick with the four month release cycle
with a double dev cycle this could mean a feature freeze somewhere
around May and a release after a two month test/bug fixing period
somewhere around July. Just a very rough idea, and not discussed with
the core devs and Jürgen ... 

Thoughts? 

Andreas 

On 2017-01-05 23:57, Nyall Dawson wrote:

> On 6 January 2017 at 03:43, Tom Chadwin  wrote: 
> 
>> Hello all
>> 
>> Amazing work going on for QGIS3 - I'm in awe of you all (as always).
>> 
>> I've been getting more and more nervous about how easy it will be to convert
>> my plugin, so yesterday I started to have a go. With lots of help from
>> Matthias (huge thanks, as ever!), I got a good way through the process. I
>> think I can now do it. I certainly don't feel so nervous.
>> 
>> However, Nyall pointed out that there is still a lot of change to come to
>> the API. I'm happy to abandon the work I've done so far, as it has achieved
>> its aim of getting me familiar with what the job will entail.
>> 
>> So, my question is, when would be the best time to start the actual
>> conversion of our plugins? Is there going to be an obvious time in QGIS3
>> development for this to happen? Can it be announced on the list?
> 
> I'd say just before/after feature freeze. There's still some very
> large API changes in store, eg Martin's current refactoring of the
> project and map layers will likely have large impact on your plugin,
> and I'd hate to see you have to "port twice". By the time feature
> freeze comes into play the large API changes will all have been locked
> in (or have to wait till 4.0!).
> 
> There's no time frame for this yet, but I'll fight hard against any
> plans for a release before mid-year.
> 
> Nyall
> 
>> Thanks
>> 
>> Tom
>> 
>> -
>> Buy Pie Spy: Adventures in British pastry 2010-11 on Amazon
>> --
>> View this message in context: 
>> http://osgeo-org.1560.x6.nabble.com/When-to-start-converting-our-plugins-tp5302167.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

  ___
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] Will Processing in QGIS 3 support parallelization?

[Neumann, Andreas]

Hi Nyall, 

Interesting. 

Your "thinking aloud" - is this something that would have to wait for
QGIS 4x or could this be interested in 3.x already? Just wondering ... 

>From a user point of view it would be very interesting to have
processing within a layer in update mode without having to create
separate new layers. Also, of course, the parallelization option (for
certain algorithms where feasible). 

Andreas 

On 2017-01-06 00:11, Nyall Dawson wrote:

> On 3 January 2017 at 18:19, Anita Graser  wrote: 
> 
>> Hi,
>> 
>> I'm currently writing a script that could benefit a lot from
>> parallelization. Will Processing in QGIS 3 provide parallelization support?
>> Or is it better to look into how to achieve parallelization independent of
>> Processing, e.g. using Python's multiprocessing library?
> 
> Depends what you're after. When processing is ported to the new task
> manager framework then algorithms will be able to run in parallel
> (where possible). Eg a buffer for one layer can run while a transform
> occurs on another layer.
> 
> If you're after parallelization *within* a single algorithm (Eg
> buffering features using multiple threads) then I'm unaware of any
> plans in place to handle this.
> 
> * That said read on for some thinking aloud
> 
> I think when we port the guts of processing over to c++ then this will
> become relatively straightforward. I'd see this happening:
> - algorithms which operate feature-by-feature inherit a special
> algorithm subclass (say "QgsFeatureBasedAlgorithm" or something) and
> override some base class "QgsFeature processFeature( QgsFeature )"
> method. Eg a buffer alg will implement this to buffer the passed
> feature's geometry and return a new modified feature.
> - QgsFeatureBasedAlgorithm could take advantage of something like
> QtConcurrent::mappedReduced to call processFeature on multiple threads
> and use the result function to write out the results for each
> processFeature call. Nice and (theoretically) easy way to gain
> multithreaded algorithms, and it would be simple to adapt many
> existing algorithms to this (buffer, centroid, transform, translate,
>  Basically anything which operates on each feature in isolation).
> 
> The side benefit of this refactoring would allow something I've wanted
> for a while - a way for processing algorithms to modify a selection
> inside a layer "in place". Eg select a bunch of polygons, run the
> buffer alg on the selection (not sure of the best UI to expose this!)
> and each selected feature will be buffered. Currently there's no easy
> way to do this in QGIS - you've got to run the alg on a selection and
> get a new layer, then delete the selection, and finally copy features
> back from the new output layer to the source layer. Yuck.
> 
> Nyall
> 
>> Thank you and 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
> ___
> 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

Re: [Qgis-developer] CI testing: the straight truth

[Neumann, Andreas]

Hi all, 

I agree with Nyall. We should try contracting the travis ci team and ask
them if we could switch to unlimited build time. Even if this means
paying a certain amount for the services (if it is a reasonable price). 

Matthias - could you please take a lead in contacting them? 

Thanks,
Andreas 

On 2017-01-03 23:40, Nyall Dawson wrote:

> On 4 January 2017 at 07:59, Matthias Kuhn  wrote: 
> 
>> Hi René-Luc, hi all,
>> 
>> This is something I have been afraid of for a couple of weeks.
>> 
>> Short story: our builds just grew too big and a full build is taking
>> more than 50 minutes to complete on the travis infrastructure.
> 
> Argh... what a pain! Still, I think in some ways this is a good
> reflection of the exponential growth in QGIS unit tests since your
> initial work introducing the CI infrastructure. I certainly would
> never want to go back to the pre-CI days!
> 
> Just wondering- is there any chance sending an email to the Travis
> crew could get an extension to this build time? I can't see anything
> on their publicised plans, but perhaps they have a cheaper unlimited
> build time option available for open source projects?
> 
> I'd like to see us exhaust these "easier" options first before
> requiring someone to donate time into tweaking/changing the CI
> infrastructure.
> 
> Nyall
> 
> What
> keeps us alive at the moment is the persistent ccache so a full build
> actually never happens. If the ccache gets lost, we will need some black
> magic to get the builds started again (it's possible to slowly get the
> cache warm but not straightforward).
> 
> What we could possibly do:
> 
> - Modularize the build: e.g. astyle could very well be moved to a
> separate job along with other static checks like spelling. That would
> even have the advantage of a faster feedback for these analyses.
> But I'm not sure how much time we can actually get out of that.
> 
> - Move dependencies into separate packages. We have some deps like
> qspatialite that are built as part of QGIS which I think could be
> installed as dependencies from a .deb. This will require quite a bit
> of work: moving travis out of the container based infrastructure to
> the sudo-enabled infrastructure, setting up a repo (e.g. ppa) with
> all sort of dependencies including qt 5 etc. This would be an option
> again since travis enabled caching also on sudo systems recently.
> This will be a quite large task to do.
> 
> - Move to another system (managed infrastructure or self-hosted, there
> are a couple of services like circle ci, drone.io, jenkins, gitlab
> ci ...).
> This will be a quite large task to do with the risk that we run into
> yet another timeout, other technical issue or run a self-hosted
> infrastructure for which nobody really has the resources to maintain.
> 
> Apart from this, there is also the dependency on some pre-compiled
> libraries in the osgeo4a repository. Keeping these up to date is not
> something we will want in the long term (I was hoping that travis would
> ship a more recent distro than trusty but haven't seen many hints in
> this direction yet).
> 
> Bottomline: I don't think there's an easy fix but I think it's time to
> start thinking about the future.
> 
> Matthias
> 
> On 01/02/2017 03:03 PM, René-Luc Dhont wrote: Hi Devs,
> 
> I would like to merge a PR https://github.com/qgis/QGIS/pull/3897 but
> Travis cannot ccomplete the tests.
> 
> Would it be simple to fix travis ?
> 
> Regards,
> René-Luc
> ___
> 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
 ___
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

Re: [Qgis-developer] $id not working as default value

[Neumann, Andreas]

Hi Nyall, 

Thanks for clarifying. 

This needs to be properly documented and taught in QGIS courses. 

Andreas 

On 2016-12-27 02:03, Nyall Dawson wrote:

> On 23 December 2016 at 23:37, Paolo Cavallini  wrote: 
> Il 23/12/2016 14:32, Giovanni Manghi ha scritto:
> 
> The solution from the Gitter discussion
> 
> aggregate( 'layername','max',"id")+1 
> thanks Giovanni
> 
> We need of course a more user friendly way to allow users have
> incremental/serial ids in their shapefiles... 
> sure, e.g. a named preset expression, as previously suggested.
> all the best.

In master you can add UNIQUE and NOT NULL constraints to the field
from within QGIS. This will cause QGIS to automatically populate it
with a serial type value whenever a new feature is created.

Nyall

> --
> Paolo Cavallini - www.faunalia.eu [1]
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
> ___
> 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 

  

Links:
--
[1] http://www.faunalia.eu
___
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] Drag & Drop fails on Geopackage

[Neumann, Andreas]

Hi, 

I wasn't aware either that one can drag and drop from browser to DB
manager. It is certainly not obvious. 

In the case of Geopackage, which is a container for many tables - how
should drag and drop behave? Should it open a dialogue that lets the
user choose which tables he wants to copy? 

I think this needs to be better specified. 

Andreas 

On 2016-12-21 21:32, Even Rouault wrote:

> On mercredi 21 décembre 2016 20:50:45 CET Paolo Cavallini wrote: 
> 
>> Il 21/12/2016 19:35, Even Rouault ha scritto: 
> 
 Errore 3 
> 
 
> 
 non riesco a creare il layer (errore OGR:Failed to open Shapefile 
> 
 
> 
 `dbname='/home/paolo/test.gpkg' key='id' table="province" (geom) 
> 
>>> 
> 
>>> sql=.shp'. 
> 
>>> 
> 
 ) 
> 
>>> 
> 
>>> More details would be appreciated: drag from which part of the UI 
> 
>>> to which part of the UI ? (I'm not sure I'm aware of all drag 
> 
>>> capabilities that exist) I've tried to drop a geopackage from the 
> 
>>> browser, DBManager and the file explorer of my desktop to QGIS canvas 
> 
>>> (with master and 2.18.2) and that works fine for me. 
> 
>> 
> 
>> Merci Even for your response. I'm D'ing from browser panel to DB Manager. 
> 
> OK, didn't know that possibility indeed. Doesn't work for me either (but I 
> don't get any error message). That doesn't work with spatialite either. 
> 
> -- 
> 
> Spatialys - Geospatial professional services 
> 
> http://www.spatialys.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

Re: [Qgis-developer] Drag & Drop fails on Geopackage

[Neumann, Andreas]

Hi Giovanni, 

So the drag and drop issue seems unrelated to Geopackage - right? 

About geopackage: if you can come up with a comprehensive list with
Geopackage problems I would be willing to find finances to fix these
issues. I would ask Even Rouault to have a look at these issues. 

I personally have a strong, very strong urge to have a good alternative
to these stupid, ugly shapefiles. We really need to make sure that
Geopackage works well in QGIS/GDAL and FOSSGIS in general. Only then we
can seriously suggest geopackage as a Shapefile replacement. 

BTW: I also think that regressions in a LT bug fix release are really
undesired. We received quite a lot of funding recently to QGIS.ORG and I
think we should spend some of these on fixing the LT regression issues. 

Andreas 

On 2016-12-21 15:01, Giovanni Manghi wrote:

>> Hi all,
>> with a simple D I'm consistently getting this:
>> 
>> Errore 3
>> non riesco a creare il layer (errore OGR:Failed to open Shapefile
>> `dbname='/home/paolo/test.gpkg' key='id' table="province" (geom) sql=.shp'.
>> )
>> 
>> 2.18.0
> 
> there is a long list of issues about gpkg support in both DB manager
> (very basic support) and qgis browser (no support).
> 
> moreover there is some regression in general about d
> 
> https://hub.qgis.org/issues/15936
> 
> -- G --
> ___
> 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

Re: [Qgis-developer] should core plugins not be available in plugin manager?

[Neumann, Andreas]

Hi, 

Before we remove the ability to have C++ plugins, or the ability to
enable/disable them, we should first inform our users and developers and
ask them if we are fine with what we propose. 

There may be usages of QGIS out there that rely on the ability to have
C++ plugins that we are not aware of. 

--- 

I do agree though that some core plugins could be removed or integrated
into the core. One example is the coordinate capture plugin, which could
be easily integrated in core, e.g. integrated in the identify tool or
status bar. 

Probably the EVIS plugin is another candidate with lots of overlaps. If
we add the missing functionality the EVIS plugin provides to core, we
could get rid of it. 

Andreas 

On 2016-12-12 20:57, DelazJ wrote:

> Hi, I do not fully share the agreement on having core plugins not 
> deactivable. Are Core plugins the problem or is it Processing? Let's not 
> wrongly mix issues.
> 
> I'd always thought that Core plugins meant plugins developed, managed, 
> updated by the QGIS project itself, provided by default with installation. It 
> doesn't mean that everybody wants to use it or needs it. The Road Graph is a 
> plugin I had never executed in 5 years I'm using QGIS. Many others (GPS 
> Tools, Heatmap, rasters related plugins...) are concerned. Why would I want 
> it activated by default and crowd the GUI? Then I'd have to struggle and 
> change some somehow hidden customization option to have it disabled? Uncheck 
> it in Plugin Manager sounds far simpler.
> 
> What puzzled many users (and might still do) with Processing in QGIS >=2.16 
> is to have removed fTools and not activate Processing by default for those 
> that were using fTools. They should be provided a transparent replacement of 
> fTools (including the removal of this one from the list). 
> And maybe communication about this change is not clear for all people. 
> Currently, fTools state is broken but there's no message to tell you that you 
> should instead activate Processing to get back your lovely functions.
> 
> So, from me, no, Core plugins should stay (de)activable even though looking 
> at all the list of Core plugins being integrated in Processing in 3.0 I 
> wonder how many Core plugins will stay (DB Manager and Processing?) when 3.0 
> lands. :)
> 
> Also, one of the power of QGIS imho is its modularity: you pick what you 
> need. We should not put all in one. And having Core plugins being listed 
> there gives some kind of confidence to contributors to follow the path 
> (create plugins). I'm not sure i well expressed what I meant to.
> 
> Regards, Harrissou
> 
> 2016-12-12 16:01 GMT+01:00 Martin Dobias :
> 
>> Hi Victor
>> 
>> On Mon, Dec 12, 2016 at 7:05 PM, Victor Olaya  wrote:
>>> Hi
>>> 
>>> This has been discussed in the past, but i think no decision was
>>> taken, so I want to bring back the discussion.
>>> 
>>> I think that core plugins should not be visible in the plugin manager,
>>> and users should not be able to disable them. If they are core, they
>>> should be active (the menus and buttons can be removed with the
>>> "View/Customization..." functionality if the user wants to)
>> 
>> Agreed that Processing should be always on. Also, IMO it should be
>> available as "qgis.processing" python module.
>> 
>> Cheers
>> Martin
>> 
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer [1]
>> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer [1]
> 
> ___
> 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

  

Links:
--
[1] 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

Re: [Qgis-developer] Status of Q3 migration?

[Neumann, Andreas]

Hi, 

I would also prefer a double dev cycle, followed by a double test
period. So just shift the one month from the first dev cycle towards the
end. 

In Bonn we discussed this and I think the double dev cycle was an
option, but we said we would decide in December/January when we know
more about the state of the 3.0. 

I had a look at the past couple meeting minutes and apparently there
haven't been any decisions in the minutes about the release date of QGIS
3.0. 

Ultimately it is Jürgen who decides as the release manager. 

Greetings, 

Andreas 

On 2016-12-06 00:02, Nyall Dawson wrote:

> On 3 December 2016 at 19:51, Paolo Cavallini  wrote: 
> 
>> Hi all,
>> I'm regularly compiling QGIS master, and I'm surprised how usable and
>> smooth it is - obviously not suitable for production, but apparently not
>> so far from it. It would be great if those more involved with the
>> migration could give us a quick overview:
>> * are there blocking factors?
>> * which are the main areas which require much work?
>> * are the deadlines proposed originally feasible
>> * how can we speed up the migration?
> 
> Hmm I've brought up previously on the list my thoughts that we
> should *extend* the timeline to mid next year, as opposed to speeding
> it up.
> 
> See https://lists.osgeo.org/pipermail/qgis-developer/2016-October/045554.html
> 
> I'm still strongly of the view that extending the timeline is a good
> idea and will give us a much better 3.x series.
> 
> Nyall
> 
>> Thanks a lot.
>> --
>> Paolo Cavallini - www.faunalia.eu [1]
>> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
>> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
>> ___
>> 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

  

Links:
--
[1] http://www.faunalia.eu
___
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] Field mapper when pasting features

[Neumann, Andreas]

exactly. There are more situations where attributes need to be
harmonized between two different schemas. 

It would be great if something generic could be developed that can be
re-used in other situations. 

With that in mind - perhaps a QEP makes sense. 

Andreas 

On 2016-10-28 12:54, Richard Duivenvoorde wrote:

> Yep, both good ideas :-)
> 
> One thing I think of: a 'mapper'-dialog could maybe also be used in the
> some algorithms like an 'union between 2 layers' and other algorithms
> which handle 2 or more feature types etc etc
> 
> Regards,
> 
> Richard Duivenvoorde
> 
> On 28-10-16 10:54, Neumann, Andreas wrote: Hi Arnaud,
> 
> This sounds like a very useful feature to have. A big +1!
> 
> Not sure if it requires a QEP - but it never hurts to do one. Perhaps
> other people have more idea, once they see a description or mockup.
> 
> Thanks in advance!
> 
> Andreas
> 
> On 2016-10-27 17:52, Arnaud Morvan wrote:
> 
> Hello QGIS devs,
> 
> I want to add a field mapper dialog when pasting features to layers.
> 
> For now when pasting features with attributes names that do not exists
> on the destination layer,
> those attributes values are lost.
> 
> When clipboard fields and destination layer fields are not strictly
> the sames,
> In QGIS 3.0, I want to popup a new dialog with fields mapper configurator.
> 
> Dialog UI could be similar to Refactor Fields Algorithm, showing a
> list of destination fields :
> 
> source expression (expression widgets) => destination field
> 
> For example, I often use this workflow :
> Open a shapefile or autocad file.
> Use the refactor fields to get temporary layer with same fields as
> destination.
> Paste to postgis database layer.
> 
> I think having this dialog showing up when needed could really ease
> data manipulation from one layer to another.
> And I want to give the possibility to use expressions.
> 
> Any remarks, do you think I need to open to open a QEP for that ?
> 
> Regards 
> 
> ___
> 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 

  ___
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: removing support for GRASS6?

[Neumann, Andreas]

Hi Victor, 

Good. 

The QGIS raster calculator should get some love. It is quite confusing
to many of our users in its current state, and also a bit limited. 

It would be nice, if an improved raster calculator could use the power
of the QGIS expressions. 

Perhaps, this would be a good candidate for another round of a QGIS
grants project. 

Andreas 

On 2016-10-28 11:41, Victor Olaya wrote:

> I want to add a calculator in processing that is based on QGIS
> classes, so is a native one, like the current raster calculator, but
> in processing. I hope that allows us to get rid of all the others,
> since it is very confusing and error prone. A good calculator that can
> do everything should be able to replace the collection of them we have
> now
> 
> 2016-10-26 18:59 GMT+02:00 Giovanni Manghi : +1 
> from me
> 
> 2016-10-26 16:24 GMT+02:00 Paolo Cavallini : Hi all,
> I think removing support for GRASS6 makes sense at least for QGIS 3.
> This will reduce confusion among users, and will remove some bugs.
> Anything against it?

please don't unless the GRASS7 r.mapcalc is fixed in Processing,
with GRASS 6 at least we can rely on r.mapcalculator, not available in
GRASS 7.

cheers!

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

  ___
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] Field mapper when pasting features

[Neumann, Andreas]

Hi Arnaud, 

This sounds like a very useful feature to have. A big +1! 

Not sure if it requires a QEP - but it never hurts to do one. Perhaps
other people have more idea, once they see a description or mockup. 

Thanks in advance! 

Andreas 

On 2016-10-27 17:52, Arnaud Morvan wrote:

> Hello QGIS devs,
> 
> I want to add a field mapper dialog when pasting features to layers.
> 
> For now when pasting features with attributes names that do not exists on the 
> destination layer,
> those attributes values are lost.
> 
> When clipboard fields and destination layer fields are not strictly the sames,
> In QGIS 3.0, I want to popup a new dialog with fields mapper configurator.
> 
> Dialog UI could be similar to Refactor Fields Algorithm, showing a list of 
> destination fields :
> 
> source expression (expression widgets) => destination field
> 
> For example, I often use this workflow :
> Open a shapefile or autocad file.
> Use the refactor fields to get temporary layer with same fields as 
> destination.
> Paste to postgis database layer.
> 
> I think having this dialog showing up when needed could really ease data 
> manipulation from one layer to another.
> And I want to give the possibility to use expressions.
> 
> Any remarks, do you think I need to open to open a QEP for that ?
> 
> Regards

  ___
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] Is the next LTR release 2.x or 3.x?

[Neumann, Andreas]

Hi Andrew, 

see also
https://www.qgis.org/en/site/getinvolved/development/roadmap.html#release-schedule


you can see that while 2.18x is not officially an LT version, there are
a number of updates planned for 2.18x - so it's almost like an LT
version ... 

The next 2.18 release will, besides bug fixes, also contain some very
useful Geopackage updates, and some upcoming 2.18x will also receive CAD
reading support (DXF/DWG). Jürgen knows when ;-) 

For 3.x. there are no release dates yet. Probably somewhere around
summer 2017 - but no-one knows yet. 

Andreas 

On 2016-10-28 08:53, Jürgen E. Fischer wrote:

> Hi Andrew,
> 
> On Thu, 27. Oct 2016 at 14:42:38 -0700, Andrew wrote: 
> 
>> I'm trying to get a plan together for how we are going to navigate the QGIS
>> 3 change.  I had thought that the next LTR was going to be a 3.x version
>> but I was wondering if that has changed with the 2.18 release and the
>> possibly extended timeline for QGIS 3.0.
> 
> The next LTR will be a 3.x.
> 2.14.x will be maintained until that is released.
> 
> Jürgen 
> ___
> 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

[Qgis-developer] Issue with vector menu and localization

[Neumann, Andreas]

Hi, 

There is a localization issue with the vector menu in QGIS 2.18x 

When I have english as my GUI language I have one vector menu (nice),
but when I switch to german I end up with two vector menus: "Vektor"
(contains plugins) and "Vector" (contains all the Processing stuff
(former fTools)). 

Probably the same in other languages when "Vector" is translated to
something else ... 

Is there something we can do about this situation? 

Thanks,
Andreas

  ___
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] Extending timeline for 3.0?

[Neumann, Andreas]

Hi, 

It would be fine for me to have a double dev cycle for 3.0. Devs should
have enough time to make proper decisions and work on the API. And
python devs probably also need more time to get their most important
plugins in shape for the new API, qt5 and Python 3. 

Perhaps it would be good to also have more than one month for testing
and bug fixing - extending this to two months. We could simply shift the
one month bug fixing/testing of the first cycle towards the end of the
second cycle. 

So this modified proposal would mean: 

Feature freeze at the end of May, release at the end of July. Right? 

Fine with me, if we still care about the 2.x branch where necessary -
preferably investing more in 2.18x than in 2.14x (my personal opinion). 

Andreas 

On 2016-10-26 07:53, Nyall Dawson wrote:

> Hi all,
> 
> I'd like to start the discussion around this early so that we can plan
> ahead and not have to make a last-minute decision.
> 
> What are everyone's thoughts on extending the timeline for 3.0? In my
> opinion things are currently going really well, we have Qt5/python3
> builds which are stable enough for daily use and there's been a ton of
> cleanups to the code.
> 
> There's a lot of changes still coming in, and I think there's SO much
> room for making things better that I don't like the idea of the early
> 2017 deadline for the final release. I'd much rather extend this out
> by another cycle and really getting the platform ready for the next
> series of QGIS releases.
> 
> We could always put out a "preview" release in March, without frozen
> API, if desired.
> 
> So, what's everyone's thoughts? Good idea? Bad idea?
> 
> Nyall
> ___
> 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

Re: [Qgis-developer] WIP: QGIS Server refactoring

[Neumann, Andreas]

ok good - just wanted you to be aware of these upcoming changes. Not
that you will be surprised. 

Have a nice weekend! 

Andreas 

On 2016-10-21 18:10, David Marteau wrote:

> Hi Andreas, 
> 
> We know that it will be premature to write code that dépends on the qgis core 
> api and that we have to wait that things stabilize on this side and that no 
> refactoring of the services can occurs without the refactoring of Martin.  
> 
> The part of the code we wand to start is the support machinery for dynamic 
> loading and registering of services and eventually the supports for the 
> plugins. 
> For this part, we do need to rely on anything from the qgis core 
> functionalities and thus  Martin Dobias's refactoring can go at its own pace. 
> 
> David 
> 
> Le 21 oct. 2016 à 17:54, Neumann, Andreas <a.neum...@carto.net> a écrit : 
> 
> Hi René-Luc, 
> 
> hm - I am not sure if this is good timing. 
> 
> Martin Dobias will refactor the layer tree extensively to allow a better QGIS 
> server code design. It is his proposal he submitted for the QGIS grants. The 
> swiss QGIS user group, potentially together with the german QGIS user group 
> will pay for his work, because it didn't make the grant in the voting, but we 
> still thought it is important work to be done. 
> 
> I guess it would make sense to wait until his work will be finished and then 
> start the QGIS server refactoring. However, it would be good to collaborate 
> with Martin to make sure his refactoring is useful for the QGIS server 
> refactoring. 
> 
> Greetings, 
> 
> Andreas 
> 
> On 2016-10-21 17:40, René-Luc Dhont wrote: 
> Hi devs,
> 
> We (David Marteau and I) will start the QGIS Server refactoring.
> 
> The first step for us is to develop the *service register* like described in 
> the QEP: QGIS server code refactoring for QGIS 3.0 
> https://github.com/qgis/QGIS-Enhancement-Proposals/issues/74
> 
> To keep the developement open, we proposed to use a github repository to 
> centralize *Pull Request* and development strictly on QGIS Server with a 
> dedicated branch https://github.com/3liz/QGIS/tree/master_qgis_server
> We proposed to do so to have the possibility to broke the code but we will 
> continue to merge master in it during the dev.
> We will open the right to other QGIS Server developers and be proud to review 
> Pull Request.
> 
> Our goal is to keep the functionalities, simplify the code and add 
> modularity; to have something more maintainable, robust and expendable.
> 
> Regards,
> René-Luc D'Hont
> 3Liz
> 
> ___
> 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

  ___
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] WIP: QGIS Server refactoring

[Neumann, Andreas]

I am refering to Martin Dobias proposal nr 14 in
https://qgisblog.files.wordpress.com/2016/09/qgisgrantapplicationssummary-september2016.pdf


titled "Project / Map layer registry refactoring" 

Andreas 

On 2016-10-21 17:54, Neumann, Andreas wrote:

> Hi René-Luc, 
> 
> hm - I am not sure if this is good timing. 
> 
> Martin Dobias will refactor the layer tree extensively to allow a better QGIS 
> server code design. It is his proposal he submitted for the QGIS grants. The 
> swiss QGIS user group, potentially together with the german QGIS user group 
> will pay for his work, because it didn't make the grant in the voting, but we 
> still thought it is important work to be done. 
> 
> I guess it would make sense to wait until his work will be finished and then 
> start the QGIS server refactoring. However, it would be good to collaborate 
> with Martin to make sure his refactoring is useful for the QGIS server 
> refactoring. 
> 
> Greetings, 
> 
> Andreas 
> 
> On 2016-10-21 17:40, René-Luc Dhont wrote:
> 
>> Hi devs,
>> 
>> We (David Marteau and I) will start the QGIS Server refactoring.
>> 
>> The first step for us is to develop the *service register* like described in 
>> the QEP: QGIS server code refactoring for QGIS 3.0 
>> https://github.com/qgis/QGIS-Enhancement-Proposals/issues/74
>> 
>> To keep the developement open, we proposed to use a github repository to 
>> centralize *Pull Request* and development strictly on QGIS Server with a 
>> dedicated branch https://github.com/3liz/QGIS/tree/master_qgis_server
>> We proposed to do so to have the possibility to broke the code but we will 
>> continue to merge master in it during the dev.
>> We will open the right to other QGIS Server developers and be proud to 
>> review Pull Request.
>> 
>> Our goal is to keep the functionalities, simplify the code and add 
>> modularity; to have something more maintainable, robust and expendable.
>> 
>> Regards,
>> René-Luc D'Hont
>> 3Liz
>> 
>> ___
>> 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

  ___
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] WIP: QGIS Server refactoring

[Neumann, Andreas]

Hi René-Luc, 

hm - I am not sure if this is good timing. 

Martin Dobias will refactor the layer tree extensively to allow a better
QGIS server code design. It is his proposal he submitted for the QGIS
grants. The swiss QGIS user group, potentially together with the german
QGIS user group will pay for his work, because it didn't make the grant
in the voting, but we still thought it is important work to be done. 

I guess it would make sense to wait until his work will be finished and
then start the QGIS server refactoring. However, it would be good to
collaborate with Martin to make sure his refactoring is useful for the
QGIS server refactoring. 

Greetings, 

Andreas 

On 2016-10-21 17:40, René-Luc Dhont wrote:

> Hi devs,
> 
> We (David Marteau and I) will start the QGIS Server refactoring.
> 
> The first step for us is to develop the *service register* like described in 
> the QEP: QGIS server code refactoring for QGIS 3.0 
> https://github.com/qgis/QGIS-Enhancement-Proposals/issues/74
> 
> To keep the developement open, we proposed to use a github repository to 
> centralize *Pull Request* and development strictly on QGIS Server with a 
> dedicated branch https://github.com/3liz/QGIS/tree/master_qgis_server
> We proposed to do so to have the possibility to broke the code but we will 
> continue to merge master in it during the dev.
> We will open the right to other QGIS Server developers and be proud to review 
> Pull Request.
> 
> Our goal is to keep the functionalities, simplify the code and add 
> modularity; to have something more maintainable, robust and expendable.
> 
> Regards,
> René-Luc D'Hont
> 3Liz
> 
> ___
> 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

Re: [Qgis-developer] Plans after friday's release?

[Neumann, Andreas]

Hi, 

> I am in favor of shooting down any 2.20 plans and fully focus on 3.0 to
> reduce the backporting overhead and improve dev-time and user-awareness
> towards 3.0.

+1 

Looking at the visual changelog of QGIS 2.18 and comparing with the
activity in the 3.x master branch I think the awareness towards 3.0 is
already there - which is good. 

The number of new features in 2.18 is considerably lower than e.g. in
2.16 and more and more new feature are in the 3x master branch only. 

> We could potentially also allow some non-intrusive features to land in
> there (some plans regarding this already exist).

+1 again. 

--- 

I'd also like to revisit the discussion about ending 2.x with an LT
version. 

It just seems illogical to me, to not end 2.x with an LT version. It is
kind of a waste of resources if we continue to backport stuff to 2.14
only and loose out on the many useful new features that were introduced
in 2.16 and 2.18. Think about all the nice things, like multi-attribute
search, multi-attribute editing, forms/widget improvements, and many
more - that won't reach the masses, because they are not in an LT
release for at least another year! 

Let's be more flexible and allow ourself to break the strict rule that
an LT version can only appear once a year, every third release. Rules
are here to break where useful/necessary. 

Just my opinion. 

Andreas ___
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] PG credentials

[Neumann, Andreas]

Hi Paolo, 

hm - not sure. 

If you have a .pgpass file it may take credentials from the .pgpass
file. 

Not sure what you mean "from the system" - you mean the credentials from
the operating system? Yes - this is another fallback mechanism - but it
depends how you configured your PostgreSQL access controls. 

Greetings, 

Andreas 

On 2016-10-18 13:25, Paolo Cavallini wrote:

> Hi all,
> if I open a project without saved credentials for PostgreSQL access,
> they seem to be taken from the system (the last used credentials). Is
> this confirmed, and the expected behaviour?
> All the best, and 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

Re: [Qgis-developer] feature selected expression

[Neumann, Andreas]

Hi Denis, 

It is in the "ExpressionsPlus" python plugin - for now. 

It was discussed if this could become a core feature - see thread
starting at
https://lists.osgeo.org/pipermail/qgis-developer/2016-September/044855.html
 

See feature request: https://hub.qgis.org/issues/15618 

Noone is assigned yet to work on it. We may probably fund Matthias to
work on it - but if you need this quicker, please go ahead and do or
fund it yourself. 

Andreas 

On 2016-10-12 15:12, Denis Rouzaud wrote:

> Hi all, 
> 
> I remember reading something about an expression to know if a feature is 
> selected or not, but can't recall where. 
> 
> Is this already in master? 
> 
> Can this be used for specific symbology of features in map composer? 
> 
> Thanks 
> 
> Denis
> 
> ___
> 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

Re: [Qgis-developer] QGIS server improvements

[Neumann, Andreas]

I think it needs a core dev familiar on the code base (specifically
server situation) to decide what needs to be done under the hood. 

I propose to ask Marco Hugentobler to take a technical lead on this,
since he started QGIS server and should be familiar with the issues.
Other devs can of course contribute. 

I can help coordinate finances or testing - but don't have enough inside
from a technical point of view. 

Andreas 

On 2016-10-12 10:07, Paolo Cavallini wrote:

> Il 12/10/2016 09:56, David Marteau ha scritto: 
> 
>> Hi,
>> 
>> There a QEP about the refactoring of the server that already addresses some 
>> issues: https://github.com/qgis/QGIS-Enhancement-Proposals/issues/74, could 
>> it fit as a starting point ?
> 
> Thanks everybody for comments. I agree we should start moving ASAP, and
> what we mainly need at this stage is someone taking the lead on this,
> ensuring that nothing important will fall into the cracks. Andreas,
> would you be available? Anybody else? If nobody, I can help.
> All the best.

  ___
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] Visualisation of relations

[Neumann, Andreas]

Hi Patrick, 

Matthias Kuhn, the one who knows about this the best, is currently out
of office / on holidays. I think he is back next week. 

I would probably wait for his review. 

Thanks and greetings, 

Andreas 

On 2016-10-12 09:48, Patrick Valsecchi wrote:

> No answer. I think I'll move forward with my proposal.
> 
> Thanks. 
> 
> On Fri, Oct 7, 2016 at 9:27 AM, Patrick Valsecchi 
>  wrote:
> 
>> Hi,
>> 
>> I'm tasked with making QGIS a bit more usable with complex database schemas 
>> having a lot of relations (up to hundreds of linked tables). The INSPIRE 
>> people were a bit too inspired when creating their data schemas and now we 
>> have to try to make QGIS able to cope with that.
>> 
>> My concerns with the current situation (as of QGIS master) are:
>> 
>> * We can specify the relations between the layers at the project level (it's 
>> now easier with the auto-discover feature for PostGIS and Spatialite). But 
>> those are only showing in the QgsAttributeForm for the 1-N side (the side 
>> that doesn't have the foreign key). Why not on the N-1 side?
>> * For showing the N-1 side in the QgsAttributeForm, one can define a Join in 
>> the layer's properties, but I don't see the point of having to define it 
>> here as well when we have already the relations info at the project level. I 
>> see a use for special joins, but for relations, I don't see why we have to 
>> define it twice. And the way it's displayed is not allowing to create joins 
>> or edit the joined fields.
>> * I let you imagine the look of the feature attribute form when there are 
>> hundreds of directly and indirectly linked tabled. This is just not usable 
>> if we display all of them directly like that. Just look at the attached 
>> screen shot that shows what happens by default with only 3 tables. It's 
>> already a mess.
>> 
>> Now, what I propose is: 
>> 
>> * Not expand the relation widget (QgsCollapsibleGroupBox) by default and 
>> build it's content only when it is expanded the first time (think of what 
>> would happen when you have loops in the schema).
>> * Show N-1 relations as well, in a collapsed by default 
>> QgsCollapsibleGroupBox, including a way to add a new linked entry, remove 
>> the link (put the FK to NULL) and delete it.
>> * Add a button to open a related feature in a new window.
>> 
>> What do you guys think? 
>> 
>> 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

Re: [Qgis-developer] QGIS server improvements

[Neumann, Andreas]

Hi Paolo / Tudor, 

I agree that the QGIS server improvements should be started. But you
need a clear plan on what to do in what order. Requirements need to go
first, otherwise there is no point in selecting devs, getting
quotes/estimates and doing a crowd-funding. And probably, several devs
will be involved. 

I wonder if a QGIS server dev could provide some insight in what needs
to be done, exactly. Who has a good overview regarding open issues
around QGIS server? Probably Marco? 

As to my knowledge, the following items need to be done: 

1. The API changes/improvements need to be done first. There are two
work items pending: 

- Proposal 14 from the QGIS grants titled "Project / Map layer registry
refactoring" from Martin Dobias. Most likely, the german and swiss QGIS
user group will fund this jointly. 

- The GUI/core separation of the widgets, cleanly separate GUI and core
for form widgets. This would allow better access to display values in
QGIS expressions and better access for (Python) Developers and the QGIS
server code base. I have a quote from Matthias Kuhn for approx. 4k EUR.
If someone can fund this, please let me know. 

I am sure there are more desired API changes that are useful for QGIS
server 

2. Then there is the switch from old map renderer to the new one. See
https://github.com/qgis/QGIS/pull/3129 

I don't know what other work items need to be done to get QGIS server in
good shape for QGIS 3.x? 

Lets spend some time first, to collect all the requirements before we do
any further actions. I think in this situation a QEP, describing what to
do in what order, makes a lot of sense. After that we can look into who
could do what. 

Andreas 

On 2016-10-12 09:00, Tudor Barascu wrote:

> Hi Paolo, 
> 
> A big thumbs up! 
> 
> All the best, 
> Tudor 
> 
> On Wednesday, October 12, 2016 8:28 AM, Paolo Cavallini 
>  wrote:
> 
> Hi all,
> after a first bloom of interest around the improvement/rewrite of qgis
> server, things seem stagnant nowadays. I suggest therefore to:
> * select one or more suitable developers
> * obtain an estimate
> * start a crowdfunding.
> Given the number of interested firms and individuals, I think it should
> be easy to reach the goal.
> Any objection to start soon?
> All the best.
> -- 
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
> ___
> 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

  ___
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] $scale vs. @map_scale variable - Inconsistency between Desktop and Server

[Neumann, Andreas]

Hi Nyall, 

Thank you - this explains it. I wasn't aware that QGIS server uses an
old map renderer. I did not even know that different map renderers
exist. But this has nothing to do with the old vs. the new symbology -
right? Because QGIS Server seems to work just fine with the new
symbology and labeling. 

So much work to do around QGIS 3.x / QGIS Server, etc. ...  

Andreas 

On 2016-10-11 10:05, Nyall Dawson wrote:

> On 11 Oct 2016 5:59 PM, "Neumann, Andreas" <a.neum...@carto.net> wrote:
>> 
>> Hi,
>> 
>> I noticed that $scale and @map_scale exist in parallel, but are not 
>> consistently behaving between QGIS Desktop and QGIS server.
>> 
>> $scale: works fine on both Desktop and Server, but expression preview in 
>> QGIS Desktop fails.
>> 
>> @map_scale: works fine on QGIS Desktop and also in expression preview, but 
>> fails on QGIS Server. 
> 
> Hi Andreas, 
> 
> Server doesn't have access to any of the map settings related variables, like 
> the scale, rotation, extent, etc. (This is why 25d ordering is messed up in 
> server). 
> 
> Server needs to be ported away from the old map renderer before this can be 
> fixed. 
> 
> Nyall
>> 
>> Context: expression to calculate letter spacing in a label for different map 
>> scale. Tested on QGIS Master 2.x on Windows 7 64bit.
>> 
>> Thank you,
>> 
>> Andreas
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> 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

[Qgis-developer] $scale vs. @map_scale variable - Inconsistency between Desktop and Server

[Neumann, Andreas]

Hi, 

I noticed that $scale and @map_scale exist in parallel, but are not
consistently behaving between QGIS Desktop and QGIS server. 

$scale: works fine on both Desktop and Server, but expression preview in
QGIS Desktop fails. 

@map_scale: works fine on QGIS Desktop and also in expression preview,
but fails on QGIS Server. 

Context: expression to calculate letter spacing in a label for different
map scale. Tested on QGIS Master 2.x on Windows 7 64bit. 

Thank you, 

Andreas 

  ___
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] Funding projects

[Neumann, Andreas]

Hi, 

I believe that a small thing that we could do and which would already
help is to maintain a list of current projects that need funding - and
add the contact information of the developer, who wants to work on it.
Maybe we could re-use the QEPs and publish a list of current QEPs and
add financial/contact information. And then delegate all the financials
to the dev. In addition, we could advertise these projects on social
media and amont the local QGIS user groups. The dev can then decide
whether he wants to deal with really small donations or whether he wants
to set a minimum amount to contributions. 

It would be a simple and effective way to make such projects more
visible to the public, while not adding a lot of bureaucracy. 

Also - if we would do all the financials through QGIS.ORG it would mean
a lot of work for me and we'd have to deal with tax issues, different
country laws, etc. - something I would like to avoid. And in general the
targetted donations would usually not meet the overall target, etc. It
is better if the dev who wants to work on an improvement would deal with
such issues. 

Andreas 

On 2016-10-06 09:05, Paolo Cavallini wrote:

> Il 06/10/2016 07:37, Neumann, Andreas ha scritto:
> 
>> So far, our (QGIS.ORG/QGIS-CH) financial resources for 2016 are
>> exhausted. Of course, if someone wants to work on this on his free time
>> or finds another sponsor, it would be very nice if this could make it
>> into QGIS 3.x rather sooner than later.
> 
> Sorry to hijack this thread. Should we resurrect the discussion about
> setting up targeted donations for specific projects?
> All the best.

  ___
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] Fields and forms redesign: - was Re: Preparing the Changelog for 2.18

[Neumann, Andreas]

Hi Nyall, 

> Ok cool. I've been thinking (based on the recent discussion re table
> manager plugin) that this existing rename field ability is quite
> hidden from users and could do with a better UI. Maybe it's time for
> https://github.com/qgis/QGIS-Enhancement-Proposals/issues/37 ...
> Nyall

I agree that it would be useful to implement a better UI for the whole
fields/widget/form management. It has been on the table for the past 2-3
years, but was never on the top of the list. It could be one topic for
the 2017 QGIS grants proposals or for the QGIS-CH sponsoring projects.
So far, our (QGIS.ORG/QGIS-CH) financial resources for 2016 are
exhausted. Of course, if someone wants to work on this on his free time
or finds another sponsor, it would be very nice if this could make it
into QGIS 3.x rather sooner than later. 

However, I wonder if the management of the drag and drop designer,
couldn't be more WYSIWYG. Other GIS software (like Autocad
Topobase/Map3d Infrastructure suite (or whatever it is called these
days)) can also do this. Can't we embed a form preview and have a better
"live" preview of our configuration (e.g. of tabs, groups, widgets,
labels, etc. Currently it is a bit like "working in the dark". 

Greetings,
Andreas 
  ___
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] Stepping back from the PSC

[Neumann, Andreas]

+1 

Thanks Marco for everything you have done for the project. And thanks
for staying with us as a core developer. 

You had been my very first contact regarding QGIS and helped me a lot to
establish QGIS at my previous work place in Uster. Without your support
I would have had a hard time introducing QGIS/FOSSGIS at this local
government. 

I also appreciated your commitment regarding QGIS Server in these past
years! 

Thanks a lot! 

Andreas 

On 2016-10-04 18:02, Jeff McKenna wrote:

> Thank you Marco for your leadership all of these years.  A huge pat on the 
> back from the whole community.  Thank you.
> 
> -jeff
> 
> -- 
> Jeff McKenna
> President Emeritus, OSGeo
> http://wiki.osgeo.org/wiki/Jeff_McKenna
> 
> On 2016-10-04 10:51 AM, Marco Hugentobler wrote: 
> 
>> Dear QGIS devs
>> 
>> After being 10 years in the QGIS PSC, I'd like to step back from my
>> position as a technical advisor. I feel that I don't have the necessary
>> time any more, so I would like to use the time I have for technical
>> things rather than organizational aspects of the project. Of course I'm
>> continuing to be a member of the developer team, so we'll stay in
>> contact anyway.
>> 
>> As discussed with Tim and in yesterdays PSC meeting, the project
>> organisation will be changed, possibly to move the former PSC roles over
>> to technical workgroup leads. Therefore we are not going to renew
>> outgoing PSC positions.
>> 
>> Finally I'd like to thank the other PSC members for the good
>> collaboration and the amazing work during all that time.
>> 
>> Best regards,
>> Marco
> 
> ___
> 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

Re: [Qgis-developer] Questions around xyz tile server connections in master 2

[Neumann, Andreas]

Hi Saber, 

I totally agree. It is great to have it in core. We just need to bring
it "on par" with the usability of e.g. the QuickMapServices. Otherwise,
people will just continue to use this plugin instead of the core QGIS
functionality. 

BTW: the QuickMapServices plugin also supports transparency, brightness,
contrast, grayscale, blend modes, smoothing, etc. 

Thanks and greetings, 

Andreas 

On 2016-10-04 16:31, Saber Razmjooei wrote:

> Hi Andreas, 
> 
> From user point of view, there is one other (very obvious) benefit of having 
> the native support: styling the XYZ layer. You can now adjust the 
> transparency, set blend mode/color rendering, etc similar to other rasters in 
> QGIS. 
> 
> Regards 
> 
> Saber 
> 
> FROM: Neumann, Andreas [mailto:a.neum...@carto.net] 
> SENT: 04 October 2016 10:08
> TO: Saber Razmjooei
> CC: 'QGIS Developers List'
> SUBJECT: RE: [Qgis-developer] Questions around xyz tile server connections in 
> master 2 
> 
> oh - SRP was indeed turned off. Silly me! 
> 
> Still I find that the "standard" methods of adding layers in QGIS should also 
> be provided for the tile servers, such as "Layer management toolbar" and Menu 
> "Layer --> AddLayer --> Add tile map server layer". I personally normally 
> don't use the QGIS browser panel and this means that I can't add tile maps if 
> this panel is not open. Or maybe the xyz tile map servers could be integrated 
> with the WMS/WMTS layer loading dialogue? 
> 
> Thanks for your reply! 
> 
> Andreas 
> 
> On 2016-10-04 10:52, Saber Razmjooei wrote: 
> 
> Hi Andreas, 
> 
> It works fine with my layers and the OTF on. 
> 
> Including some default services would be great, but unfortunately there are 
> some restrictions in using the service. 
> 
> See the original discussions here: 
> 
> https://github.com/qgis/QGIS/pull/3473 
> 
> Cheers 
> 
> Saber 
> 
> FROM: Qgis-developer [mailto:qgis-developer-boun...@lists.osgeo.org] ON 
> BEHALF OF Neumann, Andreas
> SENT: 04 October 2016 09:33
> TO: QGIS Developers List
> SUBJECT: Re: [Qgis-developer] Questions around xyz tile server connections in 
> master 2 
> 
> So I found out that http://tile.openstreetmap.org/{z}/{x}/{y}.png [1] seems 
> to work. 
> 
> However, if I add this OSM layer to my Swiss QGIS project (EPSG:21781) - the 
> swiss data seems to appear in the atlantic, west of "Guinea Ecuatorial" ;-( 
> 
> Andreas 
> 
> On 2016-10-04 09:48, Neumann, Andreas wrote: 
> 
> Hi, 
> 
> I have a couple of questions around the new "Tileserver" layer support in 
> QGIS desktop to be released with 2.18. I think the main commit is 
> https://github.com/qgis/QGIS/commit/f5b657db19eda7e72e6ed34eb7fe333c156acad0 
> - right? 
> 
> First, let me thank you a lot for this -  Martin and Lutra Consulting for 
> developing/sponsoring it! 
> 
> - 
> 
> However, I wonder if the usability of the newly added tilserver is already 
> good enough? Or at least I think it is not really obvious how to use it. 
> 
> 1. How can add a new connection to a tile server? Is the browser the only 
> way? If yes, I hope that an additional entry to Layer --> Add Layer menu 
> could be added - all other layer types can be added this way. 
> 
> 2. What is a correct URL? This is really hard to find out. F.e. I went to 
> http://wiki.openstreetmap.org/wiki/Tile_servers and tried to copy some URLs 
> and failed about finding the correct syntax. I added the layer to the project 
> --> nothing happened. No display, no error message. Maybe because the 
> projections do not match? - or would QGIS reproject on the fly? 
> 
> 3. Can we add some popular tile map server URLs by default - similar to the 
> QuickMapServices plugin? 
> 
> 4. How can one edit an existing tile server connection - e.b. change title or 
> URL? Currently, one can only delete and re-add it. 
> 
> - 
> 
> Thank you for your reply, 
> 
> Andreas
> 
> ___
> 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 
> 
> -
> 
> This email and any files transmitted with it are confidential and intended 
> solely for the use of the individual or entity to whom they are addressed. If 
> you have received this email in error please notify the system manager. This 
> message contains confidential information and is intended only for the 
> individual named. If you are not the named addressee you should not 
> dissemin

Re: [Qgis-developer] Questions around xyz tile server connections in master 2

[Neumann, Andreas]

oh - SRP was indeed turned off. Silly me! 

Still I find that the "standard" methods of adding layers in QGIS should
also be provided for the tile servers, such as "Layer management
toolbar" and Menu "Layer --> AddLayer --> Add tile map server layer". I
personally normally don't use the QGIS browser panel and this means that
I can't add tile maps if this panel is not open. Or maybe the xyz tile
map servers could be integrated with the WMS/WMTS layer loading
dialogue? 

Thanks for your reply! 

Andreas 

On 2016-10-04 10:52, Saber Razmjooei wrote:

> Hi Andreas, 
> 
> It works fine with my layers and the OTF on. 
> 
> Including some default services would be great, but unfortunately there are 
> some restrictions in using the service. 
> 
> See the original discussions here: 
> 
> https://github.com/qgis/QGIS/pull/3473 
> 
> Cheers 
> 
> Saber 
> 
> FROM: Qgis-developer [mailto:qgis-developer-boun...@lists.osgeo.org] ON 
> BEHALF OF Neumann, Andreas
> SENT: 04 October 2016 09:33
> TO: QGIS Developers List
> SUBJECT: Re: [Qgis-developer] Questions around xyz tile server connections in 
> master 2 
> 
> So I found out that http://tile.openstreetmap.org/{z}/{x}/{y}.png [1] seems 
> to work. 
> 
> However, if I add this OSM layer to my Swiss QGIS project (EPSG:21781) - the 
> swiss data seems to appear in the atlantic, west of "Guinea Ecuatorial" ;-( 
> 
> Andreas 
> 
> On 2016-10-04 09:48, Neumann, Andreas wrote:
> 
>> Hi, 
>> 
>> I have a couple of questions around the new "Tileserver" layer support in 
>> QGIS desktop to be released with 2.18. I think the main commit is 
>> https://github.com/qgis/QGIS/commit/f5b657db19eda7e72e6ed34eb7fe333c156acad0 
>> - right? 
>> 
>> First, let me thank you a lot for this -  Martin and Lutra Consulting for 
>> developing/sponsoring it! 
>> 
>> - 
>> 
>> However, I wonder if the usability of the newly added tilserver is already 
>> good enough? Or at least I think it is not really obvious how to use it. 
>> 
>> 1. How can add a new connection to a tile server? Is the browser the only 
>> way? If yes, I hope that an additional entry to Layer --> Add Layer menu 
>> could be added - all other layer types can be added this way. 
>> 
>> 2. What is a correct URL? This is really hard to find out. F.e. I went to 
>> http://wiki.openstreetmap.org/wiki/Tile_servers and tried to copy some URLs 
>> and failed about finding the correct syntax. I added the layer to the 
>> project --> nothing happened. No display, no error message. Maybe because 
>> the projections do not match? - or would QGIS reproject on the fly? 
>> 
>> 3. Can we add some popular tile map server URLs by default - similar to the 
>> QuickMapServices plugin? 
>> 
>> 4. How can one edit an existing tile server connection - e.b. change title 
>> or URL? Currently, one can only delete and re-add it. 
>> 
>> - 
>> 
>> Thank you for your reply, 
>> 
>> Andreas
>> 
>> ___
>> 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
> 
> -
> 
> This email and any files transmitted with it are confidential and intended 
> solely for the use of the individual or entity to whom they are addressed. If 
> you have received this email in error please notify the system manager. This 
> message contains confidential information and is intended only for the 
> individual named. If you are not the named addressee you should not 
> disseminate, distribute or copy this e-mail. Please notify the sender 
> immediately by e-mail if you have received this e-mail by mistake and delete 
> this e-mail from your system. If you are not the intended recipient you are 
> notified that disclosing, copying, distributing or taking any action in 
> reliance on the contents of this information is strictly prohibited. 
> 
> Whilst reasonable care has been taken to avoid virus transmission, no 
> responsibility for viru ses is taken and it is your responsibility to carry 
> out such checks as you feel appropriate. 
> 
> If this email contains a quote or offer to sell products, carry out work or 
> perform services then our standard terms and conditions [2] shall apply 
> unless explicitly stated otherwise. 
> 
> Saber Razmjooei and Peter Wells trading as Lutra Consulting.

  

Links:
--
[1] http://tile.openstreetmap.org/%7bz%7d/%7bx%7d/%7by%7d.png
[2]
http://www.lutraconsulting.co.uk/downloads/Lutra%20Consulting%20Standard%20Terms%20and%20Conditions.pdf___
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 around xyz tile server connections in master 2

[Neumann, Andreas]

So I found out that http://tile.openstreetmap.org/{z}/{x}/{y}.png seems
to work. 

However, if I add this OSM layer to my Swiss QGIS project (EPSG:21781) -
the swiss data seems to appear in the atlantic, west of "Guinea
Ecuatorial" ;-( 

Andreas 

On 2016-10-04 09:48, Neumann, Andreas wrote:

> Hi, 
> 
> I have a couple of questions around the new "Tileserver" layer support in 
> QGIS desktop to be released with 2.18. I think the main commit is 
> https://github.com/qgis/QGIS/commit/f5b657db19eda7e72e6ed34eb7fe333c156acad0 
> - right? 
> 
> First, let me thank you a lot for this -  Martin and Lutra Consulting for 
> developing/sponsoring it! 
> 
> - 
> 
> However, I wonder if the usability of the newly added tilserver is already 
> good enough? Or at least I think it is not really obvious how to use it. 
> 
> 1. How can add a new connection to a tile server? Is the browser the only 
> way? If yes, I hope that an additional entry to Layer --> Add Layer menu 
> could be added - all other layer types can be added this way. 
> 
> 2. What is a correct URL? This is really hard to find out. F.e. I went to 
> http://wiki.openstreetmap.org/wiki/Tile_servers and tried to copy some URLs 
> and failed about finding the correct syntax. I added the layer to the project 
> --> nothing happened. No display, no error message. Maybe because the 
> projections do not match? - or would QGIS reproject on the fly? 
> 
> 3. Can we add some popular tile map server URLs by default - similar to the 
> QuickMapServices plugin? 
> 
> 4. How can one edit an existing tile server connection - e.b. change title or 
> URL? Currently, one can only delete and re-add it. 
> 
> - 
> 
> Thank you for your reply, 
> 
> Andreas
> 
> ___
> 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

[Qgis-developer] Questions around xyz tile server connections in master 2

[Neumann, Andreas]

Hi, 

I have a couple of questions around the new "Tileserver" layer support
in QGIS desktop to be released with 2.18. I think the main commit is
https://github.com/qgis/QGIS/commit/f5b657db19eda7e72e6ed34eb7fe333c156acad0
- right? 

First, let me thank you a lot for this -  Martin and Lutra Consulting
for developing/sponsoring it! 

- 

However, I wonder if the usability of the newly added tilserver is
already good enough? Or at least I think it is not really obvious how to
use it. 

1. How can add a new connection to a tile server? Is the browser the
only way? If yes, I hope that an additional entry to Layer --> Add Layer
menu could be added - all other layer types can be added this way. 

2. What is a correct URL? This is really hard to find out. F.e. I went
to http://wiki.openstreetmap.org/wiki/Tile_servers and tried to copy
some URLs and failed about finding the correct syntax. I added the layer
to the project --> nothing happened. No display, no error message. Maybe
because the projections do not match? - or would QGIS reproject on the
fly? 

3. Can we add some popular tile map server URLs by default - similar to
the QuickMapServices plugin? 

4. How can one edit an existing tile server connection - e.b. change
title or URL? Currently, one can only delete and re-add it. 

- 

Thank you for your reply, 

Andreas

  ___
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] Fwd: Re: [Geopackage] Geopackage on a shared network drive

[Neumann, Andreas]

Hi Even, 

Thank you for sharing this finding! 

In that case I think that QGIS should offer a flag to open Geopackages
in read-only mode. 

Even - since you are "Mr. Geopackage" in the QGIS project anyway - can
you please make sure that this can be covered in the upcoming Geopackage
improvements? Would a "read-only" mode also be useful for other data
formats? I opened a ticket at http://hub.qgis.org/issues/15652 and
assigned it to you. I have no idea how much effort this enhancement
would mean - can you please do an estimate and send me a quote for that?
Maybe we could still include it in the upcoming Geopackage improvements
financed by the Swiss QGIS user group. 

--- 

This also leads to a follow up question: many OGR data formats have
"open options". As far as I know, these options are not exposed to the
User in QGIS, other than the encoding - or did I miss something? Should
we introduce a "GUI" way in QGIS 3.x to expose these "open options" in
the "add vector layer" dialogue? 

Thanks,
Andreas 

On 2016-10-01 23:38, Even Rouault wrote:

> FYI: An interesting finding to improve performance of large Geopackage on a 
> shared network drive.
> 
> --  Message transmis  --
> 
> Sujet : Re: [Geopackage] Geopackage on a shared network drive
> Date : samedi 01 octobre 2016, 16:41:05
> De : Árni Geirsson via Geopackage 
> À : Even Rouault 
> CC : geopack...@lists.opengeospatial.org
> 
> Yes! It renders very quickly after I set the read-only flag in the file
> explorer.
> That goes a long way towards solving the problem for me because as I
> mentioned, the team would like to use this format to store geodata, not to
> edit it and certainly not to make edits by multiple concurrent users.
> Thank you so much for your help!
> 
> Árni
> 
> Árni Geirsson
> *Alta ehf* // +354 582 5000 // +354 897 9549
> www.alta.is [1]  // Alta á Twitter  // Alta á
> Facebook 
> Gæða- og umhverfisstefna Alta 
> 
> On 1 October 2016 at 14:28, Even Rouault  wrote:
> 
> Le samedi 01 octobre 2016 16:02:38, Árni Geirsson a écrit : Hello Even
> Thank you for your suggestion. I made the changes you suggested, adding
> set SQLITE_USE_OGR_VFS=YES
> after
> set VSI_CACHE=TRUE
> set VSI_CACHE_SIZE=100
> but there was no difference. Was this perhaps not the right way to do it? 
> Yes, that's correct.
> 
> Hum actually reviewing the code, the cache mechanism is only enabled when
> the
> file is opened in read-only mode, whereas QGIS will open the file in
> read-write
> mode.
> 
> You could perhaps try to make the GPKG read-only in the explorer?, at least
> just to test if it is a promising optimization. I guess write support for
> the
> cache mechanism could be added.
> 
> A drawback of a cache machnism is that it would defeat the updates in
> SQLite
> to deal with concurrent editing, but anyway such mechanisms don't work very
> well on network shares.
> 
> Anyway, I would think that I am not alone in seeing this as a problem but I 
> find very little about it on the web.
> 
> Árni
> 
> Árni Geirsson
> *Alta ehf* // +354 582 5000 // +354 897 9549
> www.alta.is [1]  // Alta á Twitter  // Alta á
> Facebook 
> Gæða- og umhverfisstefna Alta 
> 
> On 30 September 2016 at 19:52, Even Rouault 
> 
> wrote: Le vendredi 30 septembre 2016 00:44:45, Árni Geirsson via Geopackage a
> 
> écrit : Dear Geopackage developers!
> I look forward to the day when Geopackage replaces the old shapefiles 
> and I
> 
> thank you for your efforts. As a user in a small team that uses QGIS
> and shares data on a NAS box, basically a Samba server for network
> shares, I notice that Geopackage data loads very slowly, much more
> slowly than a shapefile stored in exactly the same shared folder. I
> have noticed this with Spatialite, too, and suspect that the problem
> lies with Sqlite and some problem it has with the networking
 protocol. 

> Since Geopackage is intended (as I understand) as a storage and
> exchange format for geodata, rather than a general purpose database
> format like Spatialite, I was 
> hoping
> 
> that this problem could be overcome and that the Geopackage data
 would 

> load
> 
> as fast as the shapefile data from the network share. When the
> Geopackage and shapefile data are both on a local drive, I see no
> difference in the loading speed.
> 
> Do you think this will be solved? 
> QGIS tweaks GDAL/OGR to use a large buffer size to speed up network
> access to
> shapefiles (or any format that uses the GDAL I/O layer, which is called
> "VSI").
> 
> If you look at the qgis.bat in c:\osgeo4w\bin, you will see :
> set VSI_CACHE=TRUE
> set 

Re: [Qgis-developer] QWT polar for qgis 3?

[Neumann, Andreas]

Hi, 

I vaguely remember that it is used to display the satellite
constellation of GPS receivers. Potentially also used by some Python
plugins. 

qwt and qwt-polars did cause quite a few troubles for me during
compiling in the past. 

Given that qt5 has a charting component that also includes polar charts
(http://doc.qt.io/qt-5/qtcharts-index.html), I would appreciate to get
rid of the qwtpolar dependency. 

Andreas 

On 2016-09-30 07:35, Nathan Woodrow wrote:

> Where is it used? 
> 
> On Fri, 30 Sep 2016 3:10 pm Nyall Dawson  wrote: 
> 
>> Just wanted to raise this discussion again now that we've dropped qt4
>> compatibility.
>> 
>> Should we remove all references to qwt polar from the source and
>> remove the associated cmake flag? AFAIK it can't be used with qt5 and
>> the flag causes a lot of issues for new builders who don't know that
>> they need to disable it.
>> 
>> Nyall
>> ___
>> 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

  ___
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 2 master on Windows: lots of crashes when using the color picker dialog

[Neumann, Andreas]

Hi Jürgen, 

Are you referring to
https://github.com/qgis/QGIS/commit/c7c52442f71a6a17ea1ad97e741b2b4b6d51f698
? 

I just compiled the latest 2x version and the crash still happens ;-( 

Thanks, 

Andreas 

On 2016-09-28 17:29, Jürgen E. Fischer wrote:

> Hi Andreas,
> 
> On Wed, 28. Sep 2016 at 17:00:09 +0200, Neumann, Andreas wrote: 
> 
>> I can confirm that. It happens for categorized and for rule based renderers,
>> but not for single symbol or graduated renderers.
> 
> I also noticed a crash, when using identify on certain categorized layers.
> That's fixed - maybe your problem is/was related.
> 
> Jürgen 
> ___
> 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

Re: [Qgis-developer] QGIS 2 master on Windows: lots of crashes when using the color picker dialog

[Neumann, Andreas]

Hi Tom, 

Thank you for your tests. It is encouraging that others can reproduce.
This justifies that I'll do a bug report. 

Meanwhile I also tested on Linux and it behaves the same like the
Windows version. More comments below. 

On 2016-09-28 10:42, Tom Chadwin wrote:

> Confirmed with 0497e4a. Could it be limited to categorized renderers?
> Specifically, in my tests:
> 
> 1. does *not* occur with single symbol or graduated renderer

I can confirm that. It happens for categorized and for rule based
renderers, but not for single symbol or graduated renderers. 

> 2. in categorized renderer, does *not* occur if double click category icon
> in ToC

confirmed 

> 3. in categorized renderer *does* occur if click layer (not category) in ToC

confirmed

Here is my bug report: http://hub.qgis.org/issues/15634 

Thanks, 

Andreas 

--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/QGIS-2-master-on-Windows-lots-of-crashes-when-using-the-color-picker-dialog-tp5288053p5288207.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

[Qgis-developer] QGIS 2 master on Windows: lots of crashes when using the color picker dialog

[Neumann, Andreas]

Hi, 

I noticed that I quite often get crashes in QGIS 2 master when I use the
color picker. This is when I open the layer properties, change a style,
open the color dialogue, close it with "ok" and crash. It is quite
reproducable - happens almost always. I doesn't seem to happen when I
use the same color dialogue from the styling dock. 

Can others confirm this issue? If yes, I will open an issue (severe,
because of the crash). 

I don't know what other information I can provide? 

Here is an animated gif showing what I do to get the crash:
http://www.carto.net/neumann/temp/qgis-crash-color-dialog.gif  

Thanks, 

Andreas 

  ___
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