Hi all,
I’m writing to ask space for a CSW (Catalog Services for the Web) community module.
The module should form the core for providing catalog services out of GeoServer.
It won’t be, at least at the beginning, a stand-alone CSW server, so not a competitor
to GeoNetwork or PyCSW, but we are going to try and keep things generic enough that
it can develop in whatever direction we see fit in the future.
What I need to develop is in fact a “proxy front end”, that is, a protocol translator between
the CSW standard and a internal catalog using its own proprietary protocol, so the focus
is on providing all the protocol level implementation, and an interface, similar in the
intents to DataStore, which would allow to plug different kinds of backends onto GeoServer.
Luckily enough it seems that catalog matches well enough a number of subsystems that
we already have in place:
- querying can be done via OGC Filter of CQL, which we both support
- records returned can have a varying structure, they can be base dublin core, iso or
ebRim, in all cases it seems we have a good way of representing them by using
complex features
(Jody mentioned we have Recod, RecordSchema in gt-api, but I’d prefer to strengthen
the usage of complex features and use one less concept in our coding rather than
to disperse ourselves with new ones that are mere interfaces without an implementation)
The backend plugin may looking something like this:
interface CatalogStore {
/**
- Well known base record types
*/
FeatureType CSW_RECORD_TYPE = …; /* This one is mandatory for all implementations */
FeatureType ISO_19115_RECORD_TYPE = …;
FeatureType EBRIM_REGISTRY_PACKAGE_TYPE = …;
/**
- Returns the supported record types
*/
FeatureType getRecordSchemas() throws IOException;
/**
-
Queries a specific record type using the GeoTools Query object (which contains type name,
-
attribute selection
FeatureCollection getRecords(Query q, Transaction t) throws IOException;
List getDomain(Name typeName, Name attributeName);
List addRecord(Feature f, Transaction t) throws IOException;
void deleteRecord(Filter f, Transaction t) throws IOException;
void updateRecord(Name typeName, Name attributeNames, Object attributeValues, Filter filter, Transaction t) throws IOException;
CatalogCapabilties getCapabilities()
}
The CatalogStore would advertise the type of records it offers, including, but not limited to,
CSW (basically, Dublic Core), ISO 19115, and ebRIM, and would return features following
those schemas when getRecords is invoked.
The resulting FeatureCollection would be sent to an output format for encoding, for starters
and CITE certification we’ll need CSW, and I’m going to do some work on ebRIM since
what I have to expose from legacy is a ebRIM for earth observation compliant catalog.
The getDomain operation would support the same named operation, allowing the store
to do anything from a seq scan in the records to a distinct over a database, depending
on the storage used by the backend.
The add/delete/update operations are there to support CSW transactions, which is something
we don’t need out of the box, but it’s nice to have them in the interface anyways.
Finally, the Catalog capabilties class would be a was like QueryCapabilities, for starters
it would advertise support for write methods and the list of record properties that the store can
enumerate the domain of (the ones that can be called on GetDomain).
As you can see there is no harvest operation, this is because a harvest, if one day we will want it,
could be implemented as a service on top of CatalogStore that would look for the record information
remotely and perform transactions on the CatalogStore to update/add/remove the records.
Implementation wise I think we’re are going to create for GeoServer the bridge to the catalog,
but also a sort of “property file store for catalog”, that is a simple implementation reading from
xml files on disk (one per record), probably supporting only dublin core for starters.
This would help in testing, but would also give us a “pure record” storage (without data)
that we can then use to power the CITE tests, which demand for specific records with
a specific structure.
It would also serve as a simple example of how to implement a CatalogStore, just like
property data store did in the past.
CatalogStore at this moment would be part of GeoServer, but I would not mind pushing
it back later into GeoTools, especially if somebody shows up that wants to code a
CSW client around it.
The implementation should start later during this week
Feedback welcomed.
Cheers
Andrea
–
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
