Best Practices for USGIN Web Service Hosting

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.

Help! My GeoServer Doesn’t Like My App-Schema!


Help! My GeoServer Doesn’t Like My App-Schema!

An in depth look at a GeoServer 2.2 workspace that utilizes the app-schema extension

<*> I don't like how this blog post turned out! You can get the "better" formatted version as a PDF here. <*>


Convert File GDB to PostGIS Database

HowTo:File GDB Feature to PostGIS Database

The goal of this post is to get our data from a File GDB to a format that GeoServer can use, specifically a PostGIS GDB. If we try and use a shapefile, the field names will be truncated and this will invalidate your schema that you have worked so hard to conform to the USGIN schema standards.

*Only works for 10.x and up geodatabases. You need to upgrade your gdb to 10.x if you are using an older geodatabase.

Geoserver App-Schema Set-Up: In Progress

One hurdle to using Geoserver to deploy AASG Geothermal Data services is the resolution of schemas. Creating additonal configuration files for Geoserver allows the use of "app-schemas" which will automatically download the indicated web-accessible schema (.xsd) and be referenced in the GetFeature request. This would solve a problem with service deployment using ArcGIS, where custom schema locations is necessary.

This blog will document the problems and break-throughs I've had so far in implementing Geoserver app-schemas. I have not yet been able to get schema resolution, but would like to make a post so that others can take into account my work thus far and chime in about other ideas or advances. This work is based on Tomcat running Geoserver, set up on an Oracle VM VirtualBox. The data for the services are pulled from a PostGIS database.


A few housekeeping tips I learned the hard way, for starters:

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: for more detailed requirements.  For AASG naming conventions, please visit this link

Web Service and Layer Naming Conventions

The AASG State Geothermal Data project provides OGC (Open Geospatial Consortium, 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.

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.


Validating your WFS and WMS services

After a web service has been deployed, testing must be done to ensure that the service will work in the system, that is, be interoperable and available to end users. This group post will discuss using WFS GetFeature requests and WMS GetCapabilities requests for service validation. All OGC (Open Geospatial Consortium) services offer these requests which return an XML representation of the data. Some of the following information is taken from GeoSciML Portrayal Cookbook (available in full here 

GetCapabilities Requests

If your service is deployed using ArcMap products, the request starts from your service rest page. Scroll to the "WFS" and "WMS" links on the service rest page. The URL given from these links is the Get Capabilities request, which consists of a service endpoint part, and the OGC request part:

ArcGIS-generated fields and AASG content model fields order and type

When deploying your service using ArcMap products, two fields are automatically generated. These are the OBJECTID and SHAPE fields. The XML schemas ( that are associated with each AASG content model have a very specific ordering of the fields from that content model, and included in this specific order are the ArcMap-generated fields.

To acheive validation of your WFS service, and for your service's data to be interoperable and available within the system, the fields must be in the specific spelling, order, and data type that are assigned in the XML schema. These are usual errors we find when checking the WFS validation of hosted services.

Even though every content model has different fields, the ArcMap-generated fields are reliably in the same place in the field order. OBJECTID must come just before all the content model fields, and SHAPE must come directly after all the content model fields. (A "lax" function does allow Shape_length or Shape_Area or other fields to come after SHAPE field.)

Implementation of a Content Process “lax” function Element for AASG Schemas

Discussion of using the “lax” function in Schema Documents

We’ve recently changed how we are structuring our XSD schemas by adding a “lax” process function element at the end of the sequence.  The ‘lax’ function, or ‘any Element’ function, can be specified by the author of the schema document, and enables additional elements not specified by the schema to be included.

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.

Syndicate content