Re: [Geoserver-devel] New community module: CSW
On 23/08/2012 6:31 a.m., Chris Holmes wrote: > But CSW in GeoServer should make it easier for GeoNetwork to harvest > information from GeoServers, and to just follow a philosophy of > keeping the metadata close to the data. Yes, this is precisely my interest. There is this complicated problem with metadata - where to keep it. Ideally, you keep it with the data and let likes of geonetwork harvest it. Ditto for geoserver - if its metadata handling mapped better to source and to geonetwork, then keeping things in sync is easily. The problem I have is that geoserver can use all kind of data sources. Geonetwork can harvest from say SDE and from geoserver but how to control the harvester when the same dataset is in arcSDE and also exposed in Geoserver? On the other hand, for some data sources, geoserver lets us build metadata when there is no standard close to the data and no harvester for geonetwork. We have been hacking around with geonetwork harvesters to resolve this. A consistent picture and a way to expose to geonetwork harvesters whether the metadata is created in geoserver or fetched from another source would be good. -- Phil Scadden, Senior Scientist GNS Science Ltd 764 Cumberland St, Private Bag 1930, Dunedin, New Zealand Ph +64 3 4799663, fax +64 3 477 5232 Notice: This email and any attachments are confidential. If received in error please destroy and immediately notify us. Do not copy or disclose the contents. -- 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 Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] New community module: CSW
To reiterate a bit - in GeoServer we aren't trying to replace GeoNetwork, to be a full catalog 'solution'. We just want to expose GeoServer holdings as CSW. So one would use something like GeoNetwork in a full SDI that requires full metadata and complex editing of that and aggregating many services. But CSW in GeoServer should make it easier for GeoNetwork to harvest information from GeoServers, and to just follow a philosophy of keeping the metadata close to the data. We definitely don't want to make a full metadata editor like GeoNetwork offers, just want to handle 'search' of data layers that can be accessed from GeoServer well. My personal hope is that GeoNetwork continues its work to split up all the functionality it does, so it can interoperate better. In the GeoNetwork package you get a great CSW (and a number of other protocols to search), a portal builder toolkit, a metadata editor and a set of 'harvesting' tools. GeoServer will only look to do basic CSW. So if you want more search protocols you'd probably want to sync your GeoServer with GeoNetwork. And the other 3 things that GeoNetwork does should remain outside of GeoServer. We also want to build better 'syncing' with GeoNetwork, so one can edit service level metadata in either place and have it sync. Chris On Mon, Aug 20, 2012 at 5:06 PM, Andrea Aime wrote: > On Mon, Aug 20, 2012 at 10:41 PM, Phil Scadden wrote: > >> Geoserver provides some catalog metadata already plus a URL link but a >> very uneasy mapping. We have working at trying to sync arcGIS metadata >> (ISO or Inspire), geoserver metadata, and Geonetwork catalogues. Better >> catalog data in geoserver would surely help >> > > The main driver here is not much to provide more metadata, but to provide > the right protocol to discover data in GeoServer without having to hunt it > into a capabilities document (e.g., queriability). > > I'm not sure if the team working on exposing the catalog on CSW is going to > add metadata (I'll be working on the ebRIM/EO proxy model) but I'm pretty > sure having a CSW will trigger more request for more metadata eventually, > so if it's not going to happen right away I'm confident it will eventually > happen as a side effect of having a CSW around > > 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 > Geoserver-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > > -- 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 Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] New community module: CSW
On Tue, Aug 21, 2012 at 1:13 AM, Justin Deoliveira wrote: > > > On Mon, Aug 20, 2012 at 9:36 AM, Andrea Aime > wrote: > >> On Mon, Aug 20, 2012 at 5:59 PM, Gabriel Roldan wrote: >> >>> Hi Andrea, >>> >>> sounds exciting. >>> >>> By ISO 1915 schema I assume you mean ISO 19139, being it's current >>> schema realization (19115 is an abstract spec?). >>> >> >> Eh, you may be right, I did not look much into it, as I have to make a >> ebRIM >> binding, and I think Niels will work on basic CSW/Dublin Core instead >> (but I may be wrong) >> > > To clarify what Niels is doing (through a contract with OpenGeo) will be > adding support for the ISO metadata application profile for CSW 2.0.2. As > described here: > > http://portal.opengeospatial.org/files/?artifact_id=21460 > Ah nice, so in the end we'll have some basic version of all three? It is my understanding that in order to pass certification one also has to support CSW Dublin Core derived basic metadata records 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 Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] New community module: CSW
Phil, I agree, that was my reaction as well! On 21/08/12 04:41, Phil Scadden wrote: > Geoserver provides some catalog metadata already plus a URL link but a > very uneasy mapping. We have working at trying to sync arcGIS metadata > (ISO or Inspire), geoserver metadata, and Geonetwork catalogues. Better > catalog data in geoserver would surely help -- Ben Caradoc-Davies Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- 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 Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] New community module: CSW
On Mon, Aug 20, 2012 at 9:36 AM, Andrea Aime wrote: > On Mon, Aug 20, 2012 at 5:59 PM, Gabriel Roldan wrote: > >> Hi Andrea, >> >> sounds exciting. >> >> By ISO 1915 schema I assume you mean ISO 19139, being it's current >> schema realization (19115 is an abstract spec?). >> > > Eh, you may be right, I did not look much into it, as I have to make a > ebRIM > binding, and I think Niels will work on basic CSW/Dublin Core instead (but > I may be wrong) > To clarify what Niels is doing (through a contract with OpenGeo) will be adding support for the ISO metadata application profile for CSW 2.0.2. As described here: http://portal.opengeospatial.org/files/?artifact_id=21460 > > >> >> I'll make sure to get some time this week to merge the GSIP69 branch >> onto master so that you can experiment with OGC Filter queries on the >> internal Catalog. >> > > I won't be doing that part, probably Niels will > > 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 > Geoserver-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. -- 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 Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] New community module: CSW
On Mon, Aug 20, 2012 at 10:41 PM, Phil Scadden wrote: > Geoserver provides some catalog metadata already plus a URL link but a > very uneasy mapping. We have working at trying to sync arcGIS metadata > (ISO or Inspire), geoserver metadata, and Geonetwork catalogues. Better > catalog data in geoserver would surely help > The main driver here is not much to provide more metadata, but to provide the right protocol to discover data in GeoServer without having to hunt it into a capabilities document (e.g., queriability). I'm not sure if the team working on exposing the catalog on CSW is going to add metadata (I'll be working on the ebRIM/EO proxy model) but I'm pretty sure having a CSW will trigger more request for more metadata eventually, so if it's not going to happen right away I'm confident it will eventually happen as a side effect of having a CSW around 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 Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] New community module: CSW
Geoserver provides some catalog metadata already plus a URL link but a very uneasy mapping. We have working at trying to sync arcGIS metadata (ISO or Inspire), geoserver metadata, and Geonetwork catalogues. Better catalog data in geoserver would surely help Notice: This email and any attachments are confidential. If received in error please destroy and immediately notify us. Do not copy or disclose the contents. -- 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 Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] New community module: CSW
Very interesting,
+1 Andrea,
2012/8/20 Andrea Aime :
> 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
>
Re: [Geoserver-devel] New community module: CSW
On Mon, Aug 20, 2012 at 5:59 PM, Gabriel Roldan wrote: > Hi Andrea, > > sounds exciting. > > By ISO 1915 schema I assume you mean ISO 19139, being it's current > schema realization (19115 is an abstract spec?). > Eh, you may be right, I did not look much into it, as I have to make a ebRIM binding, and I think Niels will work on basic CSW/Dublin Core instead (but I may be wrong) > > I'll make sure to get some time this week to merge the GSIP69 branch > onto master so that you can experiment with OGC Filter queries on the > internal Catalog. > I won't be doing that part, probably Niels will 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 Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] New community module: CSW
Hi Andrea,
sounds exciting.
By ISO 1915 schema I assume you mean ISO 19139, being it's current
schema realization (19115 is an abstract spec?).
I'll make sure to get some time this week to merge the GSIP69 branch
onto master so that you can experiment with OGC Filter queries on the
internal Catalog.
And good luck with schema conversions, it's gonna be fun :)
Cheers,
Gabriel
On Mon, Aug 20, 2012 at 12:11 PM, Andrea Aime
wrote:
> 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
[Geoserver-devel] New community module: CSW
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:/
