geopython / MetaSearch

*** We have moved! MetaSearch is now a core QGIS plugin! (2014-11-30). See QGIS repository
https://hub.qgis.org/wiki/quantum-gis/MetaSearch
Other
4 stars 12 forks source link

Version 0.1.1: Can not add all WMS/WFS from a CSW #20

Closed ninsbl closed 10 years ago

ninsbl commented 10 years ago

Example: From CSW: http://www.geonorge.no/geonetwork/srv/no/csw? The service "Nordatlas - WMS" can be added to WMS-Connections in QGIS, while the service: "Sjøpattedyr" (marine mamals) can not . Neither "art_prioriterte WMS". The two latter have a Link: OGC:WMS-1.1.1-http-get-map While the first one had such a link: OGC:WMS Following the link of "Sjøpattedyr" in a webbrowser (http://maps.imr.no/geoserver/ows?) gives an error report. The same for "art_prioriterte WMS" (http://wms.dirnat.no/arcgis/services/art_prioriterte/mapserver/WMSServer?). However, at least the link for "Sjøpattedyr" works if entered manually to WMS in QGIS. Following the link of "Nordatlas - WMS" leads to a blank page (http://www.nordatlas.no/wms.aspx?)...

rduivenvoorde commented 10 years ago

Hi problem here is not the service url's from the metadata (they should both work), but the fact that the metadata link has a value OGC:WMS-1.1.1-http-get-map. As you can see here: https://github.com/geopython/MetaSearch/blob/master/plugin/MetaSearch/dialogs/maindialog.py#L534 we test for certain standard Values. We could off course fix this by adding 'OGC:WMS-1.1.1-http-get-map', but maybe we should first check if this is a syntaxical correct value, because if NOT we should consider this a metadata error I think.

@tomkralidis what do you think?

ninsbl commented 10 years ago

The geonorge-csw is geonetwork based... Found that, containing a list of possible gmd:protocol-entries in geonetwork: http://sourceforge.net/apps/trac/pycsw/wiki/GeoNodeNotes

SaraRT commented 10 years ago

Hi, we have the same problem because our metadata catalogue (http://www.geoportale.piemonte.it/geocatalogorp/geonetworkrp/srv/it/csw.rndt?) is based on Geonetwork too. Could be possible to adopt GN protocol types? Or to change the protocol checking condition, not to a complete precise string?

tomkralidis commented 10 years ago

thanks for the report. @rduivenvoorde fixed this in #21 so now OGC:WMS-1.1.1-http-get-map is an acceptable condition.

Having said this, the CSW link type definitions are heuristic at best :)

ninsbl commented 10 years ago

If you add OGC:WMS-1.1.1-http-get-map shouldn't you also add OGC:WMS-1.3.0-http-get-map as valid string too? In addition Geonetwork has some more possibly relavnt protocoll strings, like OGC:WCS-1.1.0-http-get-capabilities or OGC:WFS-1.0.0-http-get-capabilities which could be woth considering too. There is a more comprehensive list here: http://sourceforge.net/apps/trac/pycsw/wiki/GeoNodeNotes

tomkralidis commented 10 years ago

Thanks @ninsbl. FYI I added more types in fa5ee4d7612ca295f2d34fbb3dcb8217de3396b5. The list at http://sourceforge.net/apps/trac/pycsw/wiki/GeoNodeNotes (now at https://github.com/geopython/pycsw/wiki/Geonode-notes#wiki-protocol-enumeration-and-description) is based on the GN list at https://github.com/geonetwork/core-geonetwork/blob/develop/web/src/main/webapp/WEB-INF/data/config/schema_plugins/iso19139/loc/eng/labels.xml#L1894.

Having said this, there is discussion going on in OSGeo Cat-Interop about harmonizing link types (non-GeoNetwork implementations have their own, based on OGC URNs, INSPIRE has one, CKAN, etc.). Hopefully this ends up in a harmonization across implementations so client tools (like MetaSearch) can operate better.

Let me know if these changes are okay.