If you are deploying a OneGeology WMS, please visit: http://onegeology.org/wmsCookbook/home.html for more detailed requirements. For AASG naming conventions, please visit this link
When deploying a web service using ArcGIS publishing service, there are a few specifics that need to be considered when constructing the WFS and WMS Capabilites in the ArcGIS deployment wizard. This post is geared toward publishing a service for the AASG Geothermal Data Project, but the following practices are similar when deploying any USGIN-specification services using ArcGIS publishing products.
In the ArcGIS service publishing wizard or "Add New Service" wizard, you will be promted to choose Capabilities. Capabilites for both WMS and WFS are provided in AASG Geothermal Data Project services.
This blog is designed to encompass technical questions and troubleshooting for deploying and hosting USGIN services, particularly related to the AASG State Geothermal Data Project. Topics covered will included basic deployment procedures with WFS and WMS specifics, custom capablilites, handling large volume datasets, service and layers naming conventions, URIs, hosting online related files, metadata in the USGIN repository, and validating WFS and WMS services. The technical team at AZGS has encountered a need for such discussion as individual institutions and states begin hosting thier own USGIN AASG Geothermal Data Project services.
A commonly overlooked step in the configuration of an ArcGIS Server is that you need to tell the server what its name is to the outside world. You see, on an internal network your computers might have names. As geologists we prefer names like "Eclogite", "Kyanite", "Harzburgite", etc... However, on the internet computers generally have more complicated names. These names are things like "services.azgs.az.gov" or "www.google.com" or "lab.usgin.org".
By default, your ArcGIS Server knows what the computer's internal name is. However, once you want to share your services with people outside that local network, you need to tell the ArcGIS Server how those other people will find it. You do this by editing a file called "rest.config". If you installed IIS and ArcGIS Server in all the default locations, you'll find this file at C:\inetpub\wwwroot\ArcGIS\rest\rest.config.
Look through the file and find all the URLs in it. Make sure that instead of using the computer's internal name, those URLs use the computers external name.
For more information, here are a couple of links:
Converting FGDC XML metadata records for WMS and WFS services to ISO 19139 via Python and GeoNetwork
This post describes a series of Python scripts to convert FGDC XML metadata for WMS and WFS services to ISO 19139 service metadata via GeoNetwork's OGC harvest service. Here are the steps:
- Extract WMS and WFS GetCapabilities URLs from FGDC XML metadata and write them to a file.
- Create a GeoNetwork Harvest Node from extracted GetCapabilities URLs and let GeoNetwork's OGC WMS/WFS harvester create ISO 19139 metadata from GetCapabilities response. Note: the resulting ISO 19139 metadata is only as good as the one in the GetCapabilities response. In addition, GetCapabilities responses do not include all fields necessary for minimum ISO 19139 metadata.
- Copy some FGDC metadata entries (Title, Abstract, etc.) to newly created ISO 19139 metadata.
Our goal is to have working WMS and WFS metadata records in our CSW catalog that can be used to add the described services to analytical software such as ESRI's C-SW Client for ArcGIS Desktop. Following are the reasons why I am currently choosing this convoluted process instead of a direct FGDC to ISO 19139 metadata conversion:
Create a GeoNetwork OGC Harvest Node (WMS or WFS GetCapabilities to ISO 19139 metadata) through xml.harvesting.add request
GeoNetwork offers a harvest service that, among other, follows a OGC WMS or WFS GetCapabilities URL and transforms the response into an ISO 19139 metadata record. Bear in mind that the resulting ISO metadata record is only as good as the GetCapabilities response and that the metadata can never be entirely ISO 19139 conformant without dummy values due to limitations of the OGC GetCapabilities schema.
GeoNetwork offers a handy user interface to add those "GeoNetwork Harvesting Nodes" and also exposes their functionality through a even handier XML service. See chapter 19.3 on "Harvesting Services" of the GeoNetwork opensource V 2.4 The Complete Manual. Following are my notes on creating an OGC harvesting node through GeoNetwork's harvesting service.
It appears that the GeoNetwork WMS harvest selects an incorrect codeListValue for a service metadata record's srv:DCPList (Distributed Computing Platform). Currently, it enters HTTP-GET and HTTP-POST. However, there is a bit of confusion within GeoNetwork and among standards and profiles. Specifically, one could interpret a conflict between DCP in a service's GetCapabilities (OGC) and a service's metadata record (ISO):
Tested with deegree-csw 2.3pre
Read the XSLT file for more information.
Attached is an example XSLT1 script to transform a WMS GetCapabilities 1.1.1 response to a CSW Insert transaction. The script is based on deegree's wms2iso19119.xsl (http://www.deegree.org/).
Note that currently it only supports WMS version 1.1.1 (<WMT_MS_Capabilities>) responses because it chokes on 1.3.0 (<WMS_Capabilities>) responses.