[GeoNetwork-users] CSW discovery of WMS layers

Hi: when I publish a WMS (with, say, 4 layers) to GeoNetwork, the CSW
publishes one service record (dc:type='service') and 4 dataset records
(dc:type='dataset').

Discovery of the service and the datasets work fine through querying
CSW.

How can one discover datasets and be able to decipher whether they are
associated with a service?

The use case here is for a client to discover WMS layers and be able to
dynamically add them to their mapping application. I realize one can
discover the service and invoke a GetCapabilities against that service,
but I'd like to avoid that round trip seeing that the layer metadata is
already in the catalogue.

Any ideas?

Thanks

..Tom

================================
Tom Kralidis
Senior Systems Scientist
Geospatial Coordination Office
Chief Information Officer Branch
Environment Canada
Tel: +01-416-739-4907
http://www.ec.gc.ca/

Hi: when I publish a WMS (with, say, 4 layers) to GeoNetwork,
the CSW publishes one service record (dc:type='service') and
4 dataset records (dc:type='dataset').

Discovery of the service and the datasets work fine through
querying CSW.

How can one discover datasets and be able to decipher whether
they are associated with a service?

The use case here is for a client to discover WMS layers and
be able to dynamically add them to their mapping application.
I realize one can discover the service and invoke a
GetCapabilities against that service, but I'd like to avoid
that round trip seeing that the layer metadata is already in
the catalogue.

Any ideas?

Ah. It seems that setting
outputSchema="http://www.isotc211.org/2005/gmd" in the request provides
more exhaustive results.

Querying for services shows srv:operatesOn elements which show layers
available for that service.

Querying for data show a gmd:CI_OnlineResource which shows the link to
the WMS URL for that data, as well as identifying the linkage as
'OGC:WMS-1.1.1-http-get-map' within gmd:protocol.

Sorry for the noise.

Cheers

..Tom

hello tom,
some heretical questions to this topic:
what if the url of the service changes? is there a possibility to update the
service? does the uuid of the service change? how can a layer be identified
(by his name? - not every wms-layer has one).
how to handle other kinds of services (wfs/wcs/...) and their content? how to
handle secure services
the problems arise due handling many different kind of geo-objects
(services/data/coordrefsysy) in standard (which standard:-)?) conform
metadata-catalogue. in my opinion it would be better to handle services in a
kind of registry, maybe uddi, ebrim or something else. in this registries,
many different information models can be defined and a concept for handling
diefferent resources can be implemented. i speek about services, crs, id's
and other tzhings you need to implement a sdi.
the data itself can be descriped in accordance with iso19115. and you can
exchange the metadata for dataset/dataseries maybe over csw.
the things i mentioned above are only some ideas. it's worth to think about
them.
greetings
armin

Am Mittwoch 11 Februar 2009 18:51:00 schrieb Kralidis,Tom [Ontario]:

> Hi: when I publish a WMS (with, say, 4 layers) to GeoNetwork,
> the CSW publishes one service record (dc:type='service') and
> 4 dataset records (dc:type='dataset').
>
> Discovery of the service and the datasets work fine through
> querying CSW.
>
> How can one discover datasets and be able to decipher whether
> they are associated with a service?
>
> The use case here is for a client to discover WMS layers and
> be able to dynamically add them to their mapping application.
> I realize one can discover the service and invoke a
> GetCapabilities against that service, but I'd like to avoid
> that round trip seeing that the layer metadata is already in
> the catalogue.
>
> Any ideas?

Ah. It seems that setting
outputSchema="http://www.isotc211.org/2005/gmd" in the request provides
more exhaustive results.

Querying for services shows srv:operatesOn elements which show layers
available for that service.

Querying for data show a gmd:CI_OnlineResource which shows the link to
the WMS URL for that data, as well as identifying the linkage as
'OGC:WMS-1.1.1-http-get-map' within gmd:protocol.

Sorry for the noise.

Cheers

..Tom

---------------------------------------------------------------------------
--- Create and Deploy Rich Internet Apps outside the browser with
Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing
skills and code to build responsive, highly engaging applications that
combine the power of local resources and data with the reach of the web.
Download the Adobe AIR SDK and Ajax docs to start building applications
today-http://p.sf.net/sfu/adobe-com
_______________________________________________
GeoNetwork-users mailing list
GeoNetwork-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-users
GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork

--
Armin Retterath
Kompetenz- und Geschäftsstelle GDI-RP
beim LVermGeo-RP
Ferdinand-Sauerbruch-Straße 15
56073 Koblenz
Tel.: 0261/492-466
EMail: armin.retterath@anonymised.com
http://www.geoportal.rlp.de

hello tom,
some heretical questions to this topic:
what if the url of the service changes? is there a
possibility to update the
service? does the uuid of the service change?

