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.