Extract metadata of layer data automatically

[armin11]

To fulfill the requirements of the european sdi (INSPIRE) the ows must have filled the MetadataURL Tags with a link to an existing iso19139 file (maybe over http-get or csw getrecordbyid request). This file should describe the data which is used to serve the layer/featuretype thru the ows. Filling this tag by hand is a very bad idea. S.o. have to write the link or s.th. else into the mapfile.

If mapserver is able to read a metadata file which is in the some directory (for database there must be another solution like extent postgis geometry_columns with some more fields) as the datafile (tiff/shape/tab/gml) it maybe easy to fill the MetadataURL automatically and serve this metadata itself via http! In such a case the needed service-data-metadata coupling (tight) as claimed by iso19119 (​http://portal.opengeospatial.org/files/?artifact_id=122) is realized and INSPIRE may have a little chance to work ;-) .

It will be an extension to the work which is done in google summer of code 2011 ​http://trac.osgeo.org/mapserver/wiki/gsoc2011. The work there is only the part which must be done to generate the service metadata records - but the coupling between data- and service-metadata is much more relevant for implementing the european sdi! The european geoportal will not work if this is not realized - the concept is a little bit to difficult :-( .

The solution maybe simple for filebased geodata. It's the same as reading and interpreting a world file. The metadata-file should have the same name but another file extension or mimetype. I don't know if there is already a type for standardized geo-metadata. Maybe we can use *.iso19139.

Please feel free to comment this ticket!

[tomkralidis]

I don't see how this requirement is different than what the functionality provides in the current codebase for LAYER/wms_metadataurl_*. We allow users to set the MetadataURL href in the mapfile to take into account both local and remote references to metadata.

[armin11]

I didn't see that someone could give a local path for wms_metadataurl and mapserver will serve this metadata record via http. Can you explain this further on please. My intention is creating a integrated metadata management system for the osgeo software which will be interoperable and which is based on the ogc standards. In such a system, the metadata is managed at the same level as the data is managed. You will have a iso19139 (metadata) file which lies in the same directory as the geodata file (e.g. shapefile). The software have to be able to check this and interpret the metadata too. In case of ows the server should automatically generate the MetadataURL tag in the ogc capabilities documents. There is no need to fill this by hand into the mapfile. If a geodata ressource, which is set in the data line of the mapfile, have an standardized metadata record assigned it must be a function of the server component to serve this information to the whole world ;-)

[tomkralidis]

Thanks for the info. So if we allow a local path to metadata, how does this exposed via HTTP, given that we allow for DATA paths to be non-HTTP accessible.

Having said this, perhaps an operation like GetLayerMetadata would be help.

LAYER
 METADATA
  "ows_metadata_path" "/path/to/metdata.xml"
  "ows_metadata_type" "ISO19115:2003"
  "ows_metadata_format" "text/xml"
 END
END

This would then be advertised as:

<MetadataURL type="ISO19115:2003">
 <Format>text/xml</Format>
 <OnlineResource xlink:type="simple" xlink:href="http://host/cgi-bin/mapserv?service=WMS&version=1.3.0&request=GetLayerMetadata&layer=foo"/>
</MetadataURL>

In which case, MapServer would return the content of ows_metadata_path, with the MIME type of ows_metadata_format.

Another benefit here would be the ability for the code to fill in the various Layer metadata from the XML document (overriding the need to fill in wms_title, etc. Which would be much cleaner for those serving up data with associated metadata.

I think something like this could apply to all OWS Capabilities (I'm thinking mapmetadata.c). This would have to be backwards compatible, of course.

Does this make sense? This would surely require an RFC, which I'd be happy to do, as I think this would be a valuable enhancement.

[tomkralidis]

Closing. This could be achieved by mapscript generating LAYER.METADATA attributes with values parsed from a given metadata document.