web services

The AASG State Geothermal Data project provides OGC (Open Geospatial Consortium, opengeospatial.org/standards) compliant WMS and WFS services per the specifications outlined by the USGIN (see the USGIN site for more detials). AASG adopted the requirements and recommendations of USGIN for networking, data sharing, and enhanced interoperability. Such recommondations include naming conventions; the following outlines AASG-adopted naming conventions which require a specific format for naming Web Services and the Layers that contain the data within that service.

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.

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.

If you decide to use GeoServer to deploy your Web Services, you
will find that part of the process includes creating an SLD or Styled Layer
Descriptor for portrayal of the data you intend to publish.A natural symbology for such layers is an ESRI
layer file format.Using this format initially presented a
problem, though; creating an SLD for data with a complicated symbology scheme,
such as a geologic map, is not trivial using XML editing software-- even if you
have a template to work from.Many
times, conversion from RGB to Hexidecimal is required for each entry in your
symbology layer.Even if one uses a
built-in formula converter in Excel (or from various websites), a large amount
of hand entry is still required.

I've been in the midst of a daily back-and-forth email discussion
with the app-schema developers on the GeoServer-Users mailing list.
Reading through the conversation may be helpful, as they've already
resolved a number of issues I've had. Here's a link to the thread:

I'm almost done building a complete mapping file that will output
GeoSciML MappedFeatures from polygon features in a database that
follows the NCGMP09 schema.
This schema, developed as part of the USGS National Cooperative
Geologic Mapping Program, is a proposed standard database schema for
the publication of single digital geologic map. An ESRI Personal
Geodatabase implementation of the NCGMP09 schema is available on the
website linked above.

At present, there is no user-interface component that helps you
configure a complex-feature WFS in GeoServer. I'm sure that it is being
worked on, but in the meantime, the configuration is done manually, by
building the appropriate directory structure and putting XML
configuration files in the right places.

This is an example of the directory structure that has to be in place.

It works! Once you get the app-schema extension installed and the tutorial data in place, it works just fine. Make sure that in your GetFeature requests you specify the outputFormat as GML3, as it won't work at all in GML2 (which GeoServer defaults to if no outputFormat is specified).

Also, be aware that the app-schema extension is only supported at WFS version 1.1.0.

Now I can move on to beginning to map my data into GeoSciML features. I'll write some more walkthrough as I put it together.