[fdo-dev] Classes and properties in SHP providers

Robert Fortin robert.fortin at autodesk.com
Mon Oct 30 17:04:00 EST 2006


Mateusz,

Just to concur with Pierre, you don't need create datastore because you
can use a connection on an empty folder and Applyschema to create new
shape file.  Create datastore would result in a) creating a new folder
or b) creating a new shape file.  In case of a) you can do that using
standard OS API.  In case of b) a new shape file is useless until you
actually specify the info that it will contain and this is done through
apply schema. 

And I think you got both concept for Datastore and datasource right.

RF

-----Original Message-----
From: Mateusz Loskot [mailto:mateusz at loskot.net] 
Sent: Monday, October 30, 2006 4:54 PM
To: dev at fdo.osgeo.org
Subject: Re: [fdo-dev] Classes and properties in SHP providers

Pierre Dalcourt wrote:
> My comments:
> 
> 1.  SHP doesn't support create/destroy datastore.  Part of the 
> challenge is that a datastore can mean either a single shapefile or a 
> directory of shapefiles, so the intended meaning would have to be made
clear.

Yes, exactly.
Would it be much different from how OGR works?

> Secondly, the scope of ListDatastores command would have to be made 
> clear as well; if the user connects to a single shapefile (as opposed 
> to a directory), what does ListDatastores list?

First, I'd ask if support of CreateDataStore implies support of
ListDataStores support. Does it?

Second, there are two concepts/terms bounded to FDO:
- data source
- data store

The FDO Dev Guide says:

"A provider, such as Autodesk FDO Provider for Oracle, is an
implementation of the interface for a specific type of data source (for
example, for an Oracle relational database)."

What is data source for OSGeo.SHP?

As I understand, ListdataStores lists data stores available in
particular data source.
Next, according to picture on page 6 of the dev guide, chapter "FDO
Architecture and Providers", for SHP provider, as well as for raster,
ODBC and WFS, there is only single instance of data store presented -
ds<1>.
In comparison to MySQL or Oracle, there is no ds<n>.

So, I'm inclined to understand that for OSGeo.SHP works with
single-data-store data sources and if there is always one data store,
then I don't think ListDataStores command support is required, because
there is nothing dynamic it list, but always one known data store.

I've explained it in quite long way, but I'd be thankful for correction,
if I'm wrong.

> If a user connects to a single directory, does ListDatastores recurse 
> over the current directory?

According to my understanding, the situation looks as follows:

1. Connected to single shapefile
- the shapefile is considered as a data store

2. Connected to directory of shapefiles
- it's still single data store - the directory

So, for OSGeo.SHP the data store there is a kind of duality.

> 2.  I don't think so.  You can use SHP Provider to create new 
> shapefiles, by using the ApplySchema command to create a new schema 
> (or get an existing one) and then creating a class that corresponds to

> the SHP file characteristic you want.  See the SchemaTests unit tests 
> in the SHP source code for reference.

Yes, I understand it now. Also thanks to Greg who explained me it in
details on the #fdo channel.

The reason of my misunderstanding is that from FDO docs it's fairly easy
to understand that:

CreateDataStore/DestroyDataStore commands operate on physical parts od
data store/source, ie. create/delete files/directories/databases.
But ApplySchema command modifies existing elements of data store, works
on higher level, like editing existing files/tables, etc.

So, if there is said a provider does not support CreateDataStore, then
it's fairly easy to understand that no physical elements
(files/databases) can be created using such provider.

Thanks!
--
Mateusz Loskot
http://mateusz.loskot.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe at fdo.osgeo.org For additional
commands, e-mail: dev-help at fdo.osgeo.org






More information about the Fdo-internals mailing list