Re: [QGIS-Developer] On the fly on MapCanvas

[Erick Duran]

Estimados muy buenas noches

Necesito alguien me ayude, no soy muy experto en el uso de qgis, estoy
usando la versión 3.12, quiero utilizar el complemento azimut y distancia y
me aparece este error TypeError: 'NoneType' object is not subscriptable

Traceback (most recent call last):
  File 
"C:/Users/ERICK/AppData/Roaming/QGIS/QGIS3\profiles\default/python/plugins\AzimuthDistanceCalculator\azimuthsAndDistances\azimuthsAndDistances.py",
line 169, in fillTable
if self.points[0] == self.points[len(self.points) - 1]:
TypeError: 'NoneType' object is not subscriptable


Versión de Python: 3.7.0 (v3.7.0:1bf9cc5093, Jun 27 2018, 04:59:51)
[MSC v.1914 64 bit (AMD64)]
Versión de QGIS: 3.12.0-București București, cd141490ec

Agradere mucho me ayuden como soluciono este problema

saludos..

*Erick E. Duran*

*Técnico* *agrícola*

*El. 3172-93-35*

*Email. duraneric...@gmail.com  *






El lun., 16 de mar. de 2020 a la(s) 20:54,  escribió:

> Dear QGIS-Developer,
>
> I am writing a simple program to display raster data using qgis api C++.
>
> When I open raster data that has different coordinate systems, the
> on-the-fly feature does not work on my mapCanvas.
>
> Can someone help me?
>
> This is my code:
>
> OpenGisData::OpenGisData(QWidget *parent)
>
> : QMainWindow(parent)
>
> {
>
> setupUi(this);
>
> QWidget* centralWidget = OpenGisDataClass::centralWidget;
>
> mMapCanvas = new QgsMapCanvas(centralWidget);
>
> QGridLayout* gridLayout = new QGridLayout;
>
> gridLayout->addWidget(mMapCanvas);
>
> centralWidget->setLayout(gridLayout);
>
> connect(actionOpen, ::triggered, this, ::open);
>
> }
>
> void OpenGisData::open()
>
> {
>
> QString fileName = QFileDialog::getOpenFileName(this, "Open data",
> "D:\\Test");
>
> if (!fileName.isEmpty())
>
> {
>
> QgsRasterLayer* rasterLayer = new QgsRasterLayer(fileName);
>
> if (rasterLayer && rasterLayer->isValid())
>
> {
>
> QList layers = mMapCanvas->layers();
>
> layers.append(rasterLayer);
>
>
>
> mMapCanvas->setLayers(layers);
>
> mMapCanvas->zoomToFullExtent();
>
> }
>
> }
>
> }
>
>
>
> Thank You
> ___
> 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] On the fly on MapCanvas

[bachgist]

Dear QGIS-Developer,

I am writing a simple program to display raster data using qgis api C++.

When I open raster data that has different coordinate systems, the
on-the-fly feature does not work on my mapCanvas.

Can someone help me?

This is my code:

OpenGisData::OpenGisData(QWidget *parent)

: QMainWindow(parent)

{

setupUi(this);

QWidget* centralWidget = OpenGisDataClass::centralWidget;

mMapCanvas = new QgsMapCanvas(centralWidget);

QGridLayout* gridLayout = new QGridLayout;

gridLayout->addWidget(mMapCanvas);

centralWidget->setLayout(gridLayout);

connect(actionOpen, ::triggered, this, ::open);

}

void OpenGisData::open()

{

QString fileName = QFileDialog::getOpenFileName(this, "Open data",
"D:\\Test");

if (!fileName.isEmpty())

{

QgsRasterLayer* rasterLayer = new QgsRasterLayer(fileName);

if (rasterLayer && rasterLayer->isValid())

{

QList layers = mMapCanvas->layers();

layers.append(rasterLayer);

 

mMapCanvas->setLayers(layers);

mMapCanvas->zoomToFullExtent();

}

}

}

 

Thank You

___
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] More PR problems

[William Kyngesburye]

Still getting same failure.

-
William Kyngesburye



Don't Panic

