Re: [Geotools-devel] metadata/capabilities object for datasources.

[Andrea A. <aa...@li...>]

On Monday 24 March 2003 18:29, Chris Holmes wrote:

[...]

> In order to figure that out I think we should discuss what we want out =
of
> the metadata object, and how closely our idea of 'capabilities' matches
> the OGC's.  Andrea, please contribute to what I write, as I'm just
> throwing out my initial ideas of what I'd like out of it.

I have very limited time, but I'll try ;-)

> The inspiration behind the metadata object is the
> java.sql.DatabaseMetaData interface, found at
> http://java.sun.com/j2se/1.4/docs/api/java/sql/DatabaseMetaData.html.
> The docs say 'this inteface is implemented by driver vendors to let use=
rs
> know the capabilities of a Database Management System'.  Another key li=
ne
> is 'A user for this interface is commonly a tool that needs to discover
> how to deal with the underlying DBMS.' I imagine a similar use of our
> metadata object, to complement the auto-discovery of new datasources.

[SNIP]

> This allows us to not have a complex datasource hierarchy, like
> file-datasource, rbdms-datasource, transactional datasource, ect.  Inst=
ead
> the datasource interface will have all the possible operations: get, ad=
d,
> modify, delete, startMulti, endMulti.  This allows a program to figure =
out
> what actions are supported, without having to catch unsupported operati=
ons
> exceptions when methods are not implemented.

I fully agree, I feel it's a more flexyble approach that makes it easier
to write applicaitons that don't want or need to deal with native format
knowledge and ds capabilities, compared to IllegalFeatureExceptions or
a set of Interfaces.

> I'm sure we will come up with more methods that will be appropriate to =
put
> in the metadata.  We could make it closesly match a wfs FeatureType
> section of the capabilities document of a wfs.  So it would support
> operations such as getName(), getSRS(), and getLatLongBoundingBox().  A
> setSRS method could also be used for those datasource that don't hold
> their own SRID's.=20

Yes, that would put vector data sources on par with GridCoverages, that=20
already has the CoordinateSystem support. I would suggest to have a=20
getCoordinateSystem() method that returns a CoordinateSystem object.
I would also make the getCoordinateSystem() call compulsory, and have
a null returned if it's not possible to determine the CS. In the shapefil=
e=20
example, you know if you can support this call only at run time, seeing i=
f
the .prj file is there or not. The getLatLongBoudingBox() follows, you ca=
n't=20
answer such a question without knowing the CoordinateSystem and thus
having the MathTransform needed to go back from projected to geographic
coordinates (if needed).

> I think that our datasources more match the FeatureType
> element of the capablities document, as each only has one featureType. =
 I
> feel it is somewhat inappropriate as things are now to have us mirror a
> full capabilities document, with a Service section - containing the Nam=
e,
> title, abstract, fees and whatnot - and a Capability section, which
> contains information on how to access the supported operations.  But if
> we're thinking of eventually using soap or something to use the
> datasources over networks, then I guess such things would be appropriat=
e.
> So if we're planning on trying to support those in the future and/or ar=
e
> fine with our capabilities object just being the FeatureType section of
> the capabilities document, then I think we should name our metadata obj=
ect
> a Capabilities object.  And a getCapalities call on the datasource woul=
d
> return the Capabilities object.

Uhm... I'm not really familiar with WFS and Capabilities, but I'd guess
that Metadata would be more intuitive for anyone who has ever worked
with jdbc...

> Other changes to datasource to discuss
>
> - changing addFeatures to return fid's (matching the wfs insert) (this =
is
> decided, but yet to be implemented.  It's part of the wfs spec)

What are fids? A unique identifier? Is it possible to get fids also in th=
e
getFeature call? This would allow for a cached data source implementation
(you have to know if a features has already been loaded without actually
comparing the geometry and the attributes IMHO).

> -adding setFeatures. (important for datasources that use files, and
> rbdmses can simulate it if they like).  I'm curious if this should mayb=
e
> not be part of the datasource interface, as the file datasources can
> implement it, but we could just expose it with the use of startMulti an=
d
> endMulti.  I'm inclined to not have it in the interface, as I would onl=
y
> use it with start and end Multi, but I don't feel strongly, and can be
> convinced if someone more versed in file datasources has good reasons f=
or
> it.

Well, to be consistent with the Metadata reasoning, I guess it should be=20
in, and if you don't want to support it, make it clear in the
Metadata/Capabilities object.
Otherwise you'll have to know that you are dealing with a dbms backed
datasource or a file based data source, which is something we want to
avoid IMHO. Moreover, creating a setFeatures based on the other
calls (remove and add) it's more or less 10 lines of code I guess...

> -adding getSchema and setSchema.  I'd also sorta like to see a
> createDataSource method in the DataSourceFactorySpi interface that take=
s a
> schema, if possible.  This would speed things up for datasources that
> create their own schemas in the constructor, as they would know not to =
do
> that work if one was passed in. =20

Uhm, but you should anyways compare the passed schema with the one contai=
ned
in the underlying data to see how to match them, isn'it it?

> Perhaps the getSchema call should go in
> the Capabilities object?

It would be consistent with the Metadata jdbc approach at least.
That's all for now :-)

Andrea Aime