Re: [QGIS-Developer] Common PyQGIS functions for QGIS 3

[Richard Duivenvoorde]

On 21/02/2019 15.22, Tom Chadwin wrote:
> Nyall Dawson wrote
>>> I agree. Even if the PyQGIS-Documentation is now much better than in the
>>> past for me often some short examples like the ones from Thomas Gratier
>>> are really helpful to know how to proceed:
>>> https://webgeodatavore.github.io/pyqgis-samples/
>>
>> I'd love to see discussion on how we can merge this awesome resource
>> into the new PyQGIS documentation. Together they'd make an awesome
>> resource!
> 
> Matteo has raised this on the commuity list:
> https://lists.osgeo.org/pipermail/qgis-community-team/2019-January/005222.html

Looks great!

One thing we could (but I'm not sure if we still should) is to be able
to translate it in transifex. The sphinx-based cookbook was in the
process, so could be translated.

I really like Thomas examples and clean view (though it says 'published
with gitbook' which seems not free?).

Even better (which is also discussed here earlier) is (ideally) a text
in rst (editable in github, and translatable on transifex (or alike),
with included(!) codesamples which could be build/tested on CI (so the
examples keep in line with QGIS main code).

Regards,

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

Re: [QGIS-Developer] Common PyQGIS functions for QGIS 3

[Tom Chadwin]

Nyall Dawson wrote
>> I agree. Even if the PyQGIS-Documentation is now much better than in the
>> past for me often some short examples like the ones from Thomas Gratier
>> are really helpful to know how to proceed:
>> https://webgeodatavore.github.io/pyqgis-samples/
> 
> I'd love to see discussion on how we can merge this awesome resource
> into the new PyQGIS documentation. Together they'd make an awesome
> resource!

Matteo has raised this on the commuity list:
https://lists.osgeo.org/pipermail/qgis-community-team/2019-January/005222.html

Tom



-
Buy Pie Spy: Adventures in British pastry 2010-11 on Amazon 
--
Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html
___
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] Common PyQGIS functions for QGIS 3

[Nyall Dawson]

On Thu, 21 Feb 2019 at 00:51, Thomas Baumann  wrote:
>
> Hi Nyall,
>
> thanks for your feedback.
> You are right that some of my examples were not ideal to explain what I 
> meant, so I try to explain it a bit better this time ;-)

Thanks - it's much appreciated!

> create a vectorlayer
>
> Something like:
>
> https://gist.github.com/rdbath/bbba7640cf98ab09dc9bb6018011f05e#file-pyqgis_common_functions_examples-py-L24

Ah, that one IS a source of pain. QGIS 3.0 makes it easier with

   new_empty_memory_layer = QgsMemoryDataProvider.createMemoryLayer( ... )

   and

   new_memory_layer_with_copy_of_features = source_layer.materialize(
QgsFeatureRequest().setFilterExpression( ... ) )

You'd still need to follow these up with a call to QgsVectorFileWriter
to save as a disk based format.

There's some trickiness here because with some disk formats it's not
possible to create an empty layer upfront -- e.g. geojson. You have to
have some features ready to initially populate that layer with at time
of creation.

I'd be interested to hear any ideas for "ultimate wishlist" api here?

> Example2: For loading layer I meant something like
>
> https://gist.github.com/rdbath/bbba7640cf98ab09dc9bb6018011f05e#file-pyqgis_common_functions_examples-py-L7:
...

This approach is somewhat of a hack, which is why I wouldn't like to
see it as part of any "officially supported" python library. Really,
API for doing this belongs in core QGIS API itself (covered by
appropriate documentation + unit tests, of course!)

> Example3: Iterate through layers:
...
> So if there would be a pyqgis-commons library where I would know that I just 
> have to call a function "get_visible_layers" instead of  using [l.layer() for 
> l in
> QgsProject.instance().layerTreeRoot().findLayers() if l.isVisible()]  I 
> probably could use this in my next plugin without having to search/google how 
> to do this.

Right - but again, this doesn't belong in a Python specific library.
What we need here is a core API addition "visibleLayers":

visible_layers = QgsProject.instance().layerTreeRoot().visibleLayers()

> Example4: show messages / log messages:

> One other example would be the function "display_warning_message_bar" from 
> the inasafe-utilities where I can show a short message and also provide a 
> button to show more details about a warning:
> https://github.com/inasafe/inasafe/blob/bd00bfeac510722b427544b186bfa10861749e51/safe/utilities/qgis_utilities.py#L132

Once again, I think this could easily be in the c++ API, so that both
Python and c++ code could take advantage of it. I don't see anything
Python-specific here.

>  Example5: Settings:

> Here I hat something in mind like the qgis-settingsmanager of opengis ( 
> https://github.com/opengisch/qgissettingmanager ).
> I know it is not only a collection of python-/pyqt-functions but a whole 
> python module but I still it is an example of how functionalities are 
> provided to make the development of plugins easier.

Yes, that one *is* nice. I think Denis originally intended that to be
made available in the default PyQGIS library, but I suspect just ran
out of time.

> So it is always about providing some helper functions that I could also write 
> by myself but which will save time during development and can help me to do 
> the things in a consistent way in all of my plugins.

Right, but I think it's very important to differentiate here between:

1. API additions which are useful in all contexts (c++ and Python)
2. Python specific API additions, which make use of Python only
functionality like decorators, exceptions, and context managers


>
>
>>
>> I'm not saying we can't improve the PyQGIS experience, but I don't
>> personally see these as good candidates.
>>
>> I think we have a LOT of work to do with things like:
>> - throwing proper exceptions instead of crashing/returning "None"
>> values/returning "invalid" objects (e.g. QgsGeometry.fromWkt should
>> ideally raise an exception for invalid wkt instead of returning a null
>> geometry)
>> - providing Python-esque things like __repr__ methods, __len__, []
>> operators (which behave in a python style, e.g. with -1 returning the
>> last item), iterators, etc
>> - providing more "context managers" (e.g. with  : #something )
>
>
> I don't have such a deep insight in the QGIS-codebase but I guess this would 
> probably have to be done in the C++-part of QGIS, wouldn't it?

Sometimes, or sometimes it's done like this:
https://github.com/qgis/QGIS/blob/master/python/core/__init__.py.in

> I agree. Even if the PyQGIS-Documentation is now much better than in the past 
> for me often some short examples like the ones from Thomas Gratier are really 
> helpful to know how to proceed:
> https://webgeodatavore.github.io/pyqgis-samples/

I'd love to see discussion on how we can merge this awesome resource
into the new PyQGIS documentation. Together they'd make an awesome
resource!

Nyall



>
> So I see three ideas here:
>
> - provide a collection o

Re: [QGIS-Developer] Common PyQGIS functions for QGIS 3

[Thomas Baumann]

Hi Nyall,

thanks for your feedback.
You are right that some of my examples were not ideal to explain what I
meant, so I try to explain it a bit better this time ;-)

Some of the following pyqgis-examples may be outdated as things can be done
easier in qgis3 now but they should just be an example
for some functions that were written by users to make life easier during
the development of QGIS plugins.


Example1: QgsVectorlayer:

Am Mi., 20. Feb. 2019 um 10:29 Uhr schrieb Nyall Dawson <
nyall.daw...@gmail.com>:

>
> This is a single line via the existing API :
>
> vl = QgsVectorLayer( '/home/me/my.shp' , 'my_layer' )
>
> I'm curious to hear how this could be improved?
>

I wrote "load a vectorlayer" but meant "create a vectorlayer"

Something like:

https://gist.github.com/rdbath/bbba7640cf98ab09dc9bb6018011f05e#file-pyqgis_common_functions_examples-py-L24


Example2: For loading layer I meant something like

https://gist.github.com/rdbath/bbba7640cf98ab09dc9bb6018011f05e#file-pyqgis_common_functions_examples-py-L7
:


def load_layer(filename, name = None):
'''
Tries to load a layer from the given file
:param filename: the path to the file to load.
:param name: the name to use for adding the layer to the current project.
If not passed or None, it will use the filename basename
'''
name = name or os.path.splitext(os.path.basename(filename))[0]
qgslayer = QgsVectorLayer(filename, name, 'ogr')
if not qgslayer.isValid():
qgslayer = QgsRasterLayer(filename, name)
if not qgslayer.isValid():
raise RuntimeError('Could not load layer: ' + unicode(filename))

return qgslayer

-

Example3: Iterate through layers:


> # all layers
> layers = [l.layer() for l in
> QgsProject.instance().layerTreeRoot().findLayers()]
>


> # visible layers
> visible_layers = [l.layer() for l in
> QgsProject.instance().layerTreeRoot().findLayers() if l.isVisible()]
>
> Ok, not super-obvious in this case, but still quite concise ;)
>

For the example of  visible_layers = [l.layer() for l in
QgsProject.instance().layerTreeRoot().findLayers() if l.isVisible()]  :
I would probably have needed some minutes to search in one of my plugins if
I have used such a code snippet before or google gis.stackexchange ;-)
Probably I also wouldn't have written such a fancy nice one-liner to get
these layers.

