Re: [Qgis-developer] [Python] QgsFeatureIterator for geometryless PostgreSQL-Layer
Hi On 12.04.2013 09:51, Martin Dobias wrote: > On Fri, Apr 12, 2013 at 9:25 AM, Jürgen E. wrote: >> Hi Martin, >> >> On Thu, 11. Apr 2013 at 22:30:57 +0200, Martin Dobias wrote: >>> I have a feeling that we should call that a bug: the NoGeometry flag >>> tells that it is not necessary to fetch geometry... so even if the >>> flag is not set, the feature should be fetched. >> Ok, then it's also misleading. Should we rename NoGeometry to WithoutGeometry >> while we still can? > Yes, we could do that. Or maybe IgnoreGeometry? > I stumbled over this again. So I decided to fix this. [1] This pull request changes the meaning of QgsFeatureRequest::NoGeometry. Or maybe I should rather say it defines it and unifies behavior. It seems, that this was handled differently by different providers. E.g. OGR provider was returning features of a geometry-less layer regardless of this flag, while postgres and spatialite providers spat an error to the message log and didn't return any features. New behavior is: The geometry is not required to satisfy the request. It may still be returned if e.g. required for a filter condition. Are there any objections to this? My main point in the change is to be able to query any layer (regardless if it has a geometry or not) with a default constructed feature request and get all rows. Do we need a new flag RequiresGeometry? Can't just the layers/providers geometry type easily be checked for NoGeometry instead? And would a RequiresGeometry flag not rather have to be applied on a feature basis (only return features whose geometry is not NULL) Kind regards, Matthias [1] https://github.com/qgis/QGIS/pull/918 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Python] QgsFeatureIterator for geometryless PostgreSQL-Layer
Hi Martin,
On Wed, 24. Apr 2013 at 00:21:53 +0200, Martin Dobias wrote:
> > Which only moves the problem upward. Maybe we should handle setFilterFid
> > requests like the old featureAtId.
> Could you be more specific what would that mean implementation-wise?
Handling the setFilterFid requests so that they don't interfere with other
iterators - thereby reviving any code that implied that featureAtId is possible
while select()/nextFeature() is ongoing.
> Right, I thought it was the same cursor, but in fact they were called
> differently ("qgisf[N]" vs "qgisfid[N]"). But still with OGR there is
> not guarantee that it will work - if the driver does not implement
> random access to features. Not sure about other providers...
But judging by the lack of tickets that complain about this, I suppose with
frequently used OGR drivers it worked.
> I would like to address multiple iterators in the 2.1 release together with
> threaded rendering.
That's what I thought - ie. the closing of active iterators is a temporary
kludge. But I didn't think that we would release 2.0 with that (at least not
after I found that this was introducing regressions).
> Right now it seems that all those problems lead to the handling of changed
> geometries within vector layer's feature iterator
> (fetchNextChangedGeomFeature()). We could update that code to first finish
> iterating over features from data provider and only after that fetch
> remaining features (by ID) with changed geometries that have not been
> considered before (in the main loop) - at that time the internal provider's
> iterator will be closed already, so there will be no collision.
> Does that sound good to you?
Not really - sorry ;)
To me it sounds like extending the kludge. And identifying the affected code
is probably not that easy either - I suppose just a few were tagged with
tickets yet.
> This change should also lower the amount of queries to the provider: if the
> feature with changed geometry is still in the filter rectangle, no
> superfluous "feature at id" queries will be issued.
Some of the code (eg. some stuff in fTools) probably should be reworked anyway.
The question is who has enough time to work on any of this...
Jürgen
--
Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31
Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50
Software Engineer D-26506 Norden http://www.norbit.de
committ(ed|ing) to Quantum GIS IRC: jef on FreeNode
--
norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
Rheinstrasse 13, 26506 Norden
GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Python] QgsFeatureIterator for geometryless PostgreSQL-Layer
On Tue, Apr 23, 2013 at 11:38 AM, Jürgen E. wrote:
> Hi Martin,
>
> On Tue, 16. Apr 2013 at 09:32:08 +0200, Martin Dobias wrote:
>> > IMHO that's not ok. If the provider doesn't support multiple iterators,
>> > the second on should be rejected - forcing the caller to close the other
>> > one first.
>
>> You're right - when thinking about it again, it makes more sense to reject
>> new iterator rather than close the previous one with force. It should be
>> relatively simple to swap the behavior.
>
> Which only moves the problem upward. Maybe we should handle setFilterFid
> requests like the old featureAtId.
Could you be more specific what would that mean implementation-wise?
>> > As we lost the ability to do featureAtId while iterating a layer, we now
>> > have a couple of places, where stuff behaves strange and it's not really
>> > obvious that it's causes by a setFilterFid request killing a surrounding
>> > iteration.
>
>> In the other thread (about updateFeature()) I have noted that we actually
>> never really supported featureAtId while iterating a layer - at least not in
>> all providers... AFAIK postgis always used only one cursor. With OGR provider
>> that could work - but maybe just for some drivers (e.g. shapefile). If I have
>> time I will try to do few tests how qgis 1.8 behaved.
>
> I think the postgres provider had a separate (very short lived) cursor for
> featureAtId.
Right, I thought it was the same cursor, but in fact they were called
differently ("qgisf[N]" vs "qgisfid[N]"). But still with OGR there is
not guarantee that it will work - if the driver does not implement
random access to features. Not sure about other providers...
>> > Rejecting it wouldn't cure that, but at least make is show (ok, that's what
>> > the error message does also do that now). And unless we get the parallel
>> > setFilterFid request back, we'll need to identify and rewrite the looping
>> > code.
>
>> When porting the code to new API, were there really loops that combined
>> nextFeature() with featureAtId() ?
>
> Apparently. But my porting was more an semi-automatic effort - so didn't
> really look closely at all the code. And I wasn't aware that multiple
> iterators were a problem - I thought that was kind of the point of the new
> api.
> ;)
The point of the new API was to get a common flexible interface.
Multiple iterators are currently a problem mainly because previously
the providers were not designed to work that way. There was just the
implicit assumption that it's possible to use nextFeature() and
featureAtId() at the same time - although likely not working in all
cases. I would like to address multiple iterators in the 2.1 release
together with threaded rendering.
> But we have a few tickets for that. Eg. http://hub.qgis.org/issues/7472. I
> tried to link others related tickets there. There are probably more. The
> submitters usually are not aware, that the problems are related.
Thanks for gathering the related tickets into one place. Right now it
seems that all those problems lead to the handling of changed
geometries within vector layer's feature iterator
(fetchNextChangedGeomFeature()). We could update that code to first
finish iterating over features from data provider and only after that
fetch remaining features (by ID) with changed geometries that have not
been considered before (in the main loop) - at that time the internal
provider's iterator will be closed already, so there will be no
collision. This change should also lower the amount of queries to the
provider: if the feature with changed geometry is still in the filter
rectangle, no superfluous "feature at id" queries will be issued.
Does that sound good to you?
Regards
Martin
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Python] QgsFeatureIterator for geometryless PostgreSQL-Layer
Hi Martin, On Tue, 16. Apr 2013 at 09:32:08 +0200, Martin Dobias wrote: > > IMHO that's not ok. If the provider doesn't support multiple iterators, > > the second on should be rejected - forcing the caller to close the other > > one first. > You're right - when thinking about it again, it makes more sense to reject > new iterator rather than close the previous one with force. It should be > relatively simple to swap the behavior. Which only moves the problem upward. Maybe we should handle setFilterFid requests like the old featureAtId. > > As we lost the ability to do featureAtId while iterating a layer, we now > > have a couple of places, where stuff behaves strange and it's not really > > obvious that it's causes by a setFilterFid request killing a surrounding > > iteration. > In the other thread (about updateFeature()) I have noted that we actually > never really supported featureAtId while iterating a layer - at least not in > all providers... AFAIK postgis always used only one cursor. With OGR provider > that could work - but maybe just for some drivers (e.g. shapefile). If I have > time I will try to do few tests how qgis 1.8 behaved. I think the postgres provider had a separate (very short lived) cursor for featureAtId. > > Rejecting it wouldn't cure that, but at least make is show (ok, that's what > > the error message does also do that now). And unless we get the parallel > > setFilterFid request back, we'll need to identify and rewrite the looping > > code. > When porting the code to new API, were there really loops that combined > nextFeature() with featureAtId() ? Apparently. But my porting was more an semi-automatic effort - so didn't really look closely at all the code. And I wasn't aware that multiple iterators were a problem - I thought that was kind of the point of the new api. ;) But we have a few tickets for that. Eg. http://hub.qgis.org/issues/7472. I tried to link others related tickets there. There are probably more. The submitters usually are not aware, that the problems are related. I think this is a (real) blocker. Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de committ(ed|ing) to Quantum GIS IRC: jef on FreeNode -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Python] QgsFeatureIterator for geometryless PostgreSQL-Layer
On Tue, Apr 16, 2013 at 8:27 AM, Jürgen E. wrote: > Hi Martin, > > On Mon, 15. Apr 2013 at 23:45:20 +0200, Martin Dobias wrote: >> > BTW what about parallel iterators? I suppose there were problems and thats >> > why you added the "active iterators" - do you recall which providers were >> > affected and how? > >> I have modified providers to have pointers to active iterators because of two >> reasons: 1. if the user asks for a second iterator and the provider does not >> support multiple iterators, the first one has to be closed - they would not >> behave correctly if used together > > IMHO that's not ok. If the provider doesn't support multiple iterators, the > second on should be rejected - forcing the caller to close the other one > first. You're right - when thinking about it again, it makes more sense to reject new iterator rather than close the previous one with force. It should be relatively simple to swap the behavior. > As we lost the ability to do featureAtId while iterating a layer, we now have > a > couple of places, where stuff behaves strange and it's not really obvious that > it's causes by a setFilterFid request killing a surrounding iteration. In the other thread (about updateFeature()) I have noted that we actually never really supported featureAtId while iterating a layer - at least not in all providers... AFAIK postgis always used only one cursor. With OGR provider that could work - but maybe just for some drivers (e.g. shapefile). If I have time I will try to do few tests how qgis 1.8 behaved. > Rejecting it wouldn't cure that, but at least make is show (ok, that's what > the > error message does also do that now). And unless we get the parallel > setFilterFid request back, we'll need to identify and rewrite the looping > code. When porting the code to new API, were there really loops that combined nextFeature() with featureAtId() ? Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Python] QgsFeatureIterator for geometryless PostgreSQL-Layer
Hi Martin, On Mon, 15. Apr 2013 at 23:45:20 +0200, Martin Dobias wrote: > > BTW what about parallel iterators? I suppose there were problems and thats > > why you added the "active iterators" - do you recall which providers were > > affected and how? > I have modified providers to have pointers to active iterators because of two > reasons: 1. if the user asks for a second iterator and the provider does not > support multiple iterators, the first one has to be closed - they would not > behave correctly if used together IMHO that's not ok. If the provider doesn't support multiple iterators, the second on should be rejected - forcing the caller to close the other one first. As we lost the ability to do featureAtId while iterating a layer, we now have a couple of places, where stuff behaves strange and it's not really obvious that it's causes by a setFilterFid request killing a surrounding iteration. Rejecting it wouldn't cure that, but at least make is show (ok, that's what the error message does also do that now). And unless we get the parallel setFilterFid request back, we'll need to identify and rewrite the looping code. Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de committ(ed|ing) to Quantum GIS IRC: jef on FreeNode -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Python] QgsFeatureIterator for geometryless PostgreSQL-Layer
On Fri, Apr 12, 2013 at 10:33 AM, Jürgen E. wrote: >> Recently I have been wondering whether it would not be better to >> actually stop using flags and replace them by usual getter/setter >> functions. My main concern is the setSubsetOfAttributes() function: it >> also sets the flag, so the users may end up with a weird behavior, >> e.g.: >> QgsFeatureRequest().setSubsetOfAttributes( ["name","type"], fields >> ).setFlags( NoGeometry ) >> That would fetch all attributes... because the setFlags overrides the >> previously set SubsetOfAttributes flag. > > Yes, I've also thought about that, but somehow missed to speak up - but IIRC > (;)) I migrated everything accordingly. > > Given that the flags need qualification it's even shorter to use the > getter/setters API-wise. That's right. Thinking about it again, we should really fix the API before 2.0. It seems you have ported that correctly (btw. many thanks for that!), but ordinary users that do not read c++ code will sooner or later struggle with it. I'm adding that to my todo list :-) >> Also, the way how things are done right now, providers need to >> implement fetching of attributes in this way (pseudo-code): >> if using subset of attributes: >> for each attribute from subset: >> fetch attribute >> else: >> for each attribute from provider: >> fetch attribute > >> This is quite annoying, we should probably have a simple array where >> each value would indicate whether to fetch attribute with that index >> or not (by default all values would be true). The fetching would be >> simplified to: >> for each attribute from provider: >> if attribute should be fetched: >> fetch attribute > >> What do you think? :-) > > Don't they just all do: > > subsetOfAttributes ? mRequest.subsetOfAttributes() : P->attributeIndexes() Not really. Usually there's the kind of code I have mentioned above. In theory we could change it to use the attributeIndexes() call. > Can't we move that to a requestedAttributes() in QgsAbstractFeatureIterator > and > just iterate over the result? Yes we can :-) > BTW what about parallel iterators? I suppose there were problems and thats > why > you added the "active iterators" - do you recall which providers were affected > and how? I have modified providers to have pointers to active iterators because of two reasons: 1. if the user asks for a second iterator and the provider does not support multiple iterators, the first one has to be closed - they would not behave correctly if used together 2. if the layer is deleted for whatever reason, we must ensure that any iterators that may still exist will be closed - they would cause crashes otherwise As of now, all providers support only one iterator per provider instance. For parallel iterators (N iterators, one thread) we could have a provider capability indicating whether they are supported or not. Providers supporting parallel iterators would not close the previously active iterators - instead they would only keep them in the list of active iterators. When we add multi-threaded rendering, things will get a bit more complex. Providers allowing parallel iterators should be fine - they will just need some locking of the list of active iterators. There will be a slight problem with providers allowing just one iterator: in a different thread we cannot simply close the currently active iterator (from a different thread) as that would be a run condition. I guess we will have to define the behavior in the following way - when the provider is asked for a new iterator, it will: a. wait for the active iterator to get closed - if it comes from a different thread b. close the old iterator - in case it comes from the same thread This should ensure that the rendering (or processing) thread will wait until GUI thread finishes what it wants (and vice versa), while still keeping the current behavior when dealing with only one thread. We will just need to explicitly assign iterators with the threads that asks for them. Btw. the case b is really just a sanity check for invalid code - it should not happen in production environment - if it does, there is something wrong with the application logic. Maybe during the porting of providers to support multi-threaded environment we will find out that it will be easier to simply update all providers to allow multiple iterators instead of adding the support for the case of N threads and one iterator - that is yet something that needs investigation. Regards Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Python] QgsFeatureIterator for geometryless PostgreSQL-Layer
Hi Martin, On Fri, 12. Apr 2013 at 09:51:15 +0200, Martin Dobias wrote: > On Fri, Apr 12, 2013 at 9:25 AM, Jürgen E. wrote: > > Hi Martin, > > > > On Thu, 11. Apr 2013 at 22:30:57 +0200, Martin Dobias wrote: > >> I have a feeling that we should call that a bug: the NoGeometry flag > >> tells that it is not necessary to fetch geometry... so even if the > >> flag is not set, the feature should be fetched. > > > > Ok, then it's also misleading. Should we rename NoGeometry to > > WithoutGeometry > > while we still can? > > Yes, we could do that. Or maybe IgnoreGeometry? > > Recently I have been wondering whether it would not be better to > actually stop using flags and replace them by usual getter/setter > functions. My main concern is the setSubsetOfAttributes() function: it > also sets the flag, so the users may end up with a weird behavior, > e.g.: > QgsFeatureRequest().setSubsetOfAttributes( ["name","type"], fields > ).setFlags( NoGeometry ) > That would fetch all attributes... because the setFlags overrides the > previously set SubsetOfAttributes flag. Yes, I've also thought about that, but somehow missed to speak up - but IIRC (;)) I migrated everything accordingly. Given that the flags need qualification it's even shorter to use the getter/setters API-wise. > Also, the way how things are done right now, providers need to > implement fetching of attributes in this way (pseudo-code): > if using subset of attributes: > for each attribute from subset: > fetch attribute > else: > for each attribute from provider: > fetch attribute > This is quite annoying, we should probably have a simple array where > each value would indicate whether to fetch attribute with that index > or not (by default all values would be true). The fetching would be > simplified to: > for each attribute from provider: > if attribute should be fetched: > fetch attribute > What do you think? :-) Don't they just all do: subsetOfAttributes ? mRequest.subsetOfAttributes() : P->attributeIndexes() Can't we move that to a requestedAttributes() in QgsAbstractFeatureIterator and just iterate over the result? BTW what about parallel iterators? I suppose there were problems and thats why you added the "active iterators" - do you recall which providers were affected and how? Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de committ(ed|ing) to Quantum GIS IRC: jef on FreeNode -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Python] QgsFeatureIterator for geometryless PostgreSQL-Layer
On Fri, Apr 12, 2013 at 9:25 AM, Jürgen E. wrote: > Hi Martin, > > On Thu, 11. Apr 2013 at 22:30:57 +0200, Martin Dobias wrote: >> I have a feeling that we should call that a bug: the NoGeometry flag >> tells that it is not necessary to fetch geometry... so even if the >> flag is not set, the feature should be fetched. > > Ok, then it's also misleading. Should we rename NoGeometry to WithoutGeometry > while we still can? Yes, we could do that. Or maybe IgnoreGeometry? Recently I have been wondering whether it would not be better to actually stop using flags and replace them by usual getter/setter functions. My main concern is the setSubsetOfAttributes() function: it also sets the flag, so the users may end up with a weird behavior, e.g.: QgsFeatureRequest().setSubsetOfAttributes( ["name","type"], fields ).setFlags( NoGeometry ) That would fetch all attributes... because the setFlags overrides the previously set SubsetOfAttributes flag. Maybe we can keep the flags, but we should not have the SubsetOfAttributes there. Also, the way how things are done right now, providers need to implement fetching of attributes in this way (pseudo-code): if using subset of attributes: for each attribute from subset: fetch attribute else: for each attribute from provider: fetch attribute This is quite annoying, we should probably have a simple array where each value would indicate whether to fetch attribute with that index or not (by default all values would be true). The fetching would be simplified to: for each attribute from provider: if attribute should be fetched: fetch attribute What do you think? :-) Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Python] QgsFeatureIterator for geometryless PostgreSQL-Layer
Hi Martin, On Thu, 11. Apr 2013 at 22:30:57 +0200, Martin Dobias wrote: > I have a feeling that we should call that a bug: the NoGeometry flag > tells that it is not necessary to fetch geometry... so even if the > flag is not set, the feature should be fetched. Ok, then it's also misleading. Should we rename NoGeometry to WithoutGeometry while we still can? Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de committ(ed|ing) to Quantum GIS IRC: jef on FreeNode -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Python] QgsFeatureIterator for geometryless PostgreSQL-Layer
Hi Juergen On Tue, Apr 9, 2013 at 6:10 PM, Jürgen E. wrote: >> if I do >> feat = QgsFeature() >> iter = myLayer.getFeatures(QgsFeatureRequest().setFilterFid(myFid)) >> iter.nextFeature(feat) >> returns False and I get a message in the PostgreSQL message tab stating >> "Trying to fetch geometry on layer without geometry." >> >> Can anybody confirm? >> Do I miss anything or is this a bug? > > You request geometry (by not saying you don't want any) - and get refused > because there's none. > > myLayer.getFeatures(QgsFeatureRequest().setFilterFid(myFid).setFlags( > QgsFeatureRequest.NoGeometry ) ) > > should work. Not really a bug, but inconvienent. I have a feeling that we should call that a bug: the NoGeometry flag tells that it is not necessary to fetch geometry... so even if the flag is not set, the feature should be fetched. Btw. there is one slightly related thing: "enableGeometrylessFeatures(bool)" function of QgsVectorDataProvider. It works only with OGR provider and I believe there is not justification for keeping it around in v2.0. If I remember correctly we have added it long time ago when all geometryless features were automatically rejected because other parts of QGIS were not expecting QgsFeature with NULL geometry - however the situation has changed in meanwhile. I will remove it. Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Python] QgsFeatureIterator for geometryless PostgreSQL-Layer
Jürgen, this works! I checked the docs for QgsVectorLayer.getFeatures and QgsFeatureIterator but not for QgsFeatureRequest thank you and all the best Bernhard Am 09.04.2013 18:10, schrieb Jürgen E. Fischer: Hi Bernhard, On Tue, 09. Apr 2013 at 15:09:31 +0200, Bernhard Ströbl wrote: I am trying to access features of a geometryless layer derived from a PostgreSQL table in current master. if I do feat = QgsFeature() iter = myLayer.getFeatures(QgsFeatureRequest().setFilterFid(myFid)) iter.nextFeature(feat) returns False and I get a message in the PostgreSQL message tab stating "Trying to fetch geometry on layer without geometry." Can anybody confirm? Do I miss anything or is this a bug? You request geometry (by not saying you don't want any) - and get refused because there's none. myLayer.getFeatures(QgsFeatureRequest().setFilterFid(myFid).setFlags( QgsFeatureRequest.NoGeometry ) ) should work. Not really a bug, but inconvienent. Jürgen __ Information from ESET Mail Security, version of virus signature database 8211 (20130409) __ The message was checked by ESET Mail Security. http://www.eset.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Python] QgsFeatureIterator for geometryless PostgreSQL-Layer
Hi Bernhard, On Tue, 09. Apr 2013 at 15:09:31 +0200, Bernhard Ströbl wrote: > I am trying to access features of a geometryless layer derived from a > PostgreSQL table in current master. > > if I do > feat = QgsFeature() > iter = myLayer.getFeatures(QgsFeatureRequest().setFilterFid(myFid)) > iter.nextFeature(feat) > returns False and I get a message in the PostgreSQL message tab stating > "Trying to fetch geometry on layer without geometry." > > Can anybody confirm? > Do I miss anything or is this a bug? You request geometry (by not saying you don't want any) - and get refused because there's none. myLayer.getFeatures(QgsFeatureRequest().setFilterFid(myFid).setFlags( QgsFeatureRequest.NoGeometry ) ) should work. Not really a bug, but inconvienent. Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de committ(ed|ing) to Quantum GIS IRC: jef on FreeNode -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] [Python] QgsFeatureIterator for geometryless PostgreSQL-Layer
Hi, I am trying to access features of a geometryless layer derived from a PostgreSQL table in current master. if I do feat = QgsFeature() iter = myLayer.getFeatures(QgsFeatureRequest().setFilterFid(myFid)) iter.nextFeature(feat) returns False and I get a message in the PostgreSQL message tab stating "Trying to fetch geometry on layer without geometry." Can anybody confirm? Do I miss anything or is this a bug? Bernhard P. S. in 1.8 one could pass a Boolean in order to tell the dataProvider to fetch the geometry or not. __ Information from ESET Mail Security, version of virus signature database 8209 (20130409) __ The message was checked by ESET Mail Security. http://www.eset.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