> On Mar 16, 2020, at 7:20 PM, Nyall Dawson  wrote:
> 
> On Sat, 14 Mar 2020 at 10:05, William Kyngesburye  
> wrote:
>> 
>> Ah, but I can't proceed with merging the PR until the ci succeeds.  And I 
>> don't see a way to bypass the failing test, though others could when another 
>> PR failed an unrelated test.
> 
> Quite a lot of test fixes committed over the last couple of days.
> Fingers crossed this will stabilise things!
> 
> Nyall
> 
>> 
>> -
>> William Kyngesburye
>> 
>> 
>> 
>> Don't Panic
>> 
 On Mar 13, 2020, at 5:00 PM, Nyall Dawson  wrote:
>>> 
>>> On Sat, 14 Mar 2020 at 04:20, William Kyngesburye  
>>> wrote:
 
 I'm having a different problem now with another PR - travis error from 
 Auto set milestone on PR.  Test #586 fails with
 
 CMake Error at PyQgsOfflineEditingWFS.cmake:15 (MESSAGE):
 5102 Test failed: 124
>>> 
>>> I'd suggest ignoring the ci failures for your work at the moment --
>>> the CI infrastructure is going through some pains as we've a number of
>>> simultaneously flaky tests. They'll get solved (or disabled), but in
>>> the meantime you can be confident it's **not** related to your work!
>>> 
>>> Nyall
>>> 
 
 This time it periodically retries and I'm getting a lot of notification 
 emails.
 
 Again, it appears to be completely unrelated to my PR.
 
 And, still no luck with the backport bot.  Very frustrating.
 
 -
 William Kyngesburye
 
 
 
 Don't Panic
 ___
 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] More PR problems

[Nyall Dawson]

On Sat, 14 Mar 2020 at 10:05, William Kyngesburye  wrote:
>
> Ah, but I can't proceed with merging the PR until the ci succeeds.  And I 
> don't see a way to bypass the failing test, though others could when another 
> PR failed an unrelated test.

Quite a lot of test fixes committed over the last couple of days.
Fingers crossed this will stabilise things!

Nyall

>
> -
> William Kyngesburye
> 
> 
>
> Don't Panic
>
> > On Mar 13, 2020, at 5:00 PM, Nyall Dawson  wrote:
> >
> > On Sat, 14 Mar 2020 at 04:20, William Kyngesburye  
> > wrote:
> >>
> >> I'm having a different problem now with another PR - travis error from 
> >> Auto set milestone on PR.  Test #586 fails with
> >>
> >> CMake Error at PyQgsOfflineEditingWFS.cmake:15 (MESSAGE):
> >> 5102 Test failed: 124
> >
> > I'd suggest ignoring the ci failures for your work at the moment --
> > the CI infrastructure is going through some pains as we've a number of
> > simultaneously flaky tests. They'll get solved (or disabled), but in
> > the meantime you can be confident it's **not** related to your work!
> >
> > Nyall
> >
> >>
> >> This time it periodically retries and I'm getting a lot of notification 
> >> emails.
> >>
> >> Again, it appears to be completely unrelated to my PR.
> >>
> >> And, still no luck with the backport bot.  Very frustrating.
> >>
> >> -
> >> William Kyngesburye
> >> 
> >> 
> >>
> >> Don't Panic
> >> ___
> >> 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] Understanding plugin management in QGIS - exposing QgsPluginRegistry to Python?

[Sebastian M. Ernst]

Hi Oliver,

> I'd suggest drafting a QEP already, as adding support for pip/conda
> dependencies (which would be awesome !!) raises a few important
> questions (for example whether we have virtualenvs or similar on all
> systems, how plugins would declare their deps, how to deal with
> incompatible deps, or if we even go one step further and support
> distribution qgis plugin as pip packages, etc...). And there may be some
> other ideas around worth sharing at an early stage (such as proper
> multiple plugin versions support, also improving the plugin repository
> API - which by the way is also Python code, etc).

yes, I have considered writing a QEP. It is the important questions that
you have raised which make me hesitate to write a QEP just yet. I intend
to first experiment with different approaches and explore and test them
well before I'd even suggest going down any specific path. Having said
that, I am more than happy to hear about ideas on what should be tested
in this context.

Best regards,
Sebastian
___
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] Understanding plugin management in QGIS - exposing QgsPluginRegistry to Python?

[Olivier Dalang]

Hi !

Thanks Sebastian for willing to work on this !

I'd suggest drafting a QEP already, as adding support for pip/conda
dependencies (which would be awesome !!) raises a few important questions
(for example whether we have virtualenvs or similar on all systems, how
plugins would declare their deps, how to deal with incompatible deps, or if
we even go one step further and support distribution qgis plugin as pip
packages, etc...). And there may be some other ideas around worth sharing
at an early stage (such as proper multiple plugin versions support, also
improving the plugin repository API - which by the way is also Python code,
etc).

