WFS

Using WFS with MANY features in ArcGIS

If you're using a WFS in ArcMap,  it downloads and indexes ALL the data from the service. If you're connecting to a service that has ALOT of data (>?150,000 features), my experience is that you don't actually get all the data. One solution is to put a bounding box filter on the WFS connection to restrict the data request to the area you're actually interested in. 

To do this, when you set up the WFS connection properties, and are in the 'Parameters' dialog (which you'll need to do to select the feature type from the service), put an XML bounding box filter expression in the 'XML Filter Expression'

here's a bounding box filter that works (WFS 1.0.0):

    <ogc:Filter xmlns="http://www.opengis.net/ogc">

      <ogc:BBOX>

        <ogc:PropertyName>shape</ogc:PropertyName>

       <gml:Box srsName="EPSG:4326">

          <gml:coord>

            <gml:X>-109</gml:X>

            <gml:Y>37.00</gml:Y>

Service Deployment Using ArcGIS Server for WMS/WFS services

Once you have your data in the appropriate format, and the required fields populated, the next step is to create a service for the data.  When it comes to AASG or OneGeology services, there are naming conventions and metadata rules.

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

Creating WFS / WMS capabilites using ArcGIS service publishing wizard

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.

WMS

Best Practices for USGIN Web Service Hosting

Tips, techniques, and frequently asked questions for hosting AASG Geothermal Data Web Map Services and Web Feature 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.

Data Interchange Document XML Schema Validation

Validation of XML data interchange documents with normative schemas using free, open-source software (XML Explorer)

One of the objectives of the US Geoscience Information Network (USGIN) is to establish a community of practice for developing, documenting, adopting, and using standard document encoding for data interchange. The technology for encoding schemes is evolving continuously, and current practice is to use XML encoding with data schema defined by XML schema.

Content model discussion

Community site for comments on development of content models and encoding for information intechange

OGC Services don't work outside local network!

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:

  1. Extract WMS and WFS GetCapabilities URLs from FGDC XML metadata and write them to a file.
  2. 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.
  3. 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.

Syndicate content