On Wed, 2008-08-06 at 21:48 +0100, Jon Blower wrote:

> Hi all,

>

> I'm trying to get my head around vertical and 3D coordinate reference

> systems. Not being from a GIS background, I'm not too familiar with

> how CRSs are constructed. I'm looking for a way to represent

> oceanographic and meteorological measurements, which are typically

> captured as longitude,latitude,height (or depth). These heights are

> sometimes relative to the geoid, and sometimes relative to the

> ellipsoid (presumed to be WGS84). As a further complication,

> numerical models are often run on a spherical earth, so "height" in

> this case is relative to a spherical datum. (I'm not even going to

> mention - for the moment - things that are measured relative to

> instantaneous sea surface...)

All these are possible. The only blocker in geotools is making heights

non-linear on distance, say using a 'height based on barometric

pressure'. In truth, this latter would have to be time varying since the

baseline pressure evolves in time and then you would have to calculate

metric height off of that model---i.e. a headache bigger even than

Geoidal heights. Geotools sticks to axes based on distance metrics for

now.

What you call 'spherical' we do not because the word is reserved for a

different beast, where coordinates are in a different system (one angle

is off of the rotational axis of the body rather than against the

equatorial plane). What you call 'spherical', iso calls 'degenerate

ellipsoid' i.e. it's merely ellipsoidal with (major axis == minor axis).

>

> I was interested by this statement in the javadoc for

> DefaultVerticalCRS: "ellipsoidal heights (h) cannot be captured in a

> vertical coordinate reference system. Ellipsoidal heights cannot exist

> independently, but only as inseparable part of a 3D coordinate tuple

> defined in a geographic 3D coordinate reference system." However, the

> DefaultVerticalCRS class itself has the ELLIPSOIDAL_HEIGHT property (a

> 1D vertical CRS), which would seem to contradict this statement.

> Should the ELLIPSOIDAL_HEIGHT CRS be used with caution? Is it an

> approximation?

>

> On a related note, is DefaultGeographicCRS.WGS84_3D an inseparable 3D

> CRS?

Yes, that's what the language above meant. You can't, for a 3D

ellipsoidal CRS, make a compound crs out of a 2D CRS (say WGS84) and a

1D vertical ellipsoidal height CRS. Well, more to the point, you could

but then would not conform with the ISO specification so Geotools

doesn't let you. However, it's quite legitimate to have an axis 'height

above ellipsoid' perhaps merely for some attribute.

(Your examination does raise the issue that this independent

axis should require some more metadata, i.e. the ellipsoid for

which it exists and the latitude where it is valid. Perhaps that

is why ISO doesn't let us define this separately then combine it

with the 2D horizontal.)

> Or is it a combination of WGS84 + ELLIPSOIDAL_HEIGHT? In other

> words, is the interpretation of the ellipsoidal height dependent upon

> latitude and longitude?

Yes and no. The value of the ellipsoidal height is truly independent but

its ultimate meaning is dependent. Ellipsoidal height is a real height

on the line orthogonal to the ellipsoid surface. The distance of the

surface itself from the mythical 'center' of the earth does depend on

location so the meaning of the value requires: the value, a reference

