8 Relationship to Simple Features
“Simple Features” is an earlier interface specification adopted by OGC. The Simple Features specification includes two packages: Geometry and Spatial Reference Systems SRS.
The CS package in this specification covers the same ground as the Simple Features SRS package. The SRS package was based on a subset of the coordinate systems in the EPSG
abstract model. The CS package extends this abstract model to encompass all EPSG coordinate systems, including vertical coordinate systems and compound coordinate systems. CS then goes
further to handle more than 3 dimensions and ungeoreferenced coordinate systems.
8.1 Compatibility of Well-Known Text
The CS package keeps the WKT serializing concept of Simple Features SRS. In fact, all Simple Features SRS Well-Known Text strings are valid in CS, and have exactly the same
meaning. This ensures that all stored Simple Features SRS data will be compatible with the new CS package.
The Geographic Transform interface in the Simple Features SRS package has been absorbed into the CT package as a range of different math transforms e.g. Molodenski. This does not
affect WKT compatibility, since the WKT for geographic transformations was never defined.
8.2 Name changes from SF-SRS to CS
The CS package basically just renames all the Simple Features SRS interfaces by adding the “CS_” prefix, and then removes all the mutating methods. The functionality of the mutating
methods e.g. changing the longitude of a Prime Meridian has been moved into the enlarged factory interfaces. A couple of the old Simple Features interfaces have been moved into other
packages see below. Since most of the method names have been left unchanged from Simple Features, it is possible
for objects to support both sets of interfaces. For example, a geographic coordinate system object e.g. MyGCS can easily support both CS_GeographicCoordinateSystem from CS and
IGeographicCoordinateSystem from SF. This means that the object MyGCS can be used with code that expects Simple Features interfaces or code that expects CS interfaces.
One notable name change is the method to get an entity’s well-known text. For example, in COM Simple Features this property was “WellKnownText”, whereas in CS the property is called “WKT”.
This is done deliberately, so a new object which supports both SF and CS interfaces can tell whether it is being asked for an SF compatible WKT string, or a CS compatible WKT string. If it is
asked for an SF compatible string then it should not include the new optional clauses. If the object is not part of the SF abstract model e.g. a 3D coordinate system then it should either not
support the SF interfaces, or it should fail the WellKnownText method.
8.3 Authority Codes
The CS and CT packages use a String for the Authority Code, whereas Simple Features used an Integer. This change was made for compatibility with those authorities that use String codes.
As a result, the Simple Features ISpatialReferenceInfo “Code” property will fail if the CS_Info “AuthorityCode” property cannot be represented as an integer.
Page 24 of 117 OGC Document Number 01-009
9 Processes
Common processes are shown here as scenarios. Some scenarios refer to previous scenarios, so you may find it convenient to read them in order.
9.1 Create a NAD27 California Zone 1 CS
