New Vector API

classic Classic list List threaded Threaded
39 messages Options
12
Reply | Threaded
Open this post in threaded view
|

New Vector API

Martin Dobias
Hi everyone,

it seems that now it is a good time to ask for a broader review of the
work I have been doing during recent months: essentially making QGIS
vector API more flexible and more ready for introduction of threading
for rendering. That resulted in a greater refactoring of some parts of
QgsVectorLayer class and QgsVectorDataProvider implementations.
Everything is in new_vector_api branch in QGIS repository on GitHub
[1].

There are few things that are not finished, but should not take too
much work to sort out:
- disabled providers - mssql, osm, sqlanywhere, wfs - not yet updated to new API
- disabled mapserver - there are few things to update

If no serious problems will be found, I would like to merge the branch
to master and continue working on that on master branch to avoid the
possibility to drift (again) too much from the quick development that
happens on master. In short term I plan to do some polishing and
fixing bugs, then eventually start looking at the threading again.

For more details about what happened in the branch, see the text below
(long read!). A great help from early testers would be to compile the
branch, try to do some "usual" stuff with vectors and see if things
break apart (crashes? data corruption?).

Looking forward to your comments!

Regards
Martin

[1] https://github.com/qgis/Quantum-GIS/tree/new_vector_api



QGIS VECTOR API CHANGES

1. QgsFeature (changes)

a) access to attributes by name. Vector data providers and vector
layer assign pointer to the fields in QgsFeature, so it is possible to
set/get attributes by their name. This is not as efficient as with
direct access by index, but often this convenience is useful for
users.

b) attributes are stored in a QVector container rather than a QMap.
The major advantage is simplification of logic related to handling of
attributes: it's not possible to have "holes" in the array of
fields/attributes. Currently it is possible that for example layer
with three fields returns indexes 0,1,3 - but it is not so common nor
obvious, so it's a common source of errors. After refactoring there
must not be any holes, so a layer with three fields always returns
indexes 0,1,2. When iterating over layer's features, QgsFeature always
contains a vector of all layer's attributes. In case the client has
not requested attributes to be fetched, the attributes contain invalid
values.


2. QgsFields (new class)

Just like attributes within a feature are stored in a vector instead
of map, also layer's fields are now stored in a vector. QgsFields is a
new class that mimics QVector API and adds two more pieces of
functionality:

a) fast lookup of field index from name. When QgsFields is populated
with fields, it creates a map of fields that facilitates fast lookups

b) detection of field origin. When working with a vector layer, it is
sometimes useful to find out origin of the field - whether it comes
from provider, from a join or whether it is a newly added field (not
committed). In the future we could add also expression-based fields,
creating a field calculator that calculates the values on the fly.


3. QgsFeatureRequest (new class)

Class that encapsulates requests for features to a vector layer or
vector data provider. Right now in master branch, the request is
defined by arguments to select() method. That's not very flexible nor
simple to use. Feature request class allows easier extensibility in
future (support generic expression filter, native provider's SQL
filter...).

Without any customization, the request will ask for all features with
geometries and attributes - somehow better default that the current
one that does not fetch attributes if their list is not explicitly
given.

(I'm not yet completely happy with the API of this class, so it may be
changed to some degree. Suggestions are welcome.)

Examples:
- fetch all features:
    QgsFeatureRequest()
- fetch all features, only one attribute
    QgsFeatureRequest().setSubsetOfAttributes(QStringList("myfield"),
provider->fields())
- fetch all features, without geometries
    QgsFeatureRequest().setFlags(QgsFeatureRequest::NoGeometry)
- fetch only features from particular extent
    QgsFeatureRequest().setFilterRect(QgsRectangle(0,0,1,1))
- fetch only one feature
    QgsFeatureRequest().setFilterFid(45)



4. QgsFeatureIterator (new class)

The iterator class allows iteration over features of a vector layer or
a provider. It contains the usual nextFeature() method that fills
given QgsFeature class with data.

Internally, this class is a wrapper around QgsAbstractFeatureIterator
interface that is implemented by each vector data provider and by
vector layer. In theory we could use directly
QgsAbstractFeatureIterator pointers, but this wrapper allows us to use
it as a local variable, so it gets destroyed automatically when it
gets out of scope, not requiring an explicit "delete" call that would
be necessary with a pointer (easy to forget, right?)


5. Access to features

Vector layer and providers implement one important method call:
getFeatures(). It takes single argument (QgsFeatureRequest) and
returns QgsFeatureIterator. This replaces select(), nextFeature(),
rewind() and featureAtId() methods.

This approach allows users to create multiple iterators over a vector
layer (or a vector data provider). But currently that's not supported
because this needs support in the providers. At some point, we could
add support for simultaneous iterators - something that old API does
not allow at all.

When QgsFeatureIterator instance of a particular layer is closed (by
calling close() or destructed), then a new getFeatures() call may be
issued.


6. QgsVectorLayerEditBuffer (new class)

All editing functionality of vector layer has been moved out of
QgsVectorLayer into a new class that stores everything related to
editing: added features, removed features, changed geometries, changed
attribute values, added attributes, removed attributes. This class is
accessible from QgsVectorLayer, but it exists only when the layer is
in editing mode - it is deleted once features are rolled back or
committed.

The undo/redo support has been completely rewritten and greatly
simplified: instead of one undo command that gathers changes within
the edit buffer, there is now one undo command implementation for each
action. The undo commands can be grouped together with QUndoStack
macros. The new implementation ensures that the undo stack does not
get out of sync, because all editing changes are stored onto undo
stack (unlike current implementation in master branch where
begin/end-UndoCommand() methods must be called before/after edit
operations to ensure correct behavior of undo).


7. QgsVectorLayerEditUtils (new class)

Advanced editing operations that operate on vector layers (e.g. add
part) that can be composed from one or more simple edit operations
have been moved out of QgsVectorLayer and its edit buffer, so that the
vector layer API is not polluted by methods that do not need access to
its private members.


8. QgsVectorLayerCache (new class)

To speed up geometry editing, QGIS keeps a cache of geometries
currently shown in map canvas. This cache has been decoupled from
editing operations and moved to a separate class to keep things tidy.
In the future we should be able to add more general caching scheme to
allow faster rendering of vectors. Also, this might be a good place to
store index of feature ID -> row number that is calculated every time
when attribute table is opened.


9. Python

Python API has been updated to support functionality from the points
above, that is access by attribute name and support for python
iterators, e.g.:

