In the event that you don't want to open port 5432 to any traffic, or you don't want to configure PostgreSQL to listen to any remote traffic, or if you simply can't make it work right (that's where I am right now...) you can use SSH Tunneling to make a remote connection to the PostgreSQL instance. Here's how:
The geospatial metadata community has benefitted greatly from the
CSDGM Metadata Editor reviews created by Hugh Phillips and posted at:
As we make the transition toward implementation of an international
metadata standard, the community requested that FGDC compile
information about applications capable of creating ISO 19115 metadata.
The information on this page was compiled to address that need.
The official documentation for the app-schema extension has been revamped! There is a lot more to look through here - absolutely a must-read for anyone interested in using GeoServer to serve GeoSciML features.
Now that we know what kind of CSW services we can pull off, we need to pay more attention to creating and maintaining metadata. Right now, I just do a bunch of ETLs from our in-house data repositories (ArcSDE, Access, Excel, etc.) to CSW Insert Transaction XML files. That method is not user friendly and editing individual metadata records are a pain.
So, here are some CSW metadata editors I am looking at:
Tested with deegree-csw 2.3pre
Read the XSLT file for more information.
Attached is an example XSLT1 script to transform a WMS GetCapabilities 1.1.1 response to a CSW Insert transaction. The script is based on deegree's wms2iso19119.xsl (http://www.deegree.org/).
Note that currently it only supports WMS version 1.1.1 (<WMT_MS_Capabilities>) responses because it chokes on 1.3.0 (<WMS_Capabilities>) responses.
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.
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.
When you configure a complex feature service, you have to manually
map your data connection parameters into an XML document called a
mapping file. I found that the easiest way to make this connection is
... kind of sounds like overkill, but there's reason behind the confusion!
Imagine that you're trying to find some data. In the USGIN scheme,
in order to find data you search through CSW services, which are
catalogues full of ISO1939 metadata documents. Each of these documents
points you to a dataset or service that is somewhere, hopefully online,
for you to take a look at. These CSW services are like the card
catalogues of the digital era.
While working on thoroughly understanding CSW & metadata related
OGC and ISO standards, I can not but start questioning XML and its use
to carry and format data. After all, USGIN's goal is not just to
implement interoperable USGIN metadata and data profiles but also to
encourage their widespread adoption. The following blog entry "How XML Threatens Big Data"
by Michael Driscoll discusses some of the limitations XML poses to
dealing with large datasets and ease of use.
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