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.

Files: 

Please see this document for naming conventions and additional service requirement information.

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.

Testing your Web Services using Non-Proprietary GIS Software (uDig)

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.

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:

http://www.nabble.com/Geoserver-2.0-availability---included-app-schema-capabilities-td24624783.html

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.

There have already been successful implementations of GeoSciML Web Feature services, using a few different approaches.