for feature in layer.getFeatures(request):
  print feature["road_id"]
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: New Vector API

Régis Haubourg
Hi Martin,
all this looks great! I really had troubles with FieldMap and vector handling in python plugin developpement. I really appriciate that step towards more usability for basic plugin developpers.  Ready for testing and correcting some plugins of course.
 Some classes were removed some days ago and many plugins are already broken. From my point of view, it is a good timing for merging your branch, before qe spend to much efforts on correcting them. (And I stick with osgeo4w for testing, so it's hard to test your branch otherwirse ;-))
Régis
Reply | Threaded
Open this post in threaded view
|

Re: New Vector API

Alexander Bruy
In reply to this post by Martin Dobias
Hi Martin,

just tried to build new_vector_api branch under 32bit Slackware 14.0:
GCC 4.7.1
glibs 2.15
Qt 4.8.2
GDAL 1.9.2
SpatiaLite 4.0.0
Python 2.7.3

And get next error:

/home/alex/devel/cpp/qgis/src/providers/spatialite/qgsspatialiteprovider.cpp:
In member function 'void
QgsSpatiaLiteProvider::loadFieldsAbstractInterface(gaiaVectorLayerPtr)':
/home/alex/devel/cpp/qgis/src/providers/spatialite/qgsspatialiteprovider.cpp:619:23:
error: 'class QgsFields' has no member named 'insert'
make[2]: *** [src/providers/spatialite/CMakeFiles/spatialiteprovider.dir/qgsspatialiteprovider.cpp.o]
Error 1
make[1]: *** [src/providers/spatialite/CMakeFiles/spatialiteprovider.dir/all]
Error 2
make[1]: *** Waiting for unfinished jobs....

--
Alexander Bruy
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: New Vector API

John C. Tull-2
On Dec 28, 2012, at 11:27 AM, Alexander Bruy <[hidden email]> wrote:

> Hi Martin,
>
> just tried to build new_vector_api branch under 32bit Slackware 14.0:
> GCC 4.7.1
> glibs 2.15
> Qt 4.8.2
> GDAL 1.9.2
> SpatiaLite 4.0.0
> Python 2.7.3
>
> And get next error:
>
> /home/alex/devel/cpp/qgis/src/providers/spatialite/qgsspatialiteprovider.cpp:
> In member function 'void
> QgsSpatiaLiteProvider::loadFieldsAbstractInterface(gaiaVectorLayerPtr)':
> /home/alex/devel/cpp/qgis/src/providers/spatialite/qgsspatialiteprovider.cpp:619:23:
> error: 'class QgsFields' has no member named 'insert'
> make[2]: *** [src/providers/spatialite/CMakeFiles/spatialiteprovider.dir/qgsspatialiteprovider.cpp.o]
> Error 1
> make[1]: *** [src/providers/spatialite/CMakeFiles/spatialiteprovider.dir/all]
> Error 2
> make[1]: *** Waiting for unfinished jobs....
>
> --
> Alexander Bruy

Hi all,

I ran into the same compile issue on my OS X system.

Regards,
John

_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: New Vector API

Martin Dobias
In reply to this post by Alexander Bruy
Hi Alex

On Fri, Dec 28, 2012 at 8:27 PM, Alexander Bruy
<[hidden email]> wrote:

> Hi Martin,
>
> just tried to build new_vector_api branch under 32bit Slackware 14.0:
> GCC 4.7.1
> glibs 2.15
> Qt 4.8.2
> GDAL 1.9.2
> SpatiaLite 4.0.0
> Python 2.7.3
>
> And get next error:
>
> /home/alex/devel/cpp/qgis/src/providers/spatialite/qgsspatialiteprovider.cpp:
> In member function 'void
> QgsSpatiaLiteProvider::loadFieldsAbstractInterface(gaiaVectorLayerPtr)':
> /home/alex/devel/cpp/qgis/src/providers/spatialite/qgsspatialiteprovider.cpp:619:23:
> error: 'class QgsFields' has no member named 'insert'

I haven't tested with SpatiaLite 4 yet. I've just committed a quick
fix that _may_ fix your problems, but there may be more of them -
please let me know in that case, I will try to compile QGIS with
SpatiaLite 4 to fix the remaining problems.

Martin
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: New Vector API

Marco Hugentobler-4
In reply to this post by Martin Dobias

Hi Martin

Cool, great news! Can't wait to try out the new vector classes. I'm away from the computer until 4th of January. Probably other core devs are out of contact too, so please make the review period long enough.

Regards, Marco



Von Samsung Galaxy Note gesendet

Martin Dobias <[hidden email]> hat geschrieben:
Hi everyone,

it seems that now it is a good time to ask for a broader review of the
work I have been doing during recent months: essentially making QGIS
vector API more flexible and more ready for introduction of threading
for rendering. That resulted in a greater refactoring of some parts of
QgsVectorLayer class and QgsVectorDataProvider implementations.
Everything is in new_vector_api branch in QGIS repository on GitHub
[1].

There are few things that are not finished, but should not take too
much work to sort out:
- disabled providers - mssql, osm, sqlanywhere, wfs - not yet updated to new API
- disabled mapserver - there are few things to update

If no serious problems will be found, I would like to merge the branch
to master and continue working on that on master branch to avoid the
possibility to drift (again) too much from the quick development that
happens on master. In short term I plan to do some polishing and
fixing bugs, then eventually start looking at the threading again.

For more details about what happened in the branch, see the text below
(long read!). A great help from early testers would be to compile the
branch, try to do some "usual" stuff with vectors and see if things
break apart (crashes? data corruption?).

Looking forward to your comments!

Regards
Martin

[1] https://github.com/qgis/Quantum-GIS/tree/new_vector_api



QGIS VECTOR API CHANGES

1. QgsFeature (changes)

a) access to attributes by name. Vector data providers and vector
layer assign pointer to the fields in QgsFeature, so it is possible to
set/get attributes by their name. This is not as efficient as with
direct access by index, but often this convenience is useful for
users.

b) attributes are stored in a QVector container rather than a QMap.
The major advantage is simplification of logic related to handling of
attributes: it's not possible to have "holes" in the array of
fields/attributes. Currently it is possible that for example layer
with three fields returns indexes 0,1,3 - but it is not so common nor
obvious, so it's a common source of errors. After refactoring there
must not be any holes, so a layer with three fields always returns
indexes 0,1,2. When iterating over layer's features, QgsFeature always
contains a vector of all layer's attributes. In case the client has
not requested attributes to be fetched, the attributes contain invalid
values.