As for the Python or C++ discussion, I don't have enough experience to help
decide, but what's sure is that either will be better than status quo in
terms of maintenance !

Cheers,

Olivier





On Mon, 16 Mar 2020 at 12:10, Sebastian M. Ernst 
wrote:

> Hi Nyall, Paolo, Alexander, Javier,
>
> > The issues we see most often stem not from any particular use of
> > Python, but (as Matthias has pointed out) through the nature of
> > Pythons weak typing and lack of compile time checks. A simple example:
> > if I alter the signature of a virtual method in one of the c++ classes
> > to add an extra argument or change a return type, I'll know right away
> > (well, when I next compile) if I've broken some existing code. If I do
> > the same in Python, I'm basically trusting that my particular IDE can
> > correctly identify ALL use of that method, because I won't get any
> > warning if I did break something. Unit tests help, but will never
> > completely avoid this kind of breakage.
>
> agreed. One can significantly reduce the risk with the right tooling, a
> lot of discipline, experience and tests. But one can never rule this
> sort of thing out entirely. It is the nature of what Python allows you
> to do (whether or not some of this stuff can be considered good or bad
> practice) vs. what static analysis tools can understand. Most of what I
> am interested in doing here does not require pitch-black Python magic,
> so a good tool-chain should be able to handle it if the code is written
> adequately (at least in my personal experience).
>
> Javier, you alluded on type hints. Yes, they are one of the interesting
> options one has in modern Python. And if your code is not too
> performance-critical, there are actually ways to make the interpreter
> respect then at run-time, i.e. Python with static types in
> function/method signatures :) None of this is currently being used in QGIS.
>
> > Another HUGE factor with Python+QGIS is that the actual methods of
> > creating the Python bindings + the PyQt library itself is a mysterious
> > black box, full of weird inconsistencies, random results, memory
> > mismanagement and crashy code practices. I shudder to think of the
> > amount of time I've wasted fighting with SIP and its unpredictable
> > behavior. You could write the BEST Python code the world has ever
> > seen, using all the Python best practice coding techniques you want,
> > and you'll still hit random regressions and issues due to these
> > libraries. QGIS c++ code is just MUCH more predictable, transparent,
> > and easier to debug.
>
> Ok, this sounds like serious issues with SIP. The smaller your SIP
> interface is, the smaller your surface of attack becomes. Which makes me
> wonder ... even if you shift as much of QGIS' logic from Python to C++,
> you'll always be stuck with some SIP due to your Python integration and
> the plugin ecosystem. From what I have seen, QGIS (in its current form)
> is the ultimate stress-test for SIP as in QGIS does some really wild
> stuff with it. Would not it make sense to clean up a lot of those SIP
> interfaces and limit them to what actually makes sense?
>
> > But please please please can I ask you to seriously reconsider your
> > approach? I've been working on this project for nearly 10 years now,
> > and my experience time and time again is that large blocks of Python
> > code in QGIS end up unstable. Modern c++ + qt is really not that much
> > trickier to write then Python, and if you include good test coverage,
> > then the code becomes almost self-maintaining*.
>
> I have not seen any self-maintaining code in my life ;)
>
> Personally, but that's just a non-technical preference, I am way faster
> & better with prototyping / developing in Python than I am in C++. I
> usually port code away from Python in a later work step once stuff is
> working (and tested). Other than that, while understanding your points,
> I can still see how a Python solution / prototype could make sense from
> a technical perspective and still address your concerns. Allow me to
> elaborate on it.
>
> I want to manage Python plugins, Python packages and Python dependencies
> as well as load, unload and inspect Python code while remaining on top
> of things by catching and treating all possible exceptions in this
> process. Therefore, I want to work closely with some 

[QGIS-Developer] Plugin [232] NumericalDigitize approval notification.

[noreply]

Plugin NumericalDigitize approval by zimbogisgeek.
The plugin version "[232] NumericalDigitize 0.4.4" is now approved
Link: http://plugins.qgis.org/plugins/numericalDigitize/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Plugin [2005] Covid19 Tracker unapproval notification.

[noreply]