ellipsoid and a latitude of measurement. (Note in passing, that Geoidal

height is a different beast which, properly, is measured along a

non-linear axis which follows the curvilinear line of maximal change in

the earth's gravity field.)

> Or are all three axes orthogonal?

yes, but in a Riemannian space so...

>

> (BTW does anyone know of any good CRS primers?)

Bowditch (The American Practical Navigator, NIMA, Pub.No.9), Chapter 2

gives a good start at the question.

Otherwise there is a smattering of sites around the web which each try

to get started but are all missing some key pieces of the puzzle.

To really understand this stuff you have to think historically as if you

were given a budget and a mandate to decide where things were. You'll

conclude pretty quickly that there are only 2 locations 'here' and

'there' with the 'there' being arbitrarily complex and that all

locational schemes require at least one shared identifier to use as a

starting point (the datum).

So remember that no one has true knowledge we only have relative

measures off of some location(s) that we designate as our starting

point. This used to be a place that we decorated with, say, a bronze

plaque:

http://www.photolib.noaa.gov/htmls/cgs00555.htmbut now is the center of certain radio-telescope antennae which time the

incoming signals from quasars and thereby determine their relative

positions from each other along a bunch of different vectors. (Well,

here the math gets complex since the measures are not instantaneous and

the antennae are rotating and you need to line up the doppler-shifted

signals and at this level of precisions the continents drift so you have

to re-adjust things regularly and ...)

A while back, I sent a tongue in cheek message out to list along these

lines, added below. Eventually, I hope to get this all into our docs so

we can all agree about what a datum really, truly *is* (datum---a set of

real locations) notwithstanding the sloppy way we use the term in this

ISO process (iso datum---a way of describing all locations with

coordinates based on an identifier for a real 'datum' and a coordinate

space).

>

> Thanks in advance,

> Jon

>

***********************************

From: Adrian Custer <

[hidden email]>

To: Jody Garnett <

[hidden email]>

Cc: Edgar Soldin <

[hidden email]>,

[hidden email],

[hidden email]
Subject: Bursa-wolf parameters [WAS: Projection with Geotools2 CRS]

Date: Mon, 17 Sep 2007 22:14:28 +0200

On Mon, 2007-09-17 at 10:46 -0700, Jody Garnett wrote:

> Edgar Soldin wrote:

> > just one question .. what is this bursa wolf parameter option?

...

> My impression is that this is scary math I never quite understood.

The

> javadocs describe it all detail (and have links to papers etc..).

Well, Bursa was a 9 year old bicyclist from the Alps and...no, no, no, i

lie. Actually it's not particularly scary math and quite easy to

understand. All you really need to remember is that no one has ever been

to the center of the earth.

So everyone started surveying (mostly so the repressive central

governments could exploit taxes from people and have lots of jolly wars

where people could slog through the mud and kill each other so they'd be

blood and suffering for all). Each group started from some random place

on the surface of the earth. Right away, it becomes obvious to everyone

that euclidean rules don't work so well. Some didn't care so much since

taxes are basically arbitrary anyway and getting serious about it means

you'd have to walk through fields and woods and get lots of mud on your

shoes. Others kept at it and resorted to spherical geometry. Once you

start doing that precisely and at continental scales you realize that

doesn't really work either so you decide to try the next hardest thing,

an ellipsoid of rotation. Now how do you know which one to choose? Well

you pick one that minimizes your squared errors. All good and nice but

(1) you are surveying the ground which is anything but an ellipsoid

since it has all those ditches you keep falling into and that keep

getting your clothes covered in mud and (2) you are not perfect

especially with all that mud on your paper. So you have a bunch of

errors. Well everyone that does this comes up with lots of different

ellipsoids that work really nice for their data and everyone is sure

they clearly have found the 'one true ellipsoid' and they decide to use

that for all their work. Then everyone guesses where they actually are

on each of their particular ellipsoids which involves lots of going

outside at night and looking up from the mud at the stars. But then it's

not like the edges of each survey was nice and level on these ellipsoids

either --- think of the eastern USA. You can start nice and clean and

warm and dry at an inn in Boston on the edge of the sea drinking clam

chowder and having a good time but a few months later it will be bitter,

bitter cold in that tiny town of Denver because you are somewhere like a

mile high up in the air and you're wet and covered in mud from slogging

through the plains in a snowstorm. So you've got a pretty good idea that

your data is on a major slant but, well, you'll do your best to make up

for it but it really doesn't help the effort any, especially what with

all that mud that's still itching in your hair. So your errors may be a

wee bit big but hey it's all right: it's good enough to wage lots of

good wars with lots of mud and blood and to keep collecting lots of

taxes so no one cares too much.

Fast forward to more recent times where some people want to talk to lots

of different governments and work with lots of different data. They take

everyone's guess and try to line them up. Well it turns out, when you

try to line everything up, that the center points of all the different

ellipses aren't really the same points and even the orientation of the

three axes are all a bit off because of how everyone guessed where their

were on their ellipsoids. So now, to go from one data set to another so

they line up "the best," you need estimates of how much to rotate each

of the axes and how to shift the center point around; all this beyond

even the obvious stuff of changing between the different definition of

all those "one true" ellipsoids.

When you do this mathematically, you need a bunch of parameters: these

now have the names of the wolf and the bursa. Generally, you can only

come up with good parameters if you have lots of data to compare and

some good software to do the comparing. That's what the EPSG did for

everyone. The guys in the pickup trucks that went out looking for oil

kept falling into ditches along the way and getting mud on their faces

but when they got back to the office they had a good sense of what lined

up with what and could say: "yep, that hill there is the same as this

squiggle here and there's this big ditch right here that cost us our

third flat tire and..." So they collected as much data as they could and

compared it and came up with a database of parameters by which you go

from one data set to another. So that's it. That's why we use their

data; we don't have to fall in any ditches and can avoid getting mud on

our clothes. They give us their parameters and we can mostly line up

data from one survey against data from another. But you do need some

good parameters because the earlier folk had a harder time of the mud

and the data they created don't just line up the way we would like them

to.

Actually doing the math is a bit harder but the concept is pretty

straight forward: geographic data all ultimately gets tied into points

on the earth surface and that requires estimating where the points

really are and how they line up on the estimated ellipsoid being used.

That in turn means none of ellipsoids quite line up and we need

parameters to move between them.

--adrian

-------------------------------------------------------------------------

This SF.Net email is sponsored by the Moblin Your Move Developer's challenge

Build the coolest Linux based applications with Moblin SDK & win great prizes

Grand prize is a trip for two to an Open Source event anywhere in the world

http://moblin-contest.org/redirect.php?banner_id=100&url=/_______________________________________________

Geotools-gt2-users mailing list

[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users