The devil, as the old saying goes, is in the details.
As more and more users and developers of geospatial services and
content come from non-geo backgrounds, the geo-professional's attention
to those details becomes extremely important. Arguably the oldest and
most important of these "details" in our industry is the method of
defining location itself.
Mankind has been making maps for millennia, but only in the last 236
years (since John Harrison invented the marine chronometer) have we
actually been able to do so covering large areas over water and
retaining accuracy. Prior to that, only latitude (north and south)
could be measured with great accuracy. Not until the 1770s was a mobile
timepiece able to keep accurate enough time to allow calculation of
longitude (east and west). The key point is that geographers (and
cartographers and geodesists) measured latitude first and that is why
they express location in terms of latitude and longitude, in that
order, when applied to coordinates.
A two-axis system of east-west and north-south was defined using the
algebra coordinate system created by mathematician René
Descartes in the 1600s. In this Cartesian coordinate system, the
tradition is to use (x, y) as the order of the coordinate pair locating
a point on a plane. But when north is up - the predominant (though not
only) pattern for maps since Ptolemy made maps of ancient Egypt - x
measures east-west and y measures north-south. That is, the
latitude–longitude order favored by geographers is y, x. So the axis
confusion we deal with today has, itself, a longstanding history dating
back to the first efforts to relate two different reference systems
with two methods of defining the axes. As long as people communicate
clearly and accurately the characteristics of the axis-systems in use -
"truth in advertising" - the confusion is minimized.
When geodesists connect coordinate systems to the Earth by specifying a
datum (locations on the Earth for the axes), we in OGC call that a
Coordinate Reference System (CRS). The equator was a natural for a
worldwide datum on the east-west axis and over time the Greenwich
Meridian, running through Greenwich, U.K., has become the most common
location for the north-south axis.
Geodesists, who came into their own in the Age of Exploration, include
a third axis in their descriptions of location. They deal with
latitude, longitude and altitude, in that order, and call them x, y and
z. And thus confusion increases.
Moving to the use of computers for mapping, we can add two more sets of
axes. The first has to do with computer output devices: printers and
monitors which start at the top and print or display line by line to
the bottom. That is, the y-axis for these devices has no negative
region and is positive going down. (And we won't even address the fact
that some printers print left to right, while others print right to
left.)
The second computer-related set of axes has to do with the formats for
data storage. Digital Elevation Models (DEM) and Digital Terrain
Elevation Data (DTED) have an origin in the lower left corner, traverse
up, drop to the bottom of the second column and go up, and so on.
Satellite data are typically formatted, like the output devices, with
the origin in the upper left, providing yet another case; however,
various ways of encoding the multiple readings from a single ground
location have been used. A single row of points may represent all
measurements for one part of the spectrum (say blue), and the next row
may be the measurements for those same ground locations for another
part of the spectrum (say green). Another format involves storing all
measurements for one part of the spectrum in one file, and all
measurements for another part of the spectrum in another file.
Thus the answer to the question posed in the title is that computer
mapping projects probably involve four or five sets of axes. While any
transformation to move data from one set of axes to another is
straightforward, care is needed to keep from accidentally transposing
axes.
In the transition from paper maps to computer mapping, people who
programmed computers were much more likely to be versed in the
traditions of mathematics and x, y than in the traditions of geography
with latitude before longitude, and thus computer mapping and its
more-sophisticated offspring, Geographic Information Systems, are
subject to axis confusion.
And with that as background, we arrive at OGC standards! Since the
point of IT standards is to have computer programs and data
interoperable, in the early days of computer mapping, graphics
programmers were in the trenches writing the first standards, and they
ordered the coordinates x, y in the mathematical tradition. But OGC
standards developed by the membership are for the benefit of developers
and users in many fields of study. As such, we need to abide by
international best practice, harmonize with standards defined in other
standards organizations, and meet the requirements of the community.
Early on, the OGC members recognized the need to be able to
specify and use more than one coordinate reference system (CRS). Why,
you ask? Because the mathematical description for any given CRS used to
describe the shape of the earth (called an ellipsoid) is not precise
enough to be highly accurate all over the globe.
To simplify OGC work on specifying CRS, the OGC members agreed to use
the CRSs as defined by an existing standards body: the European
Petroleum Survey Group (EPSG), now the International Association of Oil
& Gas producers (OGP). In the
EPSG database, each projection explicitly specifies its own axis order.
OGC's initial work on the Web Map Service interface standard used WGS
84 as the CRS example of choice. WGS 2d is EPSG code 4326 and specifies
the axis-order latitude, then longitude. The OGC, however, used the
EPSG 4326 name and then reversed the order to x, y - not a
good thing for a standards organization to take a "standard" and then
be the only guy in the world who uses it in a non-standard way! So, in
a very real sense, the OGC created additional confusion! In June
2005, the OGC members formally agreed that for new standards,
coordinate values shall be listed in the axis order of the specified
coordinate reference system (CRS). When existing standards are subject
to revision, the axis-order issue will be considered, and any necessary
change will be made to bring it into conformity with the requirement
that coordinate values shall be listed in the axis order of the CRS it
references.
With Web Map Service (WMS) Version
1.3 (the current version, adopted in 2006), the OGC standard would also
become an ISO standard. This meant that using EPSG 4326 with the order
reversed was not an option. The creative fix: OGC introduced its own
CRS, OGC 4326, which used the same parameters as the EPSG one, but the
peculiar axis order.
In the meantime, Web Feature Service (WFS) in conjunction with
OGC Web Service (OWS) Common fixed the problem, allowing all CRSs to
express their own axis order.
While these developments were underway, the EPSG database was updated
to allow local transformations that may involve re-ordering of axes to
be specified in such a way as to be valid. As per ISO 19111, Spatial
Referencing by Coordinates, these are termed "derived CRSs."
Finally, in early 2008, the OGC Architecture Board and the Membership
revisited the axis order issue. The result of this latest effort is a
new OGC policy statement titled, "Axis Order Policy and
Recommendations." This document is available on OGC
Network.
Because the geospatial community draws on the heritage and legacies of
geography, geodesy, mathematics, computer science and other fields,
only one solution to the axis-order issue is realistic: explicit
specification of the axis-order in use. This is a kind of "truth in
advertising" requirement. Developers who want users to select their
software and applications will take care to ensure information about
the axis order is readily available. And users who want to be sure
their work is meaningful will take care to inform themselves about the
axis order associated with all software and data in a project.
I personally have no preference for any particular axis-order scheme,
but failure to deliver what one advertises is not acceptable. More and
more users are totally reliant on geospatial data and services for
their success and safety, and all chances for confusion must be
eliminated.