OGR bindings

[Nina Hüffmeyer]

Hi,

as you might know I am implementing ogr support for Thuban. I just wanted to 
let you know my state of progress:
Recently, I didn't check in anything new because my work needed some changes 
of the Thuban core. These changes are done so far, but do need some 
redesigning. This affects especially the session saving and loading which 
should be more flexible and not depending on the availability of special 
extensions. Therefore, a new concept for extensions is required.

The attached file gives you some more information on saving and loading of 
.thuban files and what changes would be required for extensions.

Regards, Nina
-------------- next part --------------
Task/Problem description:

The new extension for OGR allows to manage additional
file formats of shape resources.
Thuban .thuban files should handle this generically and not
require OGR for reading / storing such corresponding layers.
A solution is sought to have Thuban react flexible on incoming
.thuban shapestore elements and call appropriate extensions
if available or ignore otherwise.

Rephrased: The goal is to provide a possibility to access extension
capabilities without calling methods explicitly or refering directly
to a special extension.

Background information:

Binding the ogr library to Thuban allows a lot of new file formats to be read.
If you now want to save the work with these new formats to sessions, Thuban needs 
to know how to treat these file formats while saving and loading. E.g. if you 
want to save a session containing a .dgn file, you need the filename and the 
layername to open the right layer later on whereas shapefiles loaded without ogr 
just need a filename.
Or, if the ogr extension is not available and a session containing a .dgn file is tried to 
be opened, another extension could be able to read .dgn files. Thuban should search for 
a possibility to open the file instead of asking a special extension.

It seems that any file related shape source can be described with
filename and layername (some storage formats include a number of layers in one
file). Database layers additonally require a id-column.


Approach:

Providing access to capabilities requires that extensions know their capabilities.
Therefore each extension should have a list of capabilities like e.g.
["Open Shapestore/DGN", "Open Shapestore/Shapefile", "Open Shapestore/PostGIS"].
If then opening a .dgn file is required, Thuban simply searches for all
extensions able to open such a file and then choose one of the extensions.
The extensions should then have standard methods which allow for example 
to load a shapestore (e.g. LoadFileShapestore() which gets the filename and the layername).

Implementation:

Such a solution would need some changes in the following classes:

save.py: Saving of a fileshapesource would have to be generalized in such a way, that all 
	the information required for any file shape stores would be given.
	The required information is:
	- filetype
	- filename
	- layername
	- id (Thuban internal)
	- (id_column: depending on PostGIS)
	As ogrshapestores and shapefilestores should have to be treated the same way 
	(-> calling isinstance() should be true for both kind of stores), maybe a base
	class should be defined and shapefilestore and ogrshapestore should inherit from 
	this class.

Example for .thuban:

Currently shapefile stores are described this way:
 <fileshapesource filetype="shapefile" id="D813615104" filename="iceland/political.shp"/>
A DGN file could look like this:
 <fileshapesource filetype="DGN" id="D813615104" layername="political" filename="iceland/political.dgn"/>
Also the shapefiles would then look like this:
 <fileshapesource filetype="shapefile" id="D813615104" layername="political" filename="iceland/political.shp"/>
MapInfo is a format where different layernames could occur:
 <fileshapesource filetype="mapinfo" id="D813615104" layername="counties" filename="iceland/political.tab"/>

For dbshapesources the current elements dbconnection and dbshapesource in a .thuban
file are sufficient to search for postgis-readers and to execute them :-)

load.py: Opening a session would identify the filetype by "filetype" given in the .thuban
	file.
	Thuban could then search for an extension able to read the filetype and then call
	an reader method of the extension. If an extension had the capability 
	"Open Shapestore/DGN" it would have to have a reader method like "OpenShapestore" 
	to assure that no exception occurs.

extension.py/extensionregistry.py: the list of capabilities would have to be added to the 
	extensions. This could be implemented in the Extension class (extension.py) or 
	- as every extension should have an ExtensionDescription object - in the 
	ExtensionDescription class (extensionregistry.py) which would be easy to access.

data.py: base class for ogrshapestore and shapefilestore

In order to keep the naming of capabilities and depending methods unique (e.g.
"Open Shapestore/DGN" assures the existance of a method OpenShapestore() ) maybe a global list
of available capabilities could be defined.