2. QgsFields (new class)

Just like attributes within a feature are stored in a vector instead
of map, also layer's fields are now stored in a vector. QgsFields is a
new class that mimics QVector API and adds two more pieces of
functionality:

a) fast lookup of field index from name. When QgsFields is populated
with fields, it creates a map of fields that facilitates fast lookups

b) detection of field origin. When working with a vector layer, it is
sometimes useful to find out origin of the field - whether it comes
from provider, from a join or whether it is a newly added field (not
committed). In the future we could add also expression-based fields,
creating a field calculator that calculates the values on the fly.


3. QgsFeatureRequest (new class)

Class that encapsulates requests for features to a vector layer or
vector data provider. Right now in master branch, the request is
defined by arguments to select() method. That's not very flexible nor
simple to use. Feature request class allows easier extensibility in
future (support generic expression filter, native provider's SQL
filter...).

Without any customization, the request will ask for all features with
geometries and attributes - somehow better default that the current
one that does not fetch attributes if their list is not explicitly
given.

(I'm not yet completely happy with the API of this class, so it may be
changed to some degree. Suggestions are welcome.)

Examples:
- fetch all features:
    QgsFeatureRequest()
- fetch all features, only one attribute
    QgsFeatureRequest().setSubsetOfAttributes(QStringList("myfield"),
provider->fields())
- fetch all features, without geometries
    QgsFeatureRequest().setFlags(QgsFeatureRequest::NoGeometry)
- fetch only features from particular extent
    QgsFeatureRequest().setFilterRect(QgsRectangle(0,0,1,1))
- fetch only one feature
    QgsFeatureRequest().setFilterFid(45)



4. QgsFeatureIterator (new class)

The iterator class allows iteration over features of a vector layer or
a provider. It contains the usual nextFeature() method that fills
given QgsFeature class with data.

Internally, this class is a wrapper around QgsAbstractFeatureIterator
interface that is implemented by each vector data provider and by
vector layer. In theory we could use directly
QgsAbstractFeatureIterator pointers, but this wrapper allows us to use
it as a local variable, so it gets destroyed automatically when it
gets out of scope, not requiring an explicit "delete" call that would
be necessary with a pointer (easy to forget, right?)


5. Access to features

Vector layer and providers implement one important method call:
getFeatures(). It takes single argument (QgsFeatureRequest) and
returns QgsFeatureIterator. This replaces select(), nextFeature(),
rewind() and featureAtId() methods.

This approach allows users to create multiple iterators over a vector
layer (or a vector data provider). But currently that's not supported
because this needs support in the providers. At some point, we could
add support for simultaneous iterators - something that old API does
not allow at all.

When QgsFeatureIterator instance of a particular layer is closed (by
calling close() or destructed), then a new getFeatures() call may be
issued.


6. QgsVectorLayerEditBuffer (new class)

All editing functionality of vector layer has been moved out of
QgsVectorLayer into a new class that stores everything related to
editing: added features, removed features, changed geometries, changed
attribute values, added attributes, removed attributes. This class is
accessible from QgsVectorLayer, but it exists only when the layer is
in editing mode - it is deleted once features are rolled back or
committed.

The undo/redo support has been completely rewritten and greatly
simplified: instead of one undo command that gathers changes within
the edit buffer, there is now one undo command implementation for each
action. The undo commands can be grouped together with QUndoStack
macros. The new implementation ensures that the undo stack does not
get out of sync, because all editing changes are stored onto undo
stack (unlike current implementation in master branch where
begin/end-UndoCommand() methods must be called before/after edit
operations to ensure correct behavior of undo).


7. QgsVectorLayerEditUtils (new class)

Advanced editing operations that operate on vector layers (e.g. add
part) that can be composed from one or more simple edit operations
have been moved out of QgsVectorLayer and its edit buffer, so that the
vector layer API is not polluted by methods that do not need access to
its private members.


8. QgsVectorLayerCache (new class)

To speed up geometry editing, QGIS keeps a cache of geometries
currently shown in map canvas. This cache has been decoupled from
editing operations and moved to a separate class to keep things tidy.
In the future we should be able to add more general caching scheme to
allow faster rendering of vectors. Also, this might be a good place to
store index of feature ID -> row number that is calculated every time
when attribute table is opened.


9. Python

Python API has been updated to support functionality from the points
above, that is access by attribute name and support for python
iterators, e.g.:

for feature in layer.getFeatures(request):
  print feature["road_id"]
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer

_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: New Vector API

pcav
Why not releasing a beta before merging?
All the best.

Marco Hugentobler <[hidden email]> ha scritto:

Hi Martin

Cool, great news! Can't wait to try out the new vector classes. I'm away from the computer until 4th of January. Probably other core devs are out of contact too, so please make the review period long enough.

Regards, Marco



Von Samsung Galaxy Note gesendet

Martin Dobias <[hidden email]> hat geschrieben:
Hi everyone,

it seems that now it is a good time to ask for a broader review of the
work I have been doing during recent months: essentially making QGIS
vector API more flexible and more ready for introduction of threading
for rendering. That resulted in a greater refactoring of some parts of
QgsVectorLayer class and QgsVectorDataProvider implementations.
Everything is in new_vector_api branch in QGIS repository on GitHub
[1].

There are few things that are not finished, but should not take too
much work to sort out:
- disabled providers - mssql, osm, sqlanywhere, wfs - not yet updated to new API
- disabled mapserver - there are few things to update

If no serious problems will be found, I would like to merge the branch
to master and continue working on that on master branch to avoid the
possibility to drift (again) too much from the quick development that
happens on master. In short term I plan to do some polishing and
fixing bugs, then eventually start looking at the threading again.

For more details about what happened in the branch, see the text below
(long read!). A great help from early testers would be to compile the
branch, try to do some "usual" stuff with vectors and see if things
break apart (crashes? data corruption?).

Looking forward to your comments!

Regards
Martin

[1] https://github.com/qgis/Quantum-GIS/tree/new_vector_api



QGIS VECTOR API CHANGES

1. QgsFeature (changes)

a) access to attributes by name. Vector data providers and vector
layer assign pointer to the fields in QgsFeature, so it is possible to
set/get attributes by their name. This is not as efficient as with
direct access by index, but often this convenience is useful for
users.