Plugin Covid19 Tracker unapproval by zimbogisgeek.
The plugin version "[2005] Covid19 Tracker 0.1" is now unapproved
Link: http://plugins.qgis.org/plugins/covid19_tracker/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Plugin [232] NumericalDigitize approval notification.

[noreply]

Plugin NumericalDigitize approval by zimbogisgeek.
The plugin version "[232] NumericalDigitize 0.3.0" is now approved
Link: http://plugins.qgis.org/plugins/numericalDigitize/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Plugin [2005] Covid19 Tracker approval notification.

[noreply]

Plugin Covid19 Tracker approval by zimbogisgeek.
The plugin version "[2005] Covid19 Tracker 0.1" is now approved
Link: http://plugins.qgis.org/plugins/covid19_tracker/
___
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] Understanding plugin management in QGIS - exposing QgsPluginRegistry to Python?

[Sebastian M. Ernst]

Hi Nyall, Paolo, Alexander, Javier,

> The issues we see most often stem not from any particular use of
> Python, but (as Matthias has pointed out) through the nature of
> Pythons weak typing and lack of compile time checks. A simple example:
> if I alter the signature of a virtual method in one of the c++ classes
> to add an extra argument or change a return type, I'll know right away
> (well, when I next compile) if I've broken some existing code. If I do
> the same in Python, I'm basically trusting that my particular IDE can
> correctly identify ALL use of that method, because I won't get any
> warning if I did break something. Unit tests help, but will never
> completely avoid this kind of breakage.

agreed. One can significantly reduce the risk with the right tooling, a
lot of discipline, experience and tests. But one can never rule this
sort of thing out entirely. It is the nature of what Python allows you
to do (whether or not some of this stuff can be considered good or bad
practice) vs. what static analysis tools can understand. Most of what I
am interested in doing here does not require pitch-black Python magic,
so a good tool-chain should be able to handle it if the code is written
adequately (at least in my personal experience).

Javier, you alluded on type hints. Yes, they are one of the interesting
options one has in modern Python. And if your code is not too
performance-critical, there are actually ways to make the interpreter
respect then at run-time, i.e. Python with static types in
function/method signatures :) None of this is currently being used in QGIS.

> Another HUGE factor with Python+QGIS is that the actual methods of
> creating the Python bindings + the PyQt library itself is a mysterious
> black box, full of weird inconsistencies, random results, memory
> mismanagement and crashy code practices. I shudder to think of the
> amount of time I've wasted fighting with SIP and its unpredictable
> behavior. You could write the BEST Python code the world has ever
> seen, using all the Python best practice coding techniques you want,
> and you'll still hit random regressions and issues due to these
> libraries. QGIS c++ code is just MUCH more predictable, transparent,
> and easier to debug.

Ok, this sounds like serious issues with SIP. The smaller your SIP
interface is, the smaller your surface of attack becomes. Which makes me
wonder ... even if you shift as much of QGIS' logic from Python to C++,
you'll always be stuck with some SIP due to your Python integration and
the plugin ecosystem. From what I have seen, QGIS (in its current form)
is the ultimate stress-test for SIP as in QGIS does some really wild
stuff with it. Would not it make sense to clean up a lot of those SIP
interfaces and limit them to what actually makes sense?

> But please please please can I ask you to seriously reconsider your
> approach? I've been working on this project for nearly 10 years now,
> and my experience time and time again is that large blocks of Python
> code in QGIS end up unstable. Modern c++ + qt is really not that much
> trickier to write then Python, and if you include good test coverage,
> then the code becomes almost self-maintaining*.

I have not seen any self-maintaining code in my life ;)

Personally, but that's just a non-technical preference, I am way faster
& better with prototyping / developing in Python than I am in C++. I
usually port code away from Python in a later work step once stuff is
working (and tested). Other than that, while understanding your points,
I can still see how a Python solution / prototype could make sense from
a technical perspective and still address your concerns. Allow me to
elaborate on it.