If the URL of the service changes, the update must be done by the service provider in their GN entry, I imagine. If the URL goes down/etc., GN's harvester should catch this.

how can a layer
be identified
(by his name? - not every wms-layer has one).

By Layer/Name. I've yet to see a WMS without Layer/Name. It's the Title/Abstract/Keywords that aren't there sometimes.

how to handle other kinds of services (wfs/wcs/...) and their
content? how to
handle secure services
the problems arise due handling many different kind of geo-objects
(services/data/coordrefsysy) in standard (which standard:-)?) conform
metadata-catalogue. in my opinion it would be better to
handle services in a
kind of registry, maybe uddi, ebrim or something else. in
this registries,
many different information models can be defined and a
concept for handling
diefferent resources can be implemented. i speek about
services, crs, id's
and other tzhings you need to implement a sdi.
the data itself can be descriped in accordance with iso19115.
and you can
exchange the metadata for dataset/dataseries maybe over csw.
the things i mentioned above are only some ideas. it's worth
to think about
them.

Very good points. ebRIM does give you flexibility this way. Does/will GN support ebRIM?

The use cases I'm working off are relatively simple

- publish data
- publish services
- discover data
- discover service endpoints
- discover service endpoints
- don't touch the content: populate with as much info from OWS metadata (and as little manual user input) as possible

..Tom

greetings
armin

Am Mittwoch 11 Februar 2009 18:51:00 schrieb Kralidis,Tom [Ontario]:
> > Hi: when I publish a WMS (with, say, 4 layers) to GeoNetwork,
> > the CSW publishes one service record (dc:type='service') and
> > 4 dataset records (dc:type='dataset').
> >
> > Discovery of the service and the datasets work fine through
> > querying CSW.
> >
> > How can one discover datasets and be able to decipher whether
> > they are associated with a service?
> >
> > The use case here is for a client to discover WMS layers and
> > be able to dynamically add them to their mapping application.
> > I realize one can discover the service and invoke a
> > GetCapabilities against that service, but I'd like to avoid
> > that round trip seeing that the layer metadata is already in
> > the catalogue.
> >
> > Any ideas?
>
> Ah. It seems that setting
> outputSchema="http://www.isotc211.org/2005/gmd" in the
request provides
> more exhaustive results.
>
> Querying for services shows srv:operatesOn elements which
show layers
> available for that service.
>
> Querying for data show a gmd:CI_OnlineResource which shows
the link to
> the WMS URL for that data, as well as identifying the linkage as
> 'OGC:WMS-1.1.1-http-get-map' within gmd:protocol.
>
> Sorry for the noise.
>
> Cheers
>
> ..Tom
>
>
--------------------------------------------------------------
-------------
>--- Create and Deploy Rich Internet Apps outside the browser with
> Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers
can use existing
> skills and code to build responsive, highly engaging
applications that
> combine the power of local resources and data with the
reach of the web.
> Download the Adobe AIR SDK and Ajax docs to start building
applications
> today-http://p.sf.net/sfu/adobe-com
> _______________________________________________
> GeoNetwork-users mailing list
> GeoNetwork-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geonetwork-users
> GeoNetwork OpenSource is maintained at
> http://sourceforge.net/projects/geonetwork

--
Armin Retterath
Kompetenz- und Geschäftsstelle GDI-RP
beim LVermGeo-RP
Ferdinand-Sauerbruch-Straße 15
56073 Koblenz
Tel.: 0261/492-466
EMail: armin.retterath@anonymised.com
http://www.geoportal.rlp.de

--------------------------------------------------------------
----------------
Create and Deploy Rich Internet Apps outside the browser with
Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing
skills and code to
build responsive, highly engaging applications that combine
the power of local
resources and data with the reach of the web. Download the
Adobe AIR SDK and
Ajax docs to start building applications
today-http://p.sf.net/sfu/adobe-com
_______________________________________________
GeoNetwork-users mailing list
GeoNetwork-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-users
GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork

Work seems to be advancing along those lines:

http://trac.osgeo.org/geonetwork/wiki/ebXMLObjectModel

I understand that this new way of doing things is coming along in v 3.0. I'm not a committer or officially associated with the project, so perhaps there is a better page to look at or one of the core developers can chime in?

---
A. Soroka / Digital Scholarship Services R & D
the University of Virginia Library

On Feb 12, 2009, at 7:21 AM, Kralidis,Tom [Ontario] wrote:

Very good points. ebRIM does give you flexibility this way. Does/will GN support ebRIM?

Hi Armin,

Tom has answered some of your questions. I thought that I might add a few more theoretical answers that do not necessarily describe GN functionality.

-----Original Message-----
From: Armin Retterath [mailto:armin.retterath@anonymised.com]
Sent: Thursday, 12 February 2009 8:23 PM
To: geonetwork-users@lists.sourceforge.net
Subject: Re: [GeoNetwork-users] CSW discovery of WMS