b) attributes are stored in a QVector container rather than a QMap.
The major advantage is simplification of logic related to handling of
attributes: it's not possible to have "holes" in the array of
fields/attributes. Currently it is possible that for example layer
with three fields returns indexes 0,1,3 - but it is not so common nor
obvious, so it's a common source of errors. After refactoring there
must not be any holes, so a layer with three fields always returns
indexes 0,1,2. When iterati ng over layer's features, QgsFeature always
contains a vector of all layer's attributes. In case the client has
not requested attributes to be fetched, the attributes contain invalid
values.


2. QgsFields (new class)

Just like attributes within a feature are stored in a vector instead
of map, also layer's fields are now stored in a vector. QgsFields is a
new class that mimics QVector API and adds two more pieces of
functionality:

a) fast lookup of field index from name. When QgsFields is populated
with fields, it creates a map of fields that facilitates fast lookups

b) detection of field origin. When working with a vector layer, it is
sometimes useful to find out origin of the field - whether it comes
from provider, from a join or whether it is a newly added field (not
committed). In the future we could add also expression-based fields,
creating a field calculator that calculates t he values on the fly.


3. QgsFeatureRequest (new class)

Class that encapsulates requests for features to a vector layer or
vector data provider. Right now in master branch, the request is
defined by arguments to select() method. That's not very flexible nor
simple to use. Feature request class allows easier extensibility in
future (support generic expression filter, native provider's SQL
filter...).

Without any customization, the request will ask for all features with
geometries and attributes - somehow better default that the current
one that does not fetch attributes if their list is not explicitly
given.

(I'm not yet completely happy with the API of this class, so it may be
changed to some degree. Suggestions are welcome.)

Examples:
- fetch all features:
    QgsFeatureRequest()
- fetch all features, only one attribute
    QgsFeatureRequest().setSubsetOfAttributes(QStringList("myfield"),
provider->fields())
- fetch all features, without geometries
    QgsFeatureRequest().setFlags(QgsFeatureRequest::NoGeometry)
- fetch only features from particular extent
    QgsFeatureRequest().setFilterRect(QgsRectangle(0,0,1,1))
- fetch only one feature
    QgsFeatureRequest().setFilterFid(45)



4. QgsFeatureIterator (new class)

The iterator class allows iteration over features of a vector layer or
a provider. It contains the usual nextFeature() method that fills
given QgsFeature class with data.

Internally, this class is a wrapper around QgsAbstractFeatureIterator
interface that is implemented by each vector data provider and by
vector layer. In theory we could use directly
QgsAbstractFeatureIterator pointers, but this wrapper allows us to use
it as a loc al variable, so it gets destroyed automatically when it
gets out of scope, not requiring an explicit "delete" call that would
be necessary with a pointer (easy to forget, right?)


5. Access to features

Vector layer and providers implement one important method call:
getFeatures(). It takes single argument (QgsFeatureRequest) and
returns QgsFeatureIterator. This replaces select(), nextFeature(),
rewind() and featureAtId() methods.

This approach allows users to create multiple iterators over a vector
layer (or a vector data provider). But currently that's not supported
because this needs support in the providers. At some point, we could
add support for simultaneous iterators - something that old API does
not allow at all.

When QgsFeatureIterator instance of a particular layer is closed (by
calling close() or destructed), then a new getFeatures() call may be
issued.


6. QgsVectorLayerEditBuffer (new class)

All editing functionality of vector layer has been moved out of
QgsVectorLayer into a new class that stores everything related to
editing: added features, removed features, changed geometries, changed
attribute values, added attributes, removed attributes. This class is
accessible from QgsVectorLayer, but it exists only when the layer is
in editing mode - it is deleted once features are rolled back or
committed.

The undo/redo support has been completely rewritten and greatly
simplified: instead of one undo command that gathers changes within
the edit buffer, there is now one undo command implementation for each
action. The undo commands can be grouped together with QUndoStack
macros. The new implementation ensures that the undo stack does not
get out of sync, because all editing changes are stored onto undo
stack (unlike current implementation in master branc h where
begin/end-UndoCommand() methods must be called before/after edit
operations to ensure correct behavior of undo).


7. QgsVectorLayerEditUtils (new class)

Advanced editing operations that operate on vector layers (e.g. add
part) that can be composed from one or more simple edit operations
have been moved out of QgsVectorLayer and its edit buffer, so that the
vector layer API is not polluted by methods that do not need access to
its private members.


8. QgsVectorLayerCache (new class)

To speed up geometry editing, QGIS keeps a cache of geometries
currently shown in map canvas. This cache has been decoupled from
editing operations and moved to a separate class to keep things tidy.
In the future we should be able to add more general caching scheme to
allow faster rendering of vectors. Also, this might be a good place to
store index of feature ID -> row number that is calculated every time
when attribute table is opened.


9. Python

Python API has been updated to support functionality from the points
above, that is access by attribute name and support for python
iterators, e.g.:

for feature in layer.getFeatures(request):
  print feature["road_id"]
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer



Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer

--
http://faunalia.it/pc
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: New Vector API

Alexander Bruy
In reply to this post by Martin Dobias
Hi Martin,

thanks, this fix works fine, now all compiled without errors

On Sat, 29 Dec 2012 02:35:36 +0100
Martin Dobias <[hidden email]> wrote:

> I haven't tested with SpatiaLite 4 yet. I've just committed a quick
> fix that _may_ fix your problems, but there may be more of them -
> please let me know in that case, I will try to compile QGIS with
> SpatiaLite 4 to fix the remaining problems.

--
Alexander Bruy
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: New Vector API

Giovanni Manghi-2
In reply to this post by Martin Dobias
> Why not releasing a beta before merging?

I completely agree.


cheers


-- Giovanni --
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: New Vector API

Nathan Woodrow
In reply to this post by Martin Dobias
I don't think that is a great idea. A beta implies that there is a new
release coming with just bugs fixes this would not be the case if we
released a beta and then merged the changes.
From: Giovanni Manghi
Sent: 1/01/2013 2:10 AM
To: [hidden email]
Subject: Re: [Qgis-developer] New Vector API
> Why not releasing a beta before merging?

I completely agree.


cheers


-- Giovanni --
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: New Vector API

pcav
Il 31/12/2012 17:15, Nathan Woodrow ha scritto:
> I don't think that is a great idea. A beta implies that there is a new
> release coming with just bugs fixes this would not be the case if we
> released a beta and then merged the changes.

besides the name, I think waiting until after the merge, and the subsequent fixes,
could delay a release for a long time.
all the best.
--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: New Vector API

Jürgen E. Fischer
In reply to this post by pcav
Hi Paolo,

