[Qgis-developer] controlling visibility

[Carson Farmer]

List,

Based on several comments... I'm seriously thinking of abandoning this 
task to someone who actually knows how to program in C++. However, for 
the time being I'm going to keep plugging away at it ;-)

At this point, I am going to write a QgsDataTable (which will sort of be 
the non-spatial equivalent to QgsVectorLayer), and QgsOgrTableProvider. 
To start, you will not be able to view these tables directly in QGIS, 
but will essentially be able to modify them through code a la 
nextRecord, getRecordAtId, etc...

My hope is that eventually, this will lead to what Maurício de Paulo and 
Barry (see below) have suggested: separate tables from geometries. If we 
have a QgsDataTable, then QgsVectorLayer could have a function 
dataTable(), which would return a pointer to the vector layer's 
QgsDataTable. That way QgsVectorLayer could contain both the spatial 
information (QgsGeometryTable?), and the table information 
(QgsDataTable). This is similar to how a shapefile works, with geometry 
info in the .shp file, attribute info in the .dbf, and a .shx to tie it 
all together...

Obviously this is all a lot of work, but it might make things much 
simpler in the long run in terms of supporting different data sources, 
joining and relating tables, and accessing data quickly and efficiently...

Thoughts?

Carson

Maurício de Paulo
>> I've thought about it some time ago and I always thought the interface
>> would be something like GvSIG and ArcGIS where the tables are all
>> (spatial and non-spatial) in a place where you can join/relate them
>> separate from the geometry representations.
Barry Rowlingson
> Maybe have a QgsData class and then QgsMapLayer and QgsDataTable
> inherit from that. Then the legend displays QgsData objects - perhaps
> grouped as maps and data tables.
> I'd then implement QgsDataTable to have a "provider" so you could
> plug in different table types - CSV file, spreadsheet, RDBMS - or
> maybe subclass them - QgsCSVDataTable, QgsXLSDataTable etc.
>
> Or possibly vector layers are a mix-in of a data table class and a
> vector geometry class. But that would need some serious rewriting. But
> it might mean that you could use attribute data from a vector layer in
> the same way as a data table from a database..