The USGIN Catalog and Data Services website (http://catalog.usgin.org) hosts several geospatial metadata catalog (CSW) and geospatial data services (WMS, WFS, WCS) implementations and clients. Although the site functions as a showcase of USGIN service implementations, the Catalog Service for the Web service (CSW - http://catalog.usgin.org/geonetwork/srv/en/csw) is a primary metadata node for the U.S. Geospatial Information Network.
This XML document tells GeoServer to treat a datastore as a
featuretype -- that is, provide it as a featuretype that can be
requested via WFS.
For the most part, this document contains information that will be
conveyed in your WFS's GetCapabilities document. Modify titles,
abstracts and bounding boxes appropriately.
You do have to make sure that you're pointing at the right namespace
and datastore by putting the correct ID's (these are the internal
GeoServer ID strings) in under the namespace and store nodes.
This XML document tells GeoServer to treat a datastore as a
featuretype -- that is, provide it as a featuretype that can be
requested via WFS.
For the most part, this document contains information that will be
conveyed in your WFS's GetCapabilities document. Modify titles,
abstracts and bounding boxes appropriately.
You do have to make sure that you're pointing at the right namespace
and datastore by putting the correct ID's (these are the internal
GeoServer ID strings) in under the namespace and store nodes.
This is a snippet from a GeoServer/App-schema mapping file. The type mapping section is where you indicate what fields in your source data go into which fields in your output data. This particular set of AttributeMappings should take polygons from an NCGMP09 dataset and output gsml:MappedFeatures.
Two caveats: First, the Join represented in the gsml:specification element will not work without the appropriate gsml:GeologicUnit featuretype also being implemented. Second, I'm not sure yet how to implement the gsml:metadata field, so that's commented out.
This XML file configures a directory as a DataStore in GeoServer. Instead of containing explicitly the information GeoServer needs to make a connection to actual data, it invokes the app-schema extension and forwards us on to a "mapping file", described elsewhere.
The id element contains GeoServer's internal identifier for this datastore
The name element contains the human-readable name of the datastore
The workspace element contains a reference to the id of the workspace to which this datastore belongs
the connectionParameters element contains three important entries:
entry key="namespace": The URI of the namespace appropriate for this datastore
entry key="url": File path to the mapping file for this datastore. Path is relative to the geoserver\data directory
entry key="dbtype": Must read "app-schema" in order to initialize the app-schema extension
By default, Geoserver's WFS server is capable of conveying only simple features. Basically, a simple feature has some number of attributes, and each attribute has a value. Think of it like a flat table, where each row represents a feature, and each column is one of the feature's attributes.