On Sat, 29. Dec 2012 at 18:38:26 +0100, Paolo Cavallini wrote:
> Why not releasing a beta before merging?

What for?

Either we want that stuff in the release, then we need to merge it before the
release and releasing a beta now of stuff that we're probably going to break
IMHO doesn't make any sense.

Then again I don't see a big point in releasing betas at all.  We have nightly
builds.  And given that we have a feature freeze before a release those will
also settle.  If that isn't enough we could also schedule switch from nightly
to weekly builds before a release to have an easier target for testing.

Doing extra betas (and we like won't get away with just one) would just imply
more work and extra infrastructure.


Jürgen

--
Jürgen E. Fischer         norBIT GmbH               Tel. +49-4931-918175-31
Dipl.-Inf. (FH)           Rheinstraße 13            Fax. +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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: New Vector API

macho
Hi!

Just for the logs .. I agree with Jürgen in that case..
It does not make any sense to release a beta now - with some new implemented things and some not ..
From my point of view - the only last thing we are all waiting for is Martins threading implementation ..
After merging his branch I'd vote for a feature freeze and a longer stabilization phase ..
And then .. Lets' do the 2.0 ;)

regards
Werner



On Tue, Jan 1, 2013 at 5:00 PM, Jürgen E. <[hidden email]> wrote:
Hi Paolo,

On Sat, 29. Dec 2012 at 18:38:26 +0100, Paolo Cavallini wrote:
> Why not releasing a beta before merging?

What for?

Either we want that stuff in the release, then we need to merge it before the
release and releasing a beta now of stuff that we're probably going to break
IMHO doesn't make any sense.

Then again I don't see a big point in releasing betas at all.  We have nightly
builds.  And given that we have a feature freeze before a release those will
also settle.  If that isn't enough we could also schedule switch from nightly
to weekly builds before a release to have an easier target for testing.

Doing extra betas (and we like won't get away with just one) would just imply
more work and extra infrastructure.


Jürgen

--
Jürgen E. Fischer         norBIT GmbH               Tel. +49-4931-918175-31
Dipl.-Inf. (FH)           Rheinstraße 13            Fax. +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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer


_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: New Vector API

pcav
Il 01/01/2013 20:41, Werner Macho ha scritto:
> Hi!
>
> Just for the logs .. I agree with Jürgen in that case..
> It does not make any sense to release a beta now - with some new implemented things
> and some not ..
> From my point of view - the only last thing we are all waiting for is Martins
> threading implementation ..


Of course I agree with you to avoid useless work. I'm just worried that if we keep on
adding new features and breaking the API the 2.0 release will take too long.
AFAIK the blocking factors we agreed upon are:

  * Symbology overhaul
  * Labelling overhaul
  * New web site and docs
  * SEXTANTE integration
  * Interface cleanup and consistency
  * Plugins migration

I think there is still work to be done on most of these, if not all.

All the best.
--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: New Vector API

Matthias Kuhn
In reply to this post by Martin Dobias
Hi Martin,

Thank you for your work.

I really appreciate these features. Some of them will allow me to
simplify my code drastically.
I'm updating the plugin I'm working on right now and will let you know
about any problems which occur.

You've been talking about updating to PyQt4 SIP version 2. I noticed
this change did not yet happen. What are your plans regarding this update?

I'm also looking forward to seeing QgsFeatureRequest support
QgsExpression, I think this is not yet supported?

Cheers

PS:
I've just been able to segfault:

a = dataProvider.getFeatures( QgsFeatureRequest().setFilterFid(
featureId ) )
a.rewind()
a.next()

I'm not sure if the featureId existed or not ( I think it did )

PPS:
Another strange thing (maybe related), calling next() directly on a fid
filter returns a feature, storing into a QgsFeatureIterator and calling
next on this throws a StopIteration:

dataProvider.getFeatures(QgsFeatureRequest().setFilterFid( featureId )
).next()
<qgis.core.QgsFeature object at 0xaa027a0>

features = dataProvider.getFeatures(QgsFeatureRequest().setFilterFid(
featureId ) )
f = features.next()
Traceback (most recent call last):
   File
"/home/kk/.qgis//python/plugins/remotedebug/pysrc/pydevd_exec.py", line
2, in Exec
     exec exp in global_vars, local_vars
   File "<console>", line 1, in <module>
StopIteration


On 12/28/2012 05:03 PM, Martin Dobias wrote:

> Hi everyone,
>
> it seems that now it is a good time to ask for a broader review of the
> work I have been doing during recent months: essentially making QGIS
> vector API more flexible and more ready for introduction of threading
> for rendering. That resulted in a greater refactoring of some parts of
> QgsVectorLayer class and QgsVectorDataProvider implementations.
> Everything is in new_vector_api branch in QGIS repository on GitHub
> [1].
>
> There are few things that are not finished, but should not take too
> much work to sort out:
> - disabled providers - mssql, osm, sqlanywhere, wfs - not yet updated to new API
> - disabled mapserver - there are few things to update
>
> If no serious problems will be found, I would like to merge the branch
> to master and continue working on that on master branch to avoid the
> possibility to drift (again) too much from the quick development that
> happens on master. In short term I plan to do some polishing and
> fixing bugs, then eventually start looking at the threading again.
>
> For more details about what happened in the branch, see the text below
> (long read!). A great help from early testers would be to compile the
> branch, try to do some "usual" stuff with vectors and see if things
> break apart (crashes? data corruption?).
>
> Looking forward to your comments!
>
> Regards
> Martin
>
> [1] https://github.com/qgis/Quantum-GIS/tree/new_vector_api
>
>
>
> QGIS VECTOR API CHANGES
>
> 1. QgsFeature (changes)
>
> a) access to attributes by name. Vector data providers and vector
> layer assign pointer to the fields in QgsFeature, so it is possible to
> set/get attributes by their name. This is not as efficient as with
> direct access by index, but often this convenience is useful for
> users.
>
> b) attributes are stored in a QVector container rather than a QMap.
> The major advantage is simplification of logic related to handling of
> attributes: it's not possible to have "holes" in the array of
> fields/attributes. Currently it is possible that for example layer
> with three fields returns indexes 0,1,3 - but it is not so common nor
> obvious, so it's a common source of errors. After refactoring there
> must not be any holes, so a layer with three fields always returns
> indexes 0,1,2. When iterating over layer's features, QgsFeature always
> contains a vector of all layer's attributes. In case the client has
> not requested attributes to be fetched, the attributes contain invalid
> values.
>
>
> 2. QgsFields (new class)
>
> Just like attributes within a feature are stored in a vector instead
> of map, also layer's fields are now stored in a vector. QgsFields is a
> new class that mimics QVector API and adds two more pieces of
> functionality:
>
> a) fast lookup of field index from name. When QgsFields is populated
> with fields, it creates a map of fields that facilitates fast lookups
>
> b) detection of field origin. When working with a vector layer, it is
> sometimes useful to find out origin of the field - whether it comes
> from provider, from a join or whether it is a newly added field (not
> committed). In the future we could add also expression-based fields,
> creating a field calculator that calculates the values on the fly.
>
>
> 3. QgsFeatureRequest (new class)
>
> Class that encapsulates requests for features to a vector layer or
> vector data provider. Right now in master branch, the request is
> defined by arguments to select() method. That's not very flexible nor
> simple to use. Feature request class allows easier extensibility in
> future (support generic expression filter, native provider's SQL
> filter...).
>
> Without any customization, the request will ask for all features with
> geometries and attributes - somehow better default that the current
> one that does not fetch attributes if their list is not explicitly
> given.
>
> (I'm not yet completely happy with the API of this class, so it may be
> changed to some degree. Suggestions are welcome.)
>
> Examples:
> - fetch all features:
>      QgsFeatureRequest()
> - fetch all features, only one attribute
>      QgsFeatureRequest().setSubsetOfAttributes(QStringList("myfield"),
> provider->fields())
> - fetch all features, without geometries
>      QgsFeatureRequest().setFlags(QgsFeatureRequest::NoGeometry)
> - fetch only features from particular extent
>      QgsFeatureRequest().setFilterRect(QgsRectangle(0,0,1,1))
> - fetch only one feature
>      QgsFeatureRequest().setFilterFid(45)
>
>
>
> 4. QgsFeatureIterator (new class)
>
> The iterator class allows iteration over features of a vector layer or
> a provider. It contains the usual nextFeature() method that fills
> given QgsFeature class with data.
>
> Internally, this class is a wrapper around QgsAbstractFeatureIterator
> interface that is implemented by each vector data provider and by
> vector layer. In theory we could use directly
> QgsAbstractFeatureIterator pointers, but this wrapper allows us to use
> it as a local variable, so it gets destroyed automatically when it
> gets out of scope, not requiring an explicit "delete" call that would
> be necessary with a pointer (easy to forget, right?)
>
>
> 5. Access to features
>
> Vector layer and providers implement one important method call:
> getFeatures(). It takes single argument (QgsFeatureRequest) and
> returns QgsFeatureIterator. This replaces select(), nextFeature(),
> rewind() and featureAtId() methods.
>
> This approach allows users to create multiple iterators over a vector
> layer (or a vector data provider). But currently that's not supported
> because this needs support in the providers. At some point, we could
> add support for simultaneous iterators - something that old API does
> not allow at all.
>
> When QgsFeatureIterator instance of a particular layer is closed (by
> calling close() or destructed), then a new getFeatures() call may be
> issued.
>
>
> 6. QgsVectorLayerEditBuffer (new class)
>
> All editing functionality of vector layer has been moved out of
> QgsVectorLayer into a new class that stores everything related to
> editing: added features, removed features, changed geometries, changed
> attribute values, added attributes, removed attributes. This class is
> accessible from QgsVectorLayer, but it exists only when the layer is
> in editing mode - it is deleted once features are rolled back or
> committed.
>
> The undo/redo support has been completely rewritten and greatly
> simplified: instead of one undo command that gathers changes within
> the edit buffer, there is now one undo command implementation for each
> action. The undo commands can be grouped together with QUndoStack
> macros. The new implementation ensures that the undo stack does not
> get out of sync, because all editing changes are stored onto undo
> stack (unlike current implementation in master branch where
> begin/end-UndoCommand() methods must be called before/after edit
> operations to ensure correct behavior of undo).
>
>
> 7. QgsVectorLayerEditUtils (new class)
>
> Advanced editing operations that operate on vector layers (e.g. add
> part) that can be composed from one or more simple edit operations
> have been moved out of QgsVectorLayer and its edit buffer, so that the
> vector layer API is not polluted by methods that do not need access to
> its private members.
>
>
> 8. QgsVectorLayerCache (new class)
>
> To speed up geometry editing, QGIS keeps a cache of geometries
> currently shown in map canvas. This cache has been decoupled from
> editing operations and moved to a separate class to keep things tidy.
> In the future we should be able to add more general caching scheme to
> allow faster rendering of vectors. Also, this might be a good place to
> store index of feature ID -> row number that is calculated every time
> when attribute table is opened.
>
>
> 9. Python
>
> Python API has been updated to support functionality from the points
> above, that is access by attribute name and support for python
> iterators, e.g.:
>
> for feature in layer.getFeatures(request):
>    print feature["road_id"]
> _______________________________________________
> Qgis-developer mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/qgis-developer

