[Qgis-developer] Qgis datamodel (update)

Christoph Spoerri cspoerri at cavtel.net
Mon Dec 18 21:53:03 EST 2006


Hi Martin,

Thanks for the feedback. Please see my attached comments. Also, feel free to 
make any chagnes to the wiki pages.


On Thursday 14 December 2006 07:37, Martin Dobias wrote:
> Hi,
>
> I must say - nice analysis! I always prefer to do code cleanups and
> refactorings sooner than later - I've learned that on one project
> where I've been only adding new features without refining design,
> ending with completely unmaintainable code.
>
> I've read the wiki page and I have some questions:
>
> - vector data queries: you differentiate between queries for geometry
> and queries for select operation. Do you think it's better? Have you
> considered that when drawing you might need also some attributes e.g.
> to determine feature's color?

sure, I don't see why we can't combine feature and attribute queries.

>
> My vision of queries is that you'll call something like:
> select(QgsRect spatialFilter, QgsSearchString attributeFilter)
> so you'll specify both spatial and attribute filter at once and
> getNextFeature() calls will give you features that pass through both
> filters.
>
> For even better flexibility we might use visitor design pattern, e.g.:
> select(QgsDataVisitor* visitor, QgsRect spatialFilter, QgsSearchString
> attributeFilter)
> Usage: you'll create a subclass of QgsDataVisitor and override its
> function which gets called on new feature. This way you could decide
> what to do or data it will need most flexibly.

not sure what the benefits here would be, but then I'm not familiar with this 
design pattern. I guess, I should read up on it.

>
> - you write that data sets should be subclassed by provider
> developers. I don't understand this - I thought you mean that
> providers will do low-level backend-dependent work, while datasets
> will provide high-level (provider independent) functionality... Why to
> subclass them?

Yes, it was the idea that datasets would be independant from the data 
provider. Yet, after some more thinking, I'm not sure if this would actually 
be possible, since the provider wouldn't deal with the individual 
featuers/cells but with the dataset as a whole.

>
> - it's not clear to me what type of connection will be between map
> layers and data sets - do you think of one-to-one or also other types
> e.g. one dataset for more layers?

The idea is that the same dataset could be used for mulitple layers. I didn't 
deal much with the layers yet, since I don't realy think they are part of the 
data model, but rather part of the UI (?) model. I only included them in the 
discussion as clearification/examples.

>
> - when interfacing layer, should I be able to get direct access to
> data set or data provider? Or should layer work as a proxy for some
> functionality of these classes?

no. the layer wouldn't provide direct access to the data. You would need to 
get the underlaying dataset for a layer in order to interact with the data.

>
> If you'll have some time it would be nice to have an UML diagram with
> only layer, data set and data provider classes, their connection and
> most important functions / member values.

a more detailed UML should come in the next couple of weeks. I'm currently 
putting some thoughts into what methods and members each class should have 
and compare them to what already exists.

>
> My questions here are mostly about vector layers, I'm not very
> comfortable with all the raster stuff. Probably Tim is the one who
> could understands QGIS raster drawing the most
>
> Regards,
> Martin
>
> On 12/14/06, Christoph Spoerri <cspoerri at cavtel.net> wrote:
> > Hi there,
> >
> > I started to write down some of my ideas regarding the design of a
> > (hopefully) clearer and simpler data model (one word or two???). Please
> > check the wki page at
> > http://wiki.qgis.org/qgiswiki/Redesign_of_QGis_data_model and chime in
> > with any ideas or comments.
> >
> > Since my knowledge with rasters and tins is rather limited, I'm
> > especially interested in comments from the folks who are expert in that
> > area.
> >
> > cheers,
> > Christoph
> > _______________________________________________
> > Qgis-developer mailing list
> > Qgis-developer at lists.qgis.org
> > http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer



More information about the Qgis-developer mailing list