I want to manage Python plugins, Python packages and Python dependencies
as well as load, unload and inspect Python code while remaining on top
of things by catching and treating all possible exceptions in this
process. Therefore, I want to work closely with some Python modules,
e.g. `ast`, `inspect`, `importlib` and `conda.api`. I am heavily tapping
into the interpreter for that. The closer I remain to my objective, the
more flexibility I have and the more stability I gain. Even if I move as
much as possible over to C++, i.e. the GUI and some logic, the actually
required Python layer (plus C++ interface code) would remain
substantial. It would also lead to a convoluted logic, probably in the
end only little better than the current plugin installer. This is
precisely what I want to get away from. Having said that, the plugin
manager is - from my perspective at least - different from processing or
the db manager. They are significantly different technical problems.
While I agree with you that, due to SIP, it is a good idea to move as
much of processing and db manager over to C++, I am thinking that going
the opposite direction specifically *here* makes more sense. While QGIS
is a hybrid, I'd attempt to limit my exposure to SIP by limiting my
interaction with QGIS (and 

Re: [QGIS-Developer] Understanding plugin management in QGIS - exposing QgsPluginRegistry to Python?

[javier]

Hi all,


The issues we see most often stem not from any particular use of
Python, but (as Matthias has pointed out) through the nature of
Pythons weak typing and lack of compile time checks. A simple example:
if I alter the signature of a virtual method in one of the c++ classes
to add an extra argument or change a return type, I'll know right away
(well, when I next compile) if I've broken some existing code. If I do
the same in Python, I'm basically trusting that my particular IDE can
correctly identify ALL use of that method, because I won't get any
warning if I did break something. Unit tests help, but will never
completely avoid this kind of breakage.


Just my 2 cents, not really related to QgsPluginRegistry but with the 
Python/C++ issues you have been describing in this thread.
Please note that I am not familiar with QGIS Python or C++ codebase so 
this might something you are aware of (maybe you are already using it), 
but I have not seen any reference to type hinting in Python (which is 
supported since Python 3.5) in this discussion.
Currently type hints are ignored by the interpreter (Good thing is 
nothing can be broken by annotating types), but there is an additional 
tool mypy that performs static analysis of the code and warns of type 
conflicts, identifying many of those bugs that would only have shown on 
runtime (or unit tests) otherwise.


I do not know how the Python bindings are generated, but if (and I know 
this is a big 'if') we can get type hinting automatically generated from 
the C++ API, and progressively annotate types for the rest of the code 
base, we should be able to catch most if not all of these problems you 
are describing.


Regards,
Javier




___
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] Plugin [2001] Flood Defense approval notification.

[noreply]

Plugin Flood Defense approval by zimbogisgeek.
The plugin version "[2001] Flood Defense 0.6.2 Experimental" is now approved
Link: http://plugins.qgis.org/plugins/fdtm/
___
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 "fast" mode

[Tomas Straupis]

2020-03-16, pr, 10:48 Julien Cabieces rašė:
> This function is only for PostGres (Tomas use an Oracle database if I
> remember correctly).

  Actually I use PostgreSQL more, but this particular performance
problem is with Oracle database.
  And if enough people agree with the principle, I think it could be
possible to remove unnecessary queries from all providers (in time).

> And from what I inderstand from the code, It only prevents from checking
> for unique colomn in a view or materialized view.
>
> However, it looks the good option to deal with this use case, I mean no
> check (geometry type, srid, key column...) as soon as this option is set.

  That would make my patch much more simpler ;-)
  If I understand correctly, I can change my patch to skip geometry