_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: New Vector API

Martin Dobias
Hi Matthias

thanks for your mail.

On Thu, Jan 3, 2013 at 10:37 AM, Matthias Kuhn <[hidden email]> wrote:
>
> You've been talking about updating to PyQt4 SIP version 2. I noticed this
> change did not yet happen. What are your plans regarding this update?

Yes, the plans are still there. I'm only wondering what would be the
best time to switch - right now within the branch or a bit later once
the branch is merged and the new code settles down a bit? I can see a
slight advantage of the latter approach of having a greater chance of
separating problems caused by the merge and problems caused by the SIP
API change, but I do not have a strong opinion here.


> I'm also looking forward to seeing QgsFeatureRequest support QgsExpression,
> I think this is not yet supported?

No, it's not yet supported. It should be possible to add features like
this one easily even later without breaking any API. It is not my
priority now, of course any contributions in that direction are
welcome! (and also for support of native expressions for postgres,
spatialite and other DBMSs)


> PS:
> I've just been able to segfault:
>
> a = dataProvider.getFeatures( QgsFeatureRequest().setFilterFid( featureId )
> )
> a.rewind()
> a.next()

Which provider was that? Just tried with OGR and memory providers and it worked.


> PPS:
> Another strange thing (maybe related), calling next() directly on a fid
> filter returns a feature, storing into a QgsFeatureIterator and calling next
> on this throws a StopIteration:
>
> dataProvider.getFeatures(QgsFeatureRequest().setFilterFid( featureId )
> ).next()
> <qgis.core.QgsFeature object at 0xaa027a0>
>
> features = dataProvider.getFeatures(QgsFeatureRequest().setFilterFid(
> featureId ) )
> f = features.next()
> Traceback (most recent call last):
>   File "/home/kk/.qgis//python/plugins/remotedebug/pysrc/pydevd_exec.py",
> line 2, in Exec
>     exec exp in global_vars, local_vars
>   File "<console>", line 1, in <module>
> StopIteration

