Introduction
The OpenGIS Consortium
(OGC) is a non-profit organization that promotes interoperable geoprocessing.
The goal is that geospatial applications are interoperable. This
means they search for, access and display data and services using
standard interfaces. Clients using standard interfaces need not
know much about the server. OGC defines OpenGIS as "transparent
access to heterogeneous geodata and geoprocessing resources in a
networked environment." OGC's goal is open interface specifications
enabling developers to write interoperating components providing
OpenGIS."
Representatives of software vendors, government
agencies and academic institutions that belong to OGC write requirements
for interface specifications. These requirements are published as
a Request for Proposal (RFP). Member organizations then submit proposals
for these specifications. After OGC accepts a proposal as an Implementation
Specification OGC submits it to the International
Standards Organization Technical Committee 211, ISO/TC211 for
acceptance as an ISO standard.
Interface standards are widely used outside of
the geospatial community. For example, in the Microsoft environment
a user can cut out a piece of a spreadsheet and drop it into any
conformant application (e.g., MS Word). The application will have
access to spreadsheet services and data stored on the spreadsheet.
To the user it appears as if the spreadsheet is running on the application.
What we cannot do yet is to tell our spreadsheet that column H is
Transverse Mercator coordinates and please change them to Lambert
coordinates using a coordinate transformation service on the network.
However OGC has developed several sets of
geospatial interfaces. These support interoperable commercial web
GIS applications (listed at http://www.opengis.org/cgi-bin/implement.pl).
[top]
The Abstract Model of Coordinate Transformation
The US Army struggled with poor coordinate transformation
software for years. Interoperable coordinate transformation software
would help solve this problem. With this in mind I chartered a coordinate
transformation Working Group (CT-WG) at OGC. The group developed
the Abstract Model, an object model of coordinate transformations
and coordinate systems using Unified Modeling Language (UML), a
notational language used for object oriented analysis and design.
UML is widely used and has been standardized by the Object
Modeling Group.
Figure 1 shows what a UML object class looks like.
|
Figure 1. The
class has three parts. The name of the class is in the top
part, the middle part lists attributes (or properties) of
the class and the lower part lists methods, i.e. implementable
functions. The methods, both "get" operations, are
getAxis and getUnits.
|
[top]
XML
Because more applications are using Extensible
Markup Language (XML), the CT-WG wrote an XML DTD to describe coordinate
systems and coordinate transformations (Whiteside, 1999). The DTD
does not contain all the information in the UML model, because XML
doesn't support inheritance and aggregation.
[top]
Achieving Consensus
The CT-WG struggled to reach a consensus on what
the model should look like while coordinating with our counterparts
at ISO/TC211 to maintain conformance between the ISO/TC211 model
and our own. This was not always easy.
Consider a point stored as latitude, longitude
and elevation above sea level. Latitude and longitude are referenced
to a geodetic datum while elevation is referenced to a vertical
datum.
ISO/TC211 calls this a compound coordinate reference
system, composed of two coordinate reference systems, each with
its own datum, shown in Figure 2. (The object at the pointy
end of the triangle is the superclass and the object at the other
end is the subclass.)
Some OGC members felt a compound Coordinate Reference
System (CRS) should be expressed as a single CRS with two datums
and that the model should not include a compound CRS (Figure
3). There were other proposals as well.
|
Figure 2. An ISO/TC211 view
|
|
Figure 3. An early OGC view; the diamonds
on a stick indicate strong aggregation, i.e., the datum is
part of the coordinate Reference System.
|
The CT-WG could not come to a consensus
and created a UML model that left the issue open. This UML model
is part of the OpenGIS
Abstract Specification that was included in the RFP.
OGC asked members to propose an Implementation
Specification that solves this problem. The proposed solution is
shown in Figures 4 and 5. The revised UML model was
published as part of the implementation specification.
|
Figure 4. A representation of the model
used in the Implementation Specification. The dotted line
with the arrows indicates dependency; if the datum goes away
so does the coordinate system. These relationships are not
explicit in the actual UML model, part of which is shown (in
a simplified form) in Figure 5.
|
|
Figure 5. Here there is no association
between the datum superclass and the coordinate systems superclass.
Instead there are relationships between subclasses, e.g.,
a Vertical coordinate system and a Vertical Datum. This model
uses the term Coordinate System rather than Coordinate Reference
System. Data types and object types (which are present in
the actual specification) are not shown here.
|
[top]
Implementation Model
The object model for coordinate systems includes
a number of coordinate system classes and a number of datum classes.
A Compound Coordinate System includes a
horizontal and a vertical coordinate systems and references two
datums, a horizontal (geodetic) and a vertical datum. However where
the Compound Coordinate System is 3-D ellipsoidal both the horizontal
and vertical components may reference the same datum.
A Horizontal Coordinate System is a 2-D
coordinate system that may be Projected (a cartographic projection)
or Geographic (latitude and longitude). Horizontal coordinate systems
use horizontal (geodetic) datums.
A Vertical Coordinate System is a vertical
1-D coordinate system (e.g., vertical with respect to a geoid or
ellipsoid). This references a vertical datum such as a sea level
datum or a horizontal (geodetic) datum.
|
Figure 6. This specification supports
users who create a coordinate system in any number of dimensions.
|
A Local Coordinate System references a
local datum. A Local Coordinate System cannot be transformed to
another coordinate system. Once the Local Coordinate System is georeferenced
it is no longer a Local Coordinate System. Note that a local datum
is not necessarily 2-D Cartesian.
Geocentric Coordinate Systems are 3-D Cartesian
geocentric Coordinate Systems that reference a horizontal datum.
Fitted Coordinate Systems sit "inside
another coordinate system. The fitted coordinate system can be rotated
and shifted, or use any other math transform [a mathematical function]
to inject itself into the base coordinate system" (OpenGIS
Implementation Specification, 2001). A Fitted Coordinate System
references the datum of the base Coordinate System.
This specification will also support creation
of coordinate systems of any dimension, because each of these coordinate
systems and datums have the metadata shown in Figure 6, representing
ellipsoid, geoid, prime meridian, axis, parameters (both projection
and transformation parameters) and unit (i.e. linear or angular
units). The specification also includes enumerated lists for things
like datum type (e.g., Altitude Barometric and Orthometric) and
axis orientation. Attributes in CS_Info are from ISO/TC211 Spatial
Referencing by Coordinates.
[top]
Identification
Interoperability requires a universal way to identify
a coordinate system, even if the coordinate system is unique to
a small project. A client cannot import data without knowing the
coordinate system. However, no one has volunteered to keep the list
of all coordinate systems for the entire geospatial community. The
best anyone can do is to keep a list of lists.
Our coordinate system identifier will consist
of an authority (one of the lists within the list), an edition (because
an authority may update its list) and a code (a string). The authority
is whoever assigned the string to the coordinate system. This system
is distributed, extensible and supports legacy name lists (if they
are translated into integers).
This will only work if there is a single authority.
However a Compound Coordinate System may have a vertical coordinate
system from one authority and a horizontal coordinate system from
another.
[top]
Interfaces
The specification provides interfaces for coordinate
transformation (not discussed in this paper), to create a coordinate
system and to access coordinate system metadata (i.e., attributes
or properties). The interfaces support accuracy of a transformation
and of a coordinate, but not precision of a coordinate system.
The specification originally included three profiles
(i.e., versions) with analogous functionality.
1) Microsoft Interface Definition Language (MIDL) specifications
for COM interfaces
2) Interface Definition Language (IDL) specifications for CORBA
interfaces
3) Java source specifications for Java interfaces.
OGC only released the Java interfaces.
Because most of the recent work at OGC uses HTTP,
there may be an HTTP profile at some point.
[top]
CONCLUSIONS
When widely implemented, the coordinate transformation
specification will provide a common way of identifying coordinate
systems and of accessing coordinate transformation services that
support accuracy calculation. These specifications will ease data
import. Users of compliant applications will import data without
having to be aware of the coordinate system of the imported data
because the client and server will use the same identifier for a
given coordinate system. If the application cannot transform imported
data to the native coordinate system, a compliant server will transform
the coordinates to the native coordinate system. Compliant software
will therefore import data more reliably and be able to deal more
effectively with distributed data.
When I presented this paper in March 2000 a GIS
vendor (Cadcorp Ltd, UK) had already fully implemented the COM profile
of the coordinate transformation specification. The specification
supports the software's ability to transform an image or a feature
(i.e. a feature geometry). Figure 7 shows how this transforms
an image.
|
Figure 7. A prototype Cadcorp application
transforms the image on the left, creating the image on the
right.
|
The image on the left in Figure 7 was downloaded
using the Open
GIS Web Map Server Interface Specification. Web browsers can
as of January 2002 overlay geospatial data views from servers made
by 22 software producers using this specification. Overlay will
be easier using interoperable coordinate transformation software.
As of January 2002 there have been no additional
implementations of the Coordinate Transformation specification.
OGC-compliant applications identify coordinate systems using EPSG
codes. Although the number of OGC-compliant commercial products
is growing rapidly, new products largely use HTTP interfaces. Commercialization
of the coordinate transformation interface will probably be limited
until the release of an HTTP interface.
OGC maintains the coordinate transformation specifications,
improving them based on feedback from software developers and developing
additional coordinate transformation interface specifications.
[top]
REFERENCES
2001, OpenGIS Implementation Specification: Coordinate
Transformation Services Revision 1.0, OpenGIS Project Document 01-009,
Cadcorp Ltd. http://www.opengis.org/techno/specs/01-009.zip
2000, Geographic information - Spatial referencing by coordinates,
Draft International Standard 19111, ISO/TC211 N934, http://www.opengis.org/techno/specs/01-009.pdf
1999, OGC Request 9: Core Task Force, Coordinate Transformation
Working Group, A Request for Proposals: OpenGIS Coordinate Transformation
Services, OpenGIS Consortium
1999, OpenGIS Abstract Specification, Topic 2: Spatial Reference
Systems, Version 4, Project Document 99-102r, http://www.opengis.org/techno/abstract/99-102r1.pdf
de la Beaujardiere, J., 2002, OpenGIS Implementation Specification:
Web Map Server Interfaces Implementation Specification, Version
1.1.1, OpenGIS Project Document 01-68r3, http://www.opengis.org/techno/implementation.htm
Fowler, M. and Scott, K., 1997, UML Distilled, Applying the Standard
Object Modeling Language, Addison Wesley
Whiteside, A. and Nicolai, R.1999, , Recommended Definition Data
for Coordinate Reference Systems and Coordinate Transformations,
Version 1.1.0, http://www.opengis.org/techno/discussions/01-014r5.doc
[top]
ACRONYMS AND ABBREVATIONS
- COM
- Common Object Model
- CORBA
- Common Object Request Broker Architecture
- CRS
- Coordinate Reference System
- CT-WG
- Coordinate Transformation Working Group
- DTD
- Data Type Definition
- ISO/TC211
- International Standards Organization Technical Committee 211
- OGC
- OpenGIS Consortium
- RFP
- Request For Proposal
- UML
- Unified Modeling Language
- XML
- eXtensible Markup Language
[top]
|