So if there would be a pyqgis-commons library where I would know that I
just have to call a function "get_visible_layers" instead of  using
[l.layer() for l in
QgsProject.instance().layerTreeRoot().findLayers() if l.isVisible()]  I
probably could use this in my next plugin without having to search/google
how to do this.


Example4: show messages / log messages:

>
> > - show a message with different levels (info, warning, critical)
>
> iface.messageBar().pushWarning('blah','some message')
> iface.messageBar().pushInfo('blah','some message')
> iface.messageBar().pushCritical('blah','some message')
>
> > - log messages
> QgsMessageLog.logMessage('my plugin','something', Qgis.Critical)



I had something in mind like the MessageManager of Germán Carrillo:

https://github.com/gacarrillor/AutoFields/blob/master/MessageManager.py

I like the MessageManager because I can easily switch between the
message-modes 'production' or 'debug.

One other example would be the function "display_warning_message_bar" from
the inasafe-utilities where I can show a short message and also provide a
button to show more details about a warning:
https://github.com/inasafe/inasafe/blob/bd00bfeac510722b427544b186bfa10861749e51/safe/utilities/qgis_utilities.py#L132



 Example5: Settings:

>
> > - reading setting, writing settings
>
> The QgsSettings class should make this straightforward
>

Here I hat something in mind like the qgis-settingsmanager of opengis (
https://github.com/opengisch/qgissettingmanager ).
I know it is not only a collection of python-/pyqt-functions but a whole
python module but I still it is an example of how functionalities are
provided to make the development of plugins easier.


So it is always about providing some helper functions that I could also
write by myself but which will save time during development and can help me
to do the things in a consistent way in all of my plugins.



> I'm not saying we can't improve the PyQGIS experience, but I don't
> personally see these as good candidates.
>
> I think we have a LOT of work to do with things like:
> - throwing proper exceptions instead of crashing/returning "None"
> values/returning "invalid" objects (e.g. QgsGeometry.fromWkt should
> ideally raise an exception for invalid wkt instead of returning a null
> geometry)
> - providing Python-esque things like __repr__ methods, __len__, []
> operators (which behave in a python style, e.g. with -1 returning the
> last item), iterators, etc
> - providing more "context managers" (e.g. with  : #something )
>

I don't have such a deep insight in the QGIS-codebase but I guess this
would probably have to be done in the C++-part of QGIS, wouldn't it?


 (

Re: [QGIS-Developer] Common PyQGIS functions for QGIS 3

[Nyall Dawson]

On Wed, 20 Feb 2019 at 18:38, Thomas Baumann  wrote:
>
> Hi qgis-devs,
>
> I recently updated 15 QGIS-plugins to be QGIS3-ready. Most of them were self 
> written (in house) plugins but four of them were also plugins from the 
> official repository which were written by someone else.
>
> I noticed that there are severals tasks that have many plugins in common like:
> - load a vectorlayer

This is a single line via the existing API :

vl = QgsVectorLayer( '/home/me/my.shp' , 'my_layer' )

I'm curious to hear how this could be improved?

> - add a layer to the layertree
> - iterate through all (visible?) layers of the layertree

# all layers
layers = [l.layer() for l in QgsProject.instance().layerTreeRoot().findLayers()]
# visible layers
visible_layers = [l.layer() for l in
QgsProject.instance().layerTreeRoot().findLayers() if l.isVisible()]

Ok, not super-obvious in this case, but still quite concise ;)

> - show a message with different levels (info, warning, critical)

iface.messageBar().pushWarning('blah','some message')
iface.messageBar().pushInfo('blah','some message')
iface.messageBar().pushCritical('blah','some message')

> - log messages
QgsMessageLog.logMessage('my plugin','something', Qgis.Critical)

> - reading setting, writing settings

The QgsSettings class should make this straightforward

I'm not saying we can't improve the PyQGIS experience, but I don't
personally see these as good candidates.

I think we have a LOT of work to do with things like:
- throwing proper exceptions instead of crashing/returning "None"
values/returning "invalid" objects (e.g. QgsGeometry.fromWkt should
ideally raise an exception for invalid wkt instead of returning a null
geometry)
- providing Python-esque things like __repr__ methods, __len__, []
operators (which behave in a python style, e.g. with -1 returning the
last item), iterators, etc
- providing more "context managers" (e.g. with  : #something )

(Definitely don't take this as a "don't proceed"... there is a VERY
STRONG need to improve the PyQGIS API/Documentation/examples, and this
would be very valuable work!)

Nyall

>
>
>
> Wouldn't it be possible to provide such a collection not only from privat 
> persons/projects but from the QGIS-project itself so users could add common 
> functions?
> I think the chances would be higher that such a "official" collection would 
> be used in the long run and constantly extended.
>
> Apart from the fact that developers could save time while writing their 
> plugins this could perhaps also help to improve the overall quality of the 
> qgis-plugins as there would probably be several persons who could/would 
> countercheck these common functions to make sure they are well written.
>
> regards,
> Thomas
>
> PS: I asked something similar also on gis.stackexchange recently:
>
> https://gis.stackexchange.com/questions/311755/looking-for-common-pyqgis-functions-for-qgis-3
>
>
>
>
> ___
> 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] Common PyQGIS functions for QGIS 3

[Matthias Kuhn]

Hi Thomas,

Recently more and more is added to QGIS in the `qgis.utils` module, for 
example the latest addition is the `@alg` decorator for processing 
algorithms [1].


I really like these efforts and more additions are very welcome!

From a workflow perspective, it's good to come up with a QEP or a 
thread on the mailing list first. Very often those snippets overcome 
shortcomings of the QGIS API which should rather be fixed on C++ side.


Bests

Matthias

[1] https://github.com/qgis/QGIS-Enhancement-Proposals/issues/134

On 20.02.19 09:38, Thomas Baumann wrote:

Hi qgis-devs,

I recently updated 15 QGIS-plugins to be QGIS3-ready. Most of them 
were self written (in house) plugins but four of them were also 
plugins from the official repository which were written by someone else.


I noticed that there are severals tasks that have many plugins in 
common like:

- load a vectorlayer
- add a layer to the layertree
- iterate through all (visible?) layers of the layertree
- show a message with different levels (info, warning, critical)
- log messages
- reading setting, writing settings
- ...

It seems a bit ineffective that every developer writes these common 
task 'from scratch'.


There already were some ideas to collect common functions that could 
be re-used by plugin-developers:


-some older functions (GIS2) like

https://github.com/NathanW2/parfait

https://github.com/qgis/pyqgis_wrappers

and something newer like

https://github.com/boundlessgeo/lib-qgis-commons 
https://pypi.org/project/qgiscommons/



One nice example for utilities collected for a (huge) plugin is:

https://github.com/inasafe/inasafe/tree/master/safe/utilities



Wouldn't it be possible to provide such a collection not only from 
privat persons/projects but from the QGIS-project itself so users 
could add common functions?
I think the chances would be higher that such a "official" collection 
would be used in the long run and constantly extended.


Apart from the fact that developers could save time while writing 
their plugins this could perhaps also help to improve the overall 
quality of the qgis-plugins as there would probably be several persons 
who could/would countercheck these common functions to make sure they 
are well written.


regards,
Thomas

PS: I asked something similar also on gis.stackexchange recently:

https://gis.stackexchange.com/questions/311755/looking-for-common-pyqgis-functions-for-qgis-3 







___
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] Common PyQGIS functions for QGIS 3

[Thomas Baumann]

Hi qgis-devs,

I recently updated 15 QGIS-plugins to be QGIS3-ready. Most of them were
self written (in house) plugins but four of them were also plugins from the
official repository which were written by someone else.

I noticed that there are severals tasks that have many plugins in common
like:
- load a vectorlayer
- add a layer to the layertree
- iterate through all (visible?) layers of the layertree
- show a message with different levels (info, warning, critical)
- log messages
- reading setting, writing settings
- ...

It seems a bit ineffective that every developer writes these common task
'from scratch'.

There already were some ideas to collect common functions that could be
re-used by plugin-developers:

-some older functions (GIS2) like

https://github.com/NathanW2/parfait

https://github.com/qgis/pyqgis_wrappers

and something newer like

https://github.com/boundlessgeo/lib-qgis-commons
https://pypi.org/project/qgiscommons/


One nice example for utilities collected for a (huge) plugin is:

https://github.com/inasafe/inasafe/tree/master/safe/utilities


Wouldn't it be possible to provide such a collection not only from privat
persons/projects but from the QGIS-project itself so users could add common
functions?
I think the chances would be higher that such a "official" collection would
be used in the long run and constantly extended.

Apart from the fact that developers could save time while writing their
plugins this could perhaps also help to improve the overall quality of the
qgis-plugins as there would probably be several persons who could/would
countercheck these common functions to make sure they are well written.

regards,
Thomas

PS: I asked something similar also on gis.stackexchange recently:

https://gis.stackexchange.com/questions/311755/looking-for-common-pyqgis-functions-for-qgis-3
___
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