ArcGIS Server and OGC Services
SDE-Trickery and Awesomeness: Data Transformations Behind-The-Scenes
Imagine that you collected geographic data in one schema and you want to provide it in some other schema. For many of us, this only happens pretty much all of the time.
For example, maybe your organization has an enterprise database which stores all the information that you have about recent, active faults. Now you want to provide that data as a WFS service with fields that conform to the ActiveFaults template being used by the AASG Geothermal Data System. Perhaps you store all your geologic map data in such a database and you want to convert it into FeatureClasses that fit into NCGMP09-style geodatabases.
Here's a nice way to convert your data formats in such a way that you only have to do it once. You can continue to make changes to your data just like you always have, and there will always be a featureclass hanging out there in the new schema which conveys the most up-to-date information that you have. The pre-requisites are:
OGC Services don't work outside local network!
A commonly overlooked step in the configuration of an ArcGIS Server is that you need to tell the server what its name is to the outside world. You see, on an internal network your computers might have names. As geologists we prefer names like "Eclogite", "Kyanite", "Harzburgite", etc... However, on the internet computers generally have more complicated names. These names are things like "services.azgs.az.gov" or "www.google.com" or "lab.usgin.org".
By default, your ArcGIS Server knows what the computer's internal name is. However, once you want to share your services with people outside that local network, you need to tell the ArcGIS Server how those other people will find it. You do this by editing a file called "rest.config". If you installed IIS and ArcGIS Server in all the default locations, you'll find this file at C:\inetpub\wwwroot\ArcGIS\rest\rest.config.
Look through the file and find all the URLs in it. Make sure that instead of using the computer's internal name, those URLs use the computers external name.
For more information, here are a couple of links:
Dynamic Content as WFS
There could be a number of reasons why you'd like to use a database view as a backend for a WFS. Perhaps your data is split across multiple tables and updated regularly. Perhaps the data is in a table without an explicit ESRI-style SHAPE field. That's the case in this example, where the geometry information is stored in a table as UTM coordinates.
