Vertical and 3D coordinate reference systems

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Vertical and 3D coordinate reference systems

Jon Blower
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...)

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?  Or is it a combination of WGS84 + ELLIPSOIDAL_HEIGHT?  In other
words, is the interpretation of the ellipsoidal height dependent upon
latitude and longitude?  Or are all three axes orthogonal?

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

Thanks in advance,
Jon

--
--------------------------------------------------------------
Dr Jon Blower Tel: +44 118 378 5213 (direct line)
Technical Director Tel: +44 118 378 8741 (ESSC)
Reading e-Science Centre Fax: +44 118 378 6413
ESSC Email: [hidden email]
University of Reading
3 Earley Gate
Reading RG6 6AL, UK
--------------------------------------------------------------

-------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|

Re: Vertical and 3D coordinate reference systems

Jody Garnett
This is the third email I have had cross my desk about this subject over
the course of the week; so you are in good company Jon. It sounds like
several people are confused on this topic.

I recently found a very good primer posted by Jo Cook in her blog; it
seems to come from microsoft:
- http://msdn.microsoft.com/en-us/library/cc749633(SQL.100).aspx

Jo's blog is here:
- http://www.archaeogeek.com/blog

I found it by watching the osgeo feed:
- http://planet.osgeo.org/

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...)
>
> 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?  Or is it a combination of WGS84 + ELLIPSOIDAL_HEIGHT?  In other
> words, is the interpretation of the ellipsoidal height dependent upon
> latitude and longitude?  Or are all three axes orthogonal?
>
> (BTW does anyone know of any good CRS primers?)
>
> Thanks in advance,
> Jon
>
>  


-------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|

Re: Vertical and 3D coordinate reference systems

Adrian Custer
In reply to this post by Jon Blower
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.htm
but 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
Reply | Threaded
Open this post in threaded view
|

Re: Vertical and 3D coordinate reference systems

Martin Desruisseaux
In reply to this post by Jon Blower
Every 3D CRS except one special case (more on it later) are handled like that:

  a CompoundCRS made of a horizontalCRS + a VerticalCRS.

Example:

   ProjectedCRS  + VerticalCRS of kind "height above the ellipsoid"
   ProjectedCRS  + VerticalCRS of kind "height above the geoid"
   GeographicCRS + VerticalCRS of kind "height above the geoid"

All the above are CompoundCRS (well, maybe it would be possible to handle the
first one as a 3D ProjectedCRS, but ISO 19111 do not make any requirement about
that. Lets said that it is a CompoundCRS as well for keeping things simplier).

There is one and only one exception, which is explicitly mandated by ISO 19111:

   GeographicCRS + VerticalCRS of kind "height above the ellipsoid"

According ISO 19111, This one must NOT be express as a CompoundCRS, but shall
always be express as a 3D GeographicCRS instead (thats said a GeographicCRS
associated to a 3D EllipsoidalCS).

There is mathematical reasons for this exception. To make a short story, such 3D
GeographicCRS is a kind of pivot when applying datum shift, and we must ensure
that this pivot exists.

So if we read ISO 19111 literaly, a CompoundCRS made of GeographicCRS +
ellipsoidal height is not allowed. In practice, I have found that it is often
desirable to be able to handle such CRS as if it was a CompoundCRS (i.e.
splittable). This is why GeoAPI make a departure compared to ISO 19111 on this
one. Such kind of departure are identified in GeoAPI javadoc using a @departure
javadoc tag.

http://geoapi.sourceforge.net/snapshot/javadoc/org/opengis/referencing/datum/VerticalDatumType.html#ELLIPSOIDAL

We have provided a few convenience methods in org.geotools.referencing.CRS class
for splitting an arbitrary CRS to its horizontal and vertical components. Those
convenience methods have not be extended up to the point they can handle the
special case of 3D GeographicCRS, but this is a user request so we will do that
when time allows.

http://javadoc.geotools.fr/snapshot/org/geotools/referencing/CRS.html#getVerticalCRS(org.opengis.referencing.crs.CoordinateReferenceSystem)

As for other kind of height like "sigma level" (the ratio between sea surface
and the ocean floor), it is theorically possible to create a CompoundCRS made of
a GeographicCRS and whatever kind of CRS we want (could be a measure of
pressure). We do not have an explicit class for height like "sigma level", but I
have heard that future revision of ISO 19111 will contains a "FunctionCRS" or
something like that.


> 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?

The statement should be relaxed. DefaultVerticalCRS was first wrote in strict
ISO 19111 compliance, then we realized that a relaxation was required (WKT
parsing alone was already a strong reason as explained in the "departure from
ISO 19111" comment in GeoAPI), so we added that DefaultVerticalCRS and I forgot
to update DefaultVerticalCRS comment accordingly. Thanks for spotting that.


> On a related note, is DefaultGeographicCRS.WGS84_3D an inseparable 3D
> CRS?  Or is it a combination of WGS84 + ELLIPSOIDAL_HEIGHT?  In other
> words, is the interpretation of the ellipsoidal height dependent upon
> latitude and longitude?  Or are all three axes orthogonal?

It depends what you want to do.

DefaultGeographicCRS.WGS84_3D is separable (it is just a more complicated
operation than CompoundCRS, and our CRS.getHorizontal/VerticalCRS convenience
methods to do yet handle those case if I remember right).

Whatever the interpretation ellipsoidal height dependent upon latitude and
longitude or not depends of what you want to do. When applying a coordinate
operation, they can be treated as orthogonal only if the operation do not
involves a datum shift. For example they can be treated as orthogonal in map
projection, assuming the target ProjectedCRS uses the same datum than the source
GeographicCRS.

However if there is a datum shift (WGS84 to Clarke, etc.), then the 3 axis must
be handled together; they can not be separated. Transforming (40°N 30°W 10m) and
(40°N 30°W 1000m) will gives slightly different results even for the horizontal
part alone.

        Martin

-------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|

Re: Vertical and 3D coordinate reference systems

Martin Desruisseaux
In reply to this post by Jon Blower
Jon Blower a écrit :
> 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.

Updated GeoAPI javadoc:

http://geoapi.sourceforge.net/snapshot/javadoc/org/opengis/referencing/crs/VerticalCRS.html

        Martin

-------------------------------------------------------------------------
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