Again, works for me correctly with OGR and memory provider - maybe
some provider other has that problem.


Regards
Martin
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: New Vector API

Matthias Kuhn
Hi Martin,

On 01/04/2013 10:19 PM, Martin Dobias wrote:

> Hi Matthias
>
> thanks for your mail.
>
> On Thu, Jan 3, 2013 at 10:37 AM, Matthias Kuhn <[hidden email]> wrote:
>> You've been talking about updating to PyQt4 SIP version 2. I noticed this
>> change did not yet happen. What are your plans regarding this update?
> Yes, the plans are still there. I'm only wondering what would be the
> best time to switch - right now within the branch or a bit later once
> the branch is merged and the new code settles down a bit? I can see a
> slight advantage of the latter approach of having a greater chance of
> separating problems caused by the merge and problems caused by the SIP
> API change, but I do not have a strong opinion here.
I think doing it now would be the best time, as the API is already and
is even more going to be broken. For plugin devs it will probably be the
easiest to take care only once. No strong opinion here either.
>> I'm also looking forward to seeing QgsFeatureRequest support QgsExpression,
>> I think this is not yet supported?
> No, it's not yet supported. It should be possible to add features like
> this one easily even later without breaking any API. It is not my
> priority now, of course any contributions in that direction are
> welcome! (and also for support of native expressions for postgres,
> spatialite and other DBMSs)
Maybe I find the time to take care of this.
What I would like to see (but I think that's a rather tough one): to
make the providers translate QgsExpression to native backend commands.
Although this can lead to some nasty side-effects.

>> PS:
>> I've just been able to segfault:
>>
>> a = dataProvider.getFeatures( QgsFeatureRequest().setFilterFid( featureId )
>> )
>> a.rewind()
>> a.next()
> Which provider was that? Just tried with OGR and memory providers and it worked.
>
>
>> PPS:
>> Another strange thing (maybe related), calling next() directly on a fid
>> filter returns a feature, storing into a QgsFeatureIterator and calling next
>> on this throws a StopIteration:
>>
>> dataProvider.getFeatures(QgsFeatureRequest().setFilterFid( featureId )
>> ).next()
>> <qgis.core.QgsFeature object at 0xaa027a0>
>>
>> features = dataProvider.getFeatures(QgsFeatureRequest().setFilterFid(
>> featureId ) )
>> f = features.next()
>> Traceback (most recent call last):
>>    File "/home/kk/.qgis//python/plugins/remotedebug/pysrc/pydevd_exec.py",
>> line 2, in Exec
>>      exec exp in global_vars, local_vars
>>    File "<console>", line 1, in <module>
>> StopIteration
> Again, works for me correctly with OGR and memory provider - maybe
> some provider other has that problem.
Both tests have been made with a postgres backend.

>
> Regards
> Martin
Regards
Matthias
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: New Vector API

Martin Dobias
In reply to this post by Matthias Kuhn
On Thu, Jan 3, 2013 at 10:37 AM, Matthias Kuhn <[hidden email]> wrote:
> I've just been able to segfault:
>
> a = dataProvider.getFeatures( QgsFeatureRequest().setFilterFid( featureId )
> )
> a.rewind()
> a.next()

Hi Matthias

I was able to replicate the problem in postgres provider - I have
fixed the issues, please check again. By the way, funny thing is that
rewind() call obviously never worked correctly in postgres provider
until now (it executed "move 0" instead of "move absolute 0",
resulting in no actual move).

Please let me know if you encounter any other problems.

Martin
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: New Vector API

Marco Hugentobler-4
In reply to this post by Martin Dobias
Hi Martin

Finally I had a look at the vector changes and I really like the new
architecture. I agree it is important to merge soon. Merging as soon as
server and the remaining providers are ported would be good in my opinion.
Btw, there is a problem with postgis layers, probably related to the
recent fix: After zooming to a new extent, I always need to refresh a
second time to get the features (with the refresh button in the main
window). Otherwise, no features are drawn.

Regards,
Marco




On 28.12.2012 17:03, Martin Dobias wrote:

> Hi everyone,
>
> it seems that now it is a good time to ask for a broader review of the
> work I have been doing during recent months: essentially making QGIS
> vector API more flexible and more ready for introduction of threading
> for rendering. That resulted in a greater refactoring of some parts of
> QgsVectorLayer class and QgsVectorDataProvider implementations.
> Everything is in new_vector_api branch in QGIS repository on GitHub
> [1].
>
> There are few things that are not finished, but should not take too
> much work to sort out:
> - disabled providers - mssql, osm, sqlanywhere, wfs - not yet updated to new API
> - disabled mapserver - there are few things to update
>
> If no serious problems will be found, I would like to merge the branch
> to master and continue working on that on master branch to avoid the
> possibility to drift (again) too much from the quick development that
> happens on master. In short term I plan to do some polishing and
> fixing bugs, then eventually start looking at the threading again.
>
> For more details about what happened in the branch, see the text below
> (long read!). A great help from early testers would be to compile the
> branch, try to do some "usual" stuff with vectors and see if things
> break apart (crashes? data corruption?).
>
> Looking forward to your comments!
>
> Regards
> Martin
>
> [1] https://github.com/qgis/Quantum-GIS/tree/new_vector_api
>
>
>
> QGIS VECTOR API CHANGES
>
> 1. QgsFeature (changes)
>
> a) access to attributes by name. Vector data providers and vector
> layer assign pointer to the fields in QgsFeature, so it is possible to
> set/get attributes by their name. This is not as efficient as with
> direct access by index, but often this convenience is useful for
> users.
>
> b) attributes are stored in a QVector container rather than a QMap.
> The major advantage is simplification of logic related to handling of
> attributes: it's not possible to have "holes" in the array of
> fields/attributes. Currently it is possible that for example layer
> with three fields returns indexes 0,1,3 - but it is not so common nor
> obvious, so it's a common source of errors. After refactoring there
> must not be any holes, so a layer with three fields always returns
> indexes 0,1,2. When iterating over layer's features, QgsFeature always
> contains a vector of all layer's attributes. In case the client has
> not requested attributes to be fetched, the attributes contain invalid
> values.
>
>
> 2. QgsFields (new class)
>
> Just like attributes within a feature are stored in a vector instead
> of map, also layer's fields are now stored in a vector. QgsFields is a
> new class that mimics QVector API and adds two more pieces of
> functionality:
>
> a) fast lookup of field index from name. When QgsFields is populated
> with fields, it creates a map of fields that facilitates fast lookups
>
> b) detection of field origin. When working with a vector layer, it is
> sometimes useful to find out origin of the field - whether it comes
> from provider, from a join or whether it is a newly added field (not
> committed). In the future we could add also expression-based fields,
> creating a field calculator that calculates the values on the fly.
>
>
> 3. QgsFeatureRequest (new class)
>
> Class that encapsulates requests for features to a vector layer or
> vector data provider. Right now in master branch, the request is
> defined by arguments to select() method. That's not very flexible nor
> simple to use. Feature request class allows easier extensibility in
> future (support generic expression filter, native provider's SQL
> filter...).
>
> Without any customization, the request will ask for all features with
> geometries and attributes - somehow better default that the current
> one that does not fetch attributes if their list is not explicitly
> given.
>
> (I'm not yet completely happy with the API of this class, so it may be
> changed to some degree. Suggestions are welcome.)
>
> Examples:
> - fetch all features:
>      QgsFeatureRequest()
> - fetch all features, only one attribute
>      QgsFeatureRequest().setSubsetOfAttributes(QStringList("myfield"),
> provider->fields())
> - fetch all features, without geometries
>      QgsFeatureRequest().setFlags(QgsFeatureRequest::NoGeometry)
> - fetch only features from particular extent
>      QgsFeatureRequest().setFilterRect(QgsRectangle(0,0,1,1))
> - fetch only one feature
>      QgsFeatureRequest().setFilterFid(45)
>
>
>
> 4. QgsFeatureIterator (new class)
>
> The iterator class allows iteration over features of a vector layer or
> a provider. It contains the usual nextFeature() method that fills
> given QgsFeature class with data.
>
> Internally, this class is a wrapper around QgsAbstractFeatureIterator
> interface that is implemented by each vector data provider and by
> vector layer. In theory we could use directly
> QgsAbstractFeatureIterator pointers, but this wrapper allows us to use
> it as a local variable, so it gets destroyed automatically when it
> gets out of scope, not requiring an explicit "delete" call that would
> be necessary with a pointer (easy to forget, right?)
>
>
> 5. Access to features
>
> Vector layer and providers implement one important method call:
> getFeatures(). It takes single argument (QgsFeatureRequest) and
> returns QgsFeatureIterator. This replaces select(), nextFeature(),
> rewind() and featureAtId() methods.
>
> This approach allows users to create multiple iterators over a vector
> layer (or a vector data provider). But currently that's not supported
> because this needs support in the providers. At some point, we could
> add support for simultaneous iterators - something that old API does
> not allow at all.
>
> When QgsFeatureIterator instance of a particular layer is closed (by
> calling close() or destructed), then a new getFeatures() call may be
> issued.
>
>
> 6. QgsVectorLayerEditBuffer (new class)
>
> All editing functionality of vector layer has been moved out of
> QgsVectorLayer into a new class that stores everything related to
> editing: added features, removed features, changed geometries, changed
> attribute values, added attributes, removed attributes. This class is
> accessible from QgsVectorLayer, but it exists only when the layer is
> in editing mode - it is deleted once features are rolled back or
> committed.
>
> The undo/redo support has been completely rewritten and greatly
> simplified: instead of one undo command that gathers changes within
> the edit buffer, there is now one undo command implementation for each
> action. The undo commands can be grouped together with QUndoStack
> macros. The new implementation ensures that the undo stack does not
> get out of sync, because all editing changes are stored onto undo
> stack (unlike current implementation in master branch where
> begin/end-UndoCommand() methods must be called before/after edit
> operations to ensure correct behavior of undo).
>
>
> 7. QgsVectorLayerEditUtils (new class)
>
> Advanced editing operations that operate on vector layers (e.g. add
> part) that can be composed from one or more simple edit operations
> have been moved out of QgsVectorLayer and its edit buffer, so that the
> vector layer API is not polluted by methods that do not need access to
> its private members.
>
>
> 8. QgsVectorLayerCache (new class)
>
> To speed up geometry editing, QGIS keeps a cache of geometries
> currently shown in map canvas. This cache has been decoupled from
> editing operations and moved to a separate class to keep things tidy.
> In the future we should be able to add more general caching scheme to
> allow faster rendering of vectors. Also, this might be a good place to
> store index of feature ID -> row number that is calculated every time
> when attribute table is opened.
>
>
> 9. Python
>
> Python API has been updated to support functionality from the points
> above, that is access by attribute name and support for python
> iterators, e.g.:
>
> for feature in layer.getFeatures(request):
>    print feature["road_id"]
> _______________________________________________
> Qgis-developer mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/qgis-developer


