The CI_OnlineResource element is used in a variety of
contexts in ISO19115 content.
This complex-content-element provides a linkage to some online resource related
to the metadata or the described context resource. It is thus analogous to
atom:link (IETF RFC-4287) or the link element described in IETF RFC-5988. For links that locate online documents accessible
using standard browser and file type resolution technology, the link can be as
simple as a single URL element that retrieves a representation of the resource.
There are many other kinds of related resources that the onlineResource element
may point to, including web services that provide access to a dataset resource,
metadata for related or source resources, specifications for standards or
extensions to standards.
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
*Only works for 10.x and up geodatabases. You need to upgrade
your gdb to 10.x if you are using an older geodatabase.
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:
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):
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:
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.
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.
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.
I have built a UML
model (using Enterprise Architect 7.5 tool) of metadata
content that is based on ISO19115/19119, but attempts to clean up some
of the logical incoherence and inscrutable element labeling in those
specifications, as well as adding hooks for more detailed information on specific resource types and resource lineage.
The attached files include a zip archive of the Enterprise Architect-generated html report on the UML model; unzip to a directory and start on the index.htm page.
The EA document (zipped into GenericCompleteMetadataConceptualModel.zip) is the actual UML model. You'll need EA 7.5 or later to open it. The project contains a Metadata package, within which the 'GenericMetadataModel' package contains the actual model. The other packages include UML models for related ISO specifications, elements of which have been incorporated (copied, renamed, modified -- not imported) into the generic model. They are included for reference.
The html documentation generated by Enterprise Architect can also be viewed at
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.
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).
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
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.
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.)
I've made a new version of the URI redirection engine that runs in Django (see the original post here). The tool allows you to provide a list of URI patterns that identify specific resources, and redirect traffic that matches that pattern to a URL where a representation of the resource exists. It allows for content-negotiation, and the new version also begins to build infrastructure by which various instances of the application can communicate with each other.
Each instance of the application is informed about the existence of various registers, which are essentially sets of URIs. The application may or may not know how to resolve URIs that are a part of any given register, but can send incoming requests to others servers capable of resolving that register's URIs.
A rather large power point stack, for a one hour presenation on USGIN web services and their use for the National Geothermal Data System. Presented at the kick off meeting in Boise, ID, November 3, 2009 by SM Richard.
USGIN Amazon Virtual Server Development | 18 Posts | Invite only Documenting the process of development of a Web Server in the Amazon EC2 environment. Software installations tailored to the requirements for USGIN