hello tom,
some heretical questions to this topic:
what if the url of the service changes? is there a
possibility to update the
service? does the uuid of the service change?

The UUID of any metadata record should not change. If the URL changes then the URL in CI_OnlineResource should change. The metadata is still describing the same service even though the service has moved. Therefore, the metadata should be updated. A metadata records' UUID should *never* change.

how can a layer
be identified
(by his name? - not every wms-layer has one).
how to handle other kinds of services (wfs/wcs/...) and their
content? how to
handle secure services
the problems arise due handling many different kind of geo-objects
(services/data/coordrefsysy) in standard (which standard:-)?) conform
metadata-catalogue. in my opinion it would be better to
handle services in a
kind of registry, maybe uddi, ebrim or something else. in
this registries,

Services should be defined using ISO 19119. That is the standard for services.

Registers should be defined using ISO 19135. This standard includes information relating to who owns, manages, can update etc. the register. If also contains information about the dateOfLastUpdate of the register and other things that may or may not be in ISO 19115 and ISO 19119.

The register itself is a service and therefore should be described using ISO 19119 metadata. One doesn't often see this being done.

many different information models can be defined and a
concept for handling
diefferent resources can be implemented. i speek about
services, crs, id's
and other tzhings you need to implement a sdi.
the data itself can be descriped in accordance with iso19115.

Many things can be described using ISO 19115. It is *not* just for 'datasets'. People seem to overlook this. ISO 19115 can be used on any type of resource as long as the mandatory elements for that resource's metadata are available in ISO 19115. This is why ISO 19135 is for registers because there are extra fields necessary to describe the status and relations of registers. I don't know why ISO didn't just create a profile of ISO 19115 to include these extra elements. That is up to ISO TC 211 to discuss.

ISO 19135 and ISO 19115 are due for review. Does anyone believe a profile of ISO 19115 for registers and registries is better than having yet another metadata standard? Please vote.

On a similar matter, I would like GN to be a registry. Is this on the cards?

and you can
exchange the metadata for dataset/dataseries maybe over csw.
the things i mentioned above are only some ideas. it's worth
to think about
them.
greetings
armin

Thanks.

John

Am Mittwoch 11 Februar 2009 18:51:00 schrieb Kralidis,Tom [Ontario]:
> > Hi: when I publish a WMS (with, say, 4 layers) to GeoNetwork,
> > the CSW publishes one service record (dc:type='service') and
> > 4 dataset records (dc:type='dataset').
> >
> > Discovery of the service and the datasets work fine through
> > querying CSW.
> >
> > How can one discover datasets and be able to decipher whether
> > they are associated with a service?
> >
> > The use case here is for a client to discover WMS layers and
> > be able to dynamically add them to their mapping application.
> > I realize one can discover the service and invoke a
> > GetCapabilities against that service, but I'd like to avoid
> > that round trip seeing that the layer metadata is already in
> > the catalogue.
> >
> > Any ideas?
>
> Ah. It seems that setting
> outputSchema="http://www.isotc211.org/2005/gmd" in the
request provides
> more exhaustive results.
>
> Querying for services shows srv:operatesOn elements which
show layers
> available for that service.
>
> Querying for data show a gmd:CI_OnlineResource which shows
the link to
> the WMS URL for that data, as well as identifying the linkage as
> 'OGC:WMS-1.1.1-http-get-map' within gmd:protocol.
>
> Sorry for the noise.
>
> Cheers
>
> ..Tom
>
>
--------------------------------------------------------------
-------------
>--- Create and Deploy Rich Internet Apps outside the browser with
> Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers
can use existing
> skills and code to build responsive, highly engaging
applications that
> combine the power of local resources and data with the
reach of the web.
> Download the Adobe AIR SDK and Ajax docs to start building
applications
> today-http://p.sf.net/sfu/adobe-com
> _______________________________________________
> GeoNetwork-users mailing list
> GeoNetwork-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geonetwork-users
> GeoNetwork OpenSource is maintained at
> http://sourceforge.net/projects/geonetwork

--
Armin Retterath
Kompetenz- und Geschäftsstelle GDI-RP
beim LVermGeo-RP
Ferdinand-Sauerbruch-Straße 15
56073 Koblenz
Tel.: 0261/492-466
EMail: armin.retterath@anonymised.com
http://www.geoportal.rlp.de

--------------------------------------------------------------
----------------
Create and Deploy Rich Internet Apps outside the browser with
Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing
skills and code to
build responsive, highly engaging applications that combine
the power of local
resources and data with the reach of the web. Download the
Adobe AIR SDK and
Ajax docs to start building applications
today-http://p.sf.net/sfu/adobe-com
_______________________________________________
GeoNetwork-users mailing list
GeoNetwork-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-users
GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork