[QGIS-Developer] Plugin [1193] Shape Tools approval notification.

2017-09-15 Thread noreply
Plugin Shape Tools approval by pcav. The plugin version "[1193] Shape Tools 0.5" is now approved Link: http://plugins.qgis.org/plugins/shapetools/ ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/l

Re: [QGIS-Developer] Inconsistency between Query builder and Select by query dialogs

2017-09-15 Thread Andreas Neumann
Hi Paolo, I asked the same question, but apparently there are technical reasons. The Query builder creates a query that a data source can understand (e.g. OGR) - data is filtered at its source. Whereas the expression builder is much, much richer and can't be translated to filters of data pro

[QGIS-Developer] Inconsistency between Query builder and Select by query dialogs

2017-09-15 Thread Paolo Cavallini
Hi all, the two dialogs are quite different, whereas they do essentialy the same thing. Questions: * is there a specific reason why the Query builder has not been updated, or is it just the usual lack of time? * is anyone planning to work on this? Thanks. -- Paolo Cavallini - www.faunalia.eu QGIS

[QGIS-Developer] Problems with SpatiaLite and DB Manager

2017-09-15 Thread matteo
Hi guys, I'm facing some issues with a SpatiaLite DB and the DB Manager. I create as usual the connection with QGIS, open DB Manager, I can expand the list of SpatiaLite databases but when click on the single database QGIS crashes (not very explicative): QGIS died on signal 11Could not attach to

Re: [QGIS-Developer] FeatureIterator Python question

2017-09-15 Thread David Marteau
Sorry, it has already been aswered, did not see the threads. > Le 15 sept. 2017 à 16:46, David Marteau a écrit : > > Hi > > If FeatureIterator is a true iterator then use: > > feature = next(FeatureIterator) > > >> Le 15 sept. 2017 à 14:43, Andreas Neumann > > a

Re: [QGIS-Developer] FeatureIterator Python question

2017-09-15 Thread David Marteau
Hi If FeatureIterator is a true iterator then use: feature = next(FeatureIterator) > Le 15 sept. 2017 à 14:43, Andreas Neumann a écrit : > > Hi, > > While porting a project from QGIS 2x to 3x I came across a Python issue: > > In QGIS 2.x I had a code like below working: > > feature = Feat

Re: [QGIS-Developer] FeatureIterator Python question

2017-09-15 Thread Andreas Neumann
Thanks Matthias for explaining about that. Good to know. Andreas On 15.09.2017 16:22, Matthias Kuhn wrote: Hi Andreas, that will be done automatically when the iterator scopes out or the last feature is yielded. There is normally no reason to care about this method. Matthias On 09/15/2017 0

Re: [QGIS-Developer] FeatureIterator Python question

2017-09-15 Thread Matthias Kuhn
Hi Andreas, that will be done automatically when the iterator scopes out or the last feature is yielded. There is normally no reason to care about this method. Matthias On 09/15/2017 04:04 PM, Andreas Neumann wrote: > Just a quick followup question. > > I see that the QgsFeatureIterator has a c

Re: [QGIS-Developer] FeatureIterator Python question

2017-09-15 Thread Matthias Kuhn
I was also thinking about that. I would just miss this method because it's used so often and the alternative approaches just require more typing. +1 for this On 09/15/2017 03:53 PM, Nathan Woodrow wrote: > I think we could just implement out own next method to avoid that break > would be easy eno

Re: [QGIS-Developer] FeatureIterator Python question

2017-09-15 Thread Andreas Neumann
Just a quick followup question. I see that the QgsFeatureIterator has a close method. Should Python authors care about closing an existing feature iterator or would this be automatically done when the script stops executing? Andreas On 15.09.2017 15:48, Andreas Neumann wrote: Hi Matteo and

Re: [QGIS-Developer] FeatureIterator Python question

2017-09-15 Thread Nathan Woodrow
I think we could just implement out own next method to avoid that break would be easy enough. On Fri, Sep 15, 2017 at 11:48 PM, Andreas Neumann wrote: > Hi Matteo and Matthias, > > Thanks - that works fine. I did not know that this changed in Python 3. > > All the poor QGIS book authors who need

Re: [QGIS-Developer] FeatureIterator Python question

2017-09-15 Thread Andreas Neumann
Hi Matteo and Matthias, Thanks - that works fine. I did not know that this changed in Python 3. All the poor QGIS book authors who need to rewrite their books ... about this Python changes. Helps a lot! Andreas On 15.09.2017 15:44, matteo wrote: Hi Andreas, if I'm not wrong the next met

Re: [QGIS-Developer] FeatureIterator Python question

2017-09-15 Thread Matthias Kuhn
I quickly googled for the reason for this PEP 3114 (https://www.python.org/dev/peps/pep-3114/) So next() was renamed to __next__() for consistency, because it's a builtin method. iterator.__next__() or next(iterator) should yield the same item. Matthias On 09/15/2017 03:44 PM, matteo wrote: >

Re: [QGIS-Developer] FeatureIterator Python question

2017-09-15 Thread matteo
Hi Andreas, if I'm not wrong the next method is not been removed, it is a python 3 *fix* https://stackoverflow.com/questions/1073396/is-generator-next-visible-in-python-3-0 so instead of: it = layer.getFeatures() it.next() just type it = layer.getFeatures() next(it) Matteo __

Re: [QGIS-Developer] FeatureIterator Python question

2017-09-15 Thread Matthias Kuhn
Hi Andreas, that hasn't been a QGIS decision but a python3 one. next(featureIterator) is the way proposed for python3. I am not sure about the reasons for this change though. Matthias On 09/15/2017 03:40 PM, Andreas Neumann wrote: > Hi, > > Found out that I can access my first feature like: >

Re: [QGIS-Developer] FeatureIterator Python question

2017-09-15 Thread Andreas Neumann
Hi, Found out that I can access my first feature like: feature = list(FeatureIterator)[0] but not sure if this is recommended and efficient. Why was the next() method of the feature iterator removed in QGIS 3? Is there a particular reason for that? Thanks, Andreas On 15.09.2017 14:43, An

Re: [QGIS-Developer] Problem with atlas rule-based styling

2017-09-15 Thread Andreas Neumann
Sounds like a good proposal, Tom! Thanks, Andreas On 15.09.2017 14:40, Tom Chadwin wrote: What value does @atlas_featureid have if the composer/atlas has never been opened - in this session/in this project's lifetime? If null/none/similar, is resetting @atlas_featureid to that value on compos

[QGIS-Developer] FeatureIterator Python question

2017-09-15 Thread Andreas Neumann
Hi, While porting a project from QGIS 2x to 3x I came across a Python issue: In QGIS 2.x I had a code like below working: feature = FeatureIterator.next() In QGIS 3x it says that object has no attribut next. How do I access the first result of a feature iterator in QGIS 3? I don't want to lo

Re: [QGIS-Developer] Problem with atlas rule-based styling

2017-09-15 Thread Tom Chadwin
What value does @atlas_featureid have if the composer/atlas has never been opened - in this session/in this project's lifetime? If null/none/similar, is resetting @atlas_featureid to that value on composer/atlas close the best proposal? Tom - Buy Pie Spy: Adventures in British pastry 2010-1

Re: [QGIS-Developer] Problem with atlas rule-based styling

2017-09-15 Thread Andreas Neumann
Hi Nyall, Fair enough - for some use cases. Still I don't like that there is no way of correctly exiting "Atlas printing mode" in the main canvas. If print composer is closed, the symbology is still influenced by Atlas. Not so nice. I think a user would expect that if Atlas is not active anym

Re: [QGIS-Developer] Problem with atlas rule-based styling

2017-09-15 Thread Nyall Dawson
On 15 September 2017 at 18:30, Andreas Neumann wrote: > Answering myself: > > by adding in the @map_id variable into the rule I can avoid that the main > map canvas gets changed. My particular problem is thus solved. > > But the question remains: why is the Atlas printing feature changing the > ma

Re: [QGIS-Developer] Problem with atlas rule-based styling

2017-09-15 Thread Andreas Neumann
Answering myself: by adding in the @map_id variable into the rule I can avoid that the main map canvas gets changed. My particular problem is thus solved. But the question remains: why is the Atlas printing feature changing the main map canvas at all? Anything done in the print composer shoul