Useful guide to search term syntax for any applicaiton that's hitting a lucene index

http://lucene.apache.org/core/2_9_4/queryparsersyntax.html

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.

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):

    <ogc:Filter xmlns="http://www.opengis.net/ogc">

      <ogc:BBOX>

        <ogc:PropertyName>shape</ogc:PropertyName>

       <gml:Box srsName="EPSG:4326">

          <gml:coord>

            <gml:X>-109</gml:X>

            <gml:Y>37.00</gml:Y>

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.

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 

http://usgin.org/GenericMetadataModelDoc/index.htm

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:

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.)

Slides for talk at EGU, Vienna, April 2012, presented by SM Richard.