Schema resolution is a thing of beauty. 

It must be noted that one important caveat to creating tables in any database structure using ArcMap is that a primary key is not indicated. We found this when the return of a GetFeature request in Geoserver using app-schemas showed that the data was not correctly mapped to the fields (or columns from the PostGIS data table). It appeared that the first column, the OBJECTID, was acutally being mapped as data and therefore put into the first column from the mapping file, which was ObservationURI. This caused more choas; as the schema was being read by Geoserver with a one-field offset, it misinterpreted some fields as not required and completely left them out of the GetFeature request. To fix this, we used PGAdmin to specify the primary key as the objectid in the table. Then, Geoserver was able to acknowledge this and leave that field's integer out of the data when the GetFeature was returned and thus giving a correct return of the data from that PostGIS table.

See the image below for the final GetFeature request example. For those using PGAdmin, specify a primary key by right-clicking the PostGIS database table and selecting "Properties". Under the "Constraints" tab, click the Add button beside "Primary Key". Give a name, such as "bht_p_key" then click the "Columns" tab to choose the appropriate field (here, the objectid). Click OK.

One thing yet to be resolved is our want for the objectid to appear in the gml:id. Doing this in the mapping file requires writing a short CQL statement (see examples in the previous comment), which did not even give us the results we wanted. It turns out that, according to Geoserver developers, "For performance reasons, we strongly recommend avoiding using CQL to generate gml:id in the mapping file as this prevents the use of database indices and the generation of efficient SQL queries."

So for now, we will continue to use the "getId()" expression recommended until a solution to using our original objectid can be found.

Also note that the name of your layer must match exactly the name of the targetElement in your mapping file, which is the element indicated in the schema. Thus, the layer name in Geoserver used for app-schema configuration must match the name specified in your schema document.

It seems that the 'New Mapping File' (above) will allow for schema resolution, which indicates the correct namespace and online schema location in the GetFeature request, along with the features of course. We're not finished yet, though; the idExpression in the mapping file now indicates for Geoserver to give each feature a gml:id, but what we really want is this ID to be indicated by the objectid that already exists in our PostGIS datatables.

The 'working' solution using getId() :

Some of our ideas to use the object id field:

Where I'd really like to see this go is the ability to use the commercial search engines (google, yahoo, bing, etc...) to index metadata that we (as data providers) expose using standard metadata formats and present search results in such a way that a search client can find and access data from within a user's application. The search client wouldn't be any more complicated that the standard file open dialogs (with a search box) currently presented by standard GUI interfaces-- maybe with an option to access a map-based interface for geospatial data.

The idea is that from within a web application like USGS the national map , or ArcGIS online, ESRIs ArcMap, MS Excel, ModFlow, GOCAD, or whatever data analysis or map browsing program you're using, you can search for data (pick your search engine --like OpenSearch enables...), get results, look at descriptions of what you found to pick the one you need, and 'get' it. Bingo, you have a new worksheet in your workbook or layer in your map layout.

To do this the search result has to return machine actionable links that client software can parse. The links need to include sufficient information that the client can pick the link that accesses a service it knows how to use and get data in a format it can use. There are a variety of specs out there for smarter links (Web Linking RFC-5988, XLink, ESIP service cast, OGC OWS context documents, ISO19115 CI_OnlineResource, atom:link...), we just need some convergence on what properties need to be associated with a link to make it machine actionable...

Here's a proposal for the properties of interest, based on the specs mentioned above...

The scripts are referenced on the various geoportal pages by adding them to www/catalog/skins/themes/lookAndFeel.jsp

In addition to other new features and stability fixes, the latest release of the CatalogConnctor can now be accessed through OpenSearch.

Project is active, developing CSW client and Server. Current release 2.1.0, on 2010 July 30.

http://spatiumcube.sourceforge.net/components.htm

Project based in Spain, University of Zaragoza, associated with CatMDedit

Notes from their web site:

* Easy way of metadata loading. The storage of metadata records is managed directly through the file system.

* The server side of the product supports:

o the compulsory operations GetCapabilities, DescribeRecord, GetRecords and GetRecordById;

o transactional operations to allow users to add, delete and modify the catalog's contents.

* implements ISO19115 and DublinCore output schemas

* Ranked searching. Metadata are indexed based on Lucene search engine http://lucene.apache.org/java/docs/, so best results are returned first.

* Tested compatibility with other catalog tools such as GI-Cat/GI-Go http://zeus.pin.unifi.it/cgi-bin/twiki/view/GIcat/WebHome, Geonetwork http://geonetwork-opensource.org/ or CatalogConnector http://sourceforge.net/projects/catalogconnecto/.

* integrated Web Client application to test catalog services compliant with CSW 2.0.2. This client offers a guided interface to facilitate the definition of CSW requests (including maps and other graphic components for query filter expressions) using both KVP, XML and SOAP protocols. This client interface is multilingual (currently available in Spanish, English, French, Portuguese, Catalan, Galician and the Basque language; it can be customized for other languages) and can be configured to request other catalog services compliant with CSW 2.0.2 developed with different technologies like GI-Cat or GeoNetwork.

should there be a browse graphic link in this profile?

If you followed the installation instructions for PostgreSQL and PostGIS that I wrote up, the shp2pgsql command is not available globally from the command line. Browse to /opt/postgis/loader before running the command shown above. This is the case for AMI's usgin-2.0 and up.

The document has been updated to include the changes mentioned below.

There are a few fixes that I have not yet placed in the PDF:

You need to place the arguments

-XX:MaxPermSize=256m
-XX:PermSize=128m

in your project run configuration in Eclipse to avoid OutOfMemory errors.

Also, to debug your project, you need to add your project in the Source tab within the run configuration for your project. To do so, navigate to Run Configurations or Debug Configurations for your project and then select the Source tab. Next, click Add and then select Java Project and select your project.

Lastly, the Eclipse/Tomcat debugger will not detect any changes to your Java code unless you run build.xml and restart Tomcat. I am not quite sure why this is true, but it is a minor annoyance.

-XX:MaxPermSize=256m
-XX:PermSize=128m
-Xmn128m
-Xms356m
-Xmx640m
-XX:+UseParallelGC