--
Dr. Marco Hugentobler
Sourcepole -  Linux & Open Source Solutions
Weberstrasse 5, CH-8004 Zürich, Switzerland
[hidden email] http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee

_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: New Vector API

Matthias Kuhn
In reply to this post by Martin Dobias
Hi Martin,

as already mentioned by Marco, there seems to be a problem with the
latest fix. I have multiple postgres layers and after every redraw only
one layer (random) is drawn (sometimes not even one layer).

When I quit QGIS I get a segmentation fault in the postgres provider
(QgsPostgresConn, member methods called on a NULL pointer), backtrace
attached.

Regards,
Matthias


On 01/06/2013 10:01 PM, Martin Dobias wrote:

> On Thu, Jan 3, 2013 at 10:37 AM, Matthias Kuhn <[hidden email]> wrote:
>> I've just been able to segfault:
>>
>> a = dataProvider.getFeatures( QgsFeatureRequest().setFilterFid( featureId )
>> )
>> a.rewind()
>> a.next()
> Hi Matthias
>
> I was able to replicate the problem in postgres provider - I have
> fixed the issues, please check again. By the way, funny thing is that
> rewind() call obviously never worked correctly in postgres provider
> until now (it executed "move 0" instead of "move absolute 0",
> resulting in no actual move).
>
> Please let me know if you encounter any other problems.
>
> Martin

_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer

trace.dump (35K) Download Attachment
12