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
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:
catalina.sh
Service Deployment Using ArcGIS Server for WMS/WFS services
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
Web Service and Layer Naming Conventions
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.
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
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 http://usgin.org/sites/usgin.org/files/GeoSciML-PortrayalCookbook.pdf).
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 (http://schemas.usgin.org/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.
