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<Object> getDomain(Name typeName, Name attributeName);
List<FeatureId> 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
-------------------------------------------------------
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
