Representing a position on a globe requires not two, but three values, which on earth are generally represented by (latitude, longitude, elevation). Computers generally work in Cartesian spaces, as do our paper maps, which are easier to understand as (x,y) coordinates, hence the conflict.

The ordering followed some historical convention for spherical coordinates, which map onto geographic coordinates as follows:

geographic spherical symbol ---------- --------- ------ longitude azimuth φ latitude inclination θ elevation radius r 

The common ordering of (r, θ, φ) (which is not settled standard) simplifies to (θ, φ) when you assume we're working on a unit sphere, and hence (latitude, longitude).

Because a GIS is implemented in an environment which uses cartesian coordinates are used throughout the rest of the system, we're left with a bit of a conflict. I think the key issue is to be clear what you're using, and stick to it.

I personally prefer the Cartesian units because of their commonality elsewhere, and while the academic connections to spherical coordinates aren't to be forgotten, it isn't the pragmatic choice when implementing new systems. The (x, y) form is used internally in most spatial file formats such as WKT, Shapefiles, GeoJSON and the like -- but if you're presenting data to a lay audience, then what's right depends on what's easiest for them to understand.

Representing a position on a globe requires not two, but three values, which on earth are generally represented by (latitude, longitude, elevation). Computers generally work in Cartesian spaces, as do our paper maps, which are easier to understand as (x,y) coordinates, hence the conflict.

The ordering followed some historical convention for spherical coordinates, which map onto geographic coordinates as follows:

geographic spherical symbol ---------- --------- ------ longitude azimuth φ latitude inclination θ elevation radius r 

The common ordering of (r, θ, φ) (an ISO standard in the physics community, though not not settled elsewhere) simplifies to (θ, φ) when you assume we're working on a unit sphere, and hence (latitude, longitude).

Because a GIS is implemented in an environment which uses cartesian coordinates are used throughout the rest of the system, we're left with a bit of a conflict. I think the key issue is to be clear what you're using, and stick to it.

I personally prefer the Cartesian units because of their commonality elsewhere, and while the academic connections to spherical coordinates aren't to be forgotten, it isn't the pragmatic choice when implementing new systems. The (x, y) form is used internally in most spatial file formats such as WKT, Shapefiles, GeoJSON and the like -- but if you're presenting data to a lay audience, then what's right depends on what's easiest for them to understand.

Representing a position on a globe requires not two, but three values, which on earth are generally represented by (latitude, longitude, elevation). Computers generally work in Cartesian spaces, as do our paper maps, which are easier to understand as (x,y) coordinates, hence the conflict.

The ordering followed some historical convention for spherical coordinates, which map onto geographic coordinates as follows:

geographic spherical symbol ---------- --------- ------ longitude azimuth φ latitude inclination θ elevation radius r 

The common ordering of (r, θ, φ) (which is not settled standard) simplifies to (θ, φ) when you assume we're working on a unit sphere, and hence (latitude, longitude).

Because a GIS is implemented in an environment which uses cartesian coordinates are used throughout the rest of the system, we're left with a bit of a conflict. I think the key issue is to be clear what you're using, and stick to it: I personally prefer the Cartesian units because of their commonality elsewhere, and while the academic connections to spherical coordinates aren't to be forgotten, it isn't the pragmatic choice when implementing new systems.

Representing a position on a globe requires not two, but three values, which on earth are generally represented by (latitude, longitude, elevation). Computers generally work in Cartesian spaces, as do our paper maps, which are easier to understand as (x,y) coordinates, hence the conflict.

The ordering followed some historical convention for spherical coordinates, which map onto geographic coordinates as follows:

geographic spherical symbol ---------- --------- ------ longitude azimuth φ latitude inclination θ elevation radius r 

The common ordering of (r, θ, φ) (which is not settled standard) simplifies to (θ, φ) when you assume we're working on a unit sphere, and hence (latitude, longitude).

Because a GIS is implemented in an environment which uses cartesian coordinates are used throughout the rest of the system, we're left with a bit of a conflict. I think the key issue is to be clear what you're using, and stick to it.

I personally prefer the Cartesian units because of their commonality elsewhere, and while the academic connections to spherical coordinates aren't to be forgotten, it isn't the pragmatic choice when implementing new systems. The (x, y) form is used internally in most spatial file formats such as WKT, Shapefiles, GeoJSON and the like -- but if you're presenting data to a lay audience, then what's right depends on what's easiest for them to understand.