type and srid check when they are saved in project already and when
option "trust project" is switched on?
(https://github.com/qgis/QGIS/pull/34738)

-- 
Tomas
___
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 "fast" mode

[Julien Cabieces]

Hi all,

This function is only for PostGres (Tomas use an Oracle database if I
remember correctly).

And from what I inderstand from the code, It only prevents from checking
for unique colomn in a view or materialized view.

However, it looks the good option to deal with this use case, I mean no
check (geometry type, srid, key column...) as soon as this option is set.

Regards,
Julien

> Hi Tomas.
> Check the project property option named "trust". This is exactly what it is
> supposed to do.
> I admit the wording is not nice, any better idea is welcome.
> Best regards
>
>
> Le sam. 14 mars 2020 à 12:55, Tomas Straupis  a
> écrit :
>
>> Hello
>>
>>   I would like to know opinion of QGIS developer community on the
>> question of "self-fixing queries" in the context of database layers.
>>
>>   When you add a new database layer, QGIS queries required data, asks
>> user for other information and then saves it in the project file.
>>   Now when you re-open the project, QGIS is re-querying a lot of data
>> which is already saved in the project: geometry type, srid, attributes
>> (table columns/types).
>>   The downsides are:
>>   * these "re-checking" queries take considerable time on large
>> databases: with millions of records from 1minute up to several hours,
>> database is tuned - WMS/WFS queries finish in ~100ms.
>>   * in QGIS server environment these re-checking queries are executed
>> each time when apache launches a new QGIS server process
>>   * QGIS might by itself (without human interaction) decide to  work
>> differently compared to what it was asked to do when the project was
>> created if it finds that "something has changed"
>>   * re-checking during project opening is not 100% correct, as if
>> changes are possible in principle, then data/schema could change
>> during the time QGIS (Desktop/Server) is open/running
>>   * in environments other than development (testing, qa, production),
>> database schema should never change without some clear procedure which
>> should also include updating QGIS project files and testing them as
>> required, therefore such re-checkings should never be required on
>> testing/production environments.
>>
>>   I do understand that the current situation/understanding is
>> different from mine, so in order to satisfy everybody, maybe it would
>> be feasible to add say an environment variable like QGIS_FAST=TRUE (or
>> QGIS_PRODUCTION=TRUE) and if this is set - re-checking queries could
>> be skipped? We've been running modified QGIS without re-checking in
>> production for months and are very happy with results. This should
>> also improve the benchmarks of QGIS Server as it is known that initial
>> opening of the project takes considerable amount of time.
>>
>>   What is your opinion?
>>
>>   Thank you
>>
>> --
>> Tomas
>> ___
>> 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] [Processing][Article] Evaluation of Effective Cognition for the QGIS Processing Modeler

[Paolo Cavallini]

Hi João,

Il 16/03/20 00:10, Nyall Dawson ha scritto:

>> Is open access:
>> https://www.mdpi.com/2076-3417/10/4/1446/htm

thanks a lot for the suggestion. I see a number of practical suggestions
here, at least some of them look easy to implement.
Cheers.
-- 
Paolo Cavallini - www.faunalia.eu
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
___
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] Understanding plugin management in QGIS - exposing QgsPluginRegistry to Python?

[Alexander Bruy]

I'm with Nyall here. Once we started moving Processing classes in C++
it became much more stable than pure Python solution (even with tests).

As was said previously Python support is optional and from my point of view
it is much better to port remainings of the Plugin Manager to C++ and leave
only tiny wrapper for loading Python plugins.

пн, 16 бер. 2020 о 01:26 Nyall Dawson  пише:
>
> On Sun, 15 Mar 2020 at 21:50, Sebastian M. Ernst  
> wrote:
> >
> > Hi Borys, Nyall, Matthias,
> >
> > thanks all for your replies! Let me address some of the points/concerns
> > raised.
> >
> > > Actually, over time we've found that the opposite is true -- the
> > > Python code in QGIS master is the **most** work to maintain, and a
> > > constant source of regressions. That's due to the nature of the Python
> > > language itself, not a reflection of the quality of the code...
> >
> > Nyall, could you point me to some specific regressions that you are
> > referring to? Bugs or their IDs (so I can look them up)? When you say
> > "nature of the Python language", which specific aspects are you
> > referring to? I know there is a lot that one can legitimately criticize
> > about the language, but again I'd be highly interested in what
> > specifically is causing you headaches.
>
> The issues we see most often stem not from any particular use of
> Python, but (as Matthias has pointed out) through the nature of
> Pythons weak typing and lack of compile time checks. A simple example:
> if I alter the signature of a virtual method in one of the c++ classes
> to add an extra argument or change a return type, I'll know right away
> (well, when I next compile) if I've broken some existing code. If I do
> the same in Python, I'm basically trusting that my particular IDE can
> correctly identify ALL use of that method, because I won't get any
> warning if I did break something. Unit tests help, but will never
> completely avoid this kind of breakage.
>
> And we see this happen ALL. THE. TIME. in QGIS Python code. Processing
> (through NO fault of the maintainers) was a frequent source of
> breakage in QGIS 2.x, and it was only by porting the guts of it away
> from Python and to c++ that we could finally get things stable. Now
> it's happening all the time in dbmanager -- I don't think there's been
> a single recent QGIS release which hasn't had some form of regression
> in db manager. And again, I blame that on the nature of Python, not on
> the existing code or maintainers.
>
> Another HUGE factor with Python+QGIS is that the actual methods of
> creating the Python bindings + the PyQt library itself is a mysterious
> black box, full of weird inconsistencies, random results, memory
> mismanagement and crashy code practices. I shudder to think of the
> amount of time I've wasted fighting with SIP and its unpredictable
> behavior. You could write the BEST Python code the world has ever
> seen, using all the Python best practice coding techniques you want,
> and you'll still hit random regressions and issues due to these
> libraries. QGIS c++ code is just MUCH more predictable, transparent,
> and easier to debug.
>
> >> That's due to the nature of the Python
> > > language itself, not a reflection of the quality of the code...
> > Reading the code of the Python (environment) integration, I can see that
> > it is prone to all sorts of issues - but I'd be interested in your
> > experience in what actually causes problems the most.
>
> My point wasn't a comment of the quality of the Python code either
> way. Rather, my point was that **regardless** of the quality of the
> Python code, you'll still end up with a difficult to maintain, fragile
> result!
>
> > > That would be my preference too -- the overall movement in QGIS code
> > > is to reduce the overall amount of Python code in master, not the
> > > reverse.
> >
> > I can understand where you are coming from, however please allow me to
> > suggest the following: I would like to do what I already hinted on, i.e.
> > unify most plugin management code into a common, modern Python code base
> > with tests etc.
>
> This work sounds fantastic, and highly valuable to QGIS. It's GREAT to
> hear that you want to investigate this!!
>
> But please please please can I ask you to seriously reconsider your
> approach? I've been working on this project for nearly 10 years now,
> and my experience time and time again is that large blocks of Python
> code in QGIS end up unstable. Modern c++ + qt is really not that much
> trickier to write then Python, and if you include good test coverage,
> then the code becomes almost self-maintaining*.
>
> Python is a GREAT choice for QGIS scripts and addons, but I just don't
> think it's a suitable choice here.
>
> Nyall
>
> * at least, until a major qt release deprecates stuff you rely on! :P
>
>
>
> I would like to show how this could look like. You do
> > not have to accept it or merge it. After all, I would probably have to
> > write an enhancement proposal 

Re: [QGIS-Developer] Understanding plugin management in QGIS - exposing QgsPluginRegistry to Python?

[Paolo Cavallini]

Hi Sebastian,
thanks for your thoughts.

Il 15/03/20 22:31, Sebastian M. Ernst ha scritto:
> 
> Well, the bottom line is more efficiently tapping into pypi and conda
> packages. QGIS / OSGeo4W pretty much acts as a rather limited Python
> distribution. It's missing a lot of interesting scientific packages that
> currently see rapid development. Their distribution as part of QGIS /
> OSGeo4W would probably go much beyond the scope and resources of the
> QGIS project. If, on the other hand, QGIS was "simply" yet another
> C++-heavy Python package within a larger ecosystem, let's say Anaconda,
> this would add an interesting new perspective. I have been chasing the
> idea that QGIS plugins (more specifically their meta data) are lacking a
> lot of features of Python wheels or Conda packages. They really can not
> carry dependencies (other than dependencies to other plugins, added in
> QGIS 3.6 I believe). It's actually officially recommended to make Python
> dependencies part of QGIS plugins' distribution files (c & p), which can
> be a no-go for a number of good reasons. If you imagine that QGIS
> plugins are instead (or additionally) distributed as conda packages
> (with all of conda's package management features) while the entire thing
> remains manageable through a simple GUI, the QGIS plugin manager, I can
> see some interesting new use-cases and possibilities (especially for
> non-technical and Windows users). This is more or less the gist of my
> thinking.

having a proper way of managing plugin dependencies would be a huge
improvement, as this is one of the weakest points of our plugin management.
Cheers.
-- 
Paolo Cavallini - www.faunalia.eu
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
___
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] Requirements for new contributors

[Paolo Cavallini]

Thank you Morten, welcome on board!
Cheers.

Il 15/03/20 20:48, Morten Sickel ha scritto:
>  
> 
> I hereby confirm,
> 
>  
> 
> I have read, understood and agree to the code of conduct, the coding
> standard and the diversety statements as described on
> https://qgis.org/en/site/getinvolved/development/contributor_requirements.html
> 
>  
> 
> Morten Sickel
> 
> mor...@sickel.net 
> 
>  
> 
> I hope to be able to participate a bit on the python side – I have had
> some problems with the db manager. I am going to do a bit more
> investigation to write a bug report, but I think I have an idea how to
> fix the problem.
> 
>  
> 
> Morten
> 
> 
> ___
> 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
> 

-- 
Paolo Cavallini - www.faunalia.eu
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
___
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