[postgis-users] [postgis-devel] Buck Rogers and the 3rd Dimension

[Gerald Creager]

Paragon Corporation wrote:
> Paul,
> I always wondered that - I guess 2 questions I would ask
> 
> 1) How do other spatial databases handle this, or do they not really do
> anything with the z coordinate anyway especially with polar coords? Seems to
> me SQL Server doesn't do anything with it but haven't tested it enough to be
> absolutely sure.
> But not sure about Oracle, Informix, IBM (or maybe for their geodetic calcs
> they ignore it)
> 
> 2) The instruments collecting this stuff, I guess gps and what-not -- how do
> they collect this extra coordinate or is it always a separate field and what
> measurement is it in?  I suppose if they always measure altitude in meters,
> then we would for users have to come up with some mechanism to allow them to
> convert it to degrees if you assume all axis are the same type (polar).

Determination of vertical could take a bit of explaining to do, but I'll 
give it a shot for GPS instruments and "traditional" survey hardware.

Traditional survey: Find a benchmark that has been established using 
conventional means, is of high order, and has had multiple surveying 
"loops" tied to several other benchmarks (note, I'm not simply talking 
"survey monument" here; a benchmark is significant for height...). For 
low-order height estimates, run a level line or loop from the benchmark 
to the point of interest, or if looking for, e.g., contours, set up a 
grid and take level measurements (which are actually delta's of the 
original testing level point) for each node on the grid.

GPS keeps track of its position with respect to a 3D model of the earth 
that's devoid of surface roughness: the ellipsoid (or spheroid, if one 
prefers).  This is the surface of an ellipse rotated about its semimajor 
axis.  GPS always references this mathematical model for its 
trilaterated location, using signal s from at least 3 satellites for 2D 
(assumed on the ellipsoid surface), or 4 satellites for a 3D position 
that references the ellipsoid.  Ignoring the issues with trilateration, 
accuracy and such, let's talk about the sort of information a GPS 
receiver provides in its height estimate.

Orthometric height is referenced to an undulating surface, the geoid, 
that is based on gravity.  Like the ellipsoid, this is a model surface, 
and isn't detectable by mere mortals.  Orthometric height is what we 
refer to when we measure heights today using NAVD-88 (the North American 
Vertical Datum of 1988, as periodically adjusted; WGS84 has both a datum 
and ellipsoid that are strongly correlated to NAD83 and NAVD-88 but are 
adjusted more frequently).  Most high end GPS receivers, used for 
surveying, don't even bother trying to maintain a geoid database of any 
significance, but some handheld/consumer receivers do.  The orthometric 
height, which is similar to, but not the same as "mean sea level" (a 
measure fraught with scary practices) and is the norm for geodetic 
surveying in the US.  Orthometric height is an algebraic sum or 
difference of the difference between the geoid and ellipsoid at a given 
point, and the height above or below the ellipsoid.

In practice, the most accurate measure the GPS can provide you is the 
height above ellipsoid, and then leave it to you to determine the 
geoid/ellipsoid separation, and perform the rather mundane algebra to 
determine the height.

In point of fact, most receivers DO calculate the position in an 
earth-centric coordinate system, and convert it to [insert 
datum/ellipsoid here].  However, it's the rare receiver, in my 
experience, that could provide you with that as a simple output.

gerry

> I would say the whole spatial ref model falls apart anyway since it seems to
> me it completely ignores this (questionably non-polar dimension so if you
> think in polar its not as clear cut as the planar. that Z is an unknown so
> the best answer is to do nothing with it and take it literally . 

> -----Original Message-----
> From: postgis-devel-bounces at postgis.refractions.net
> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Paul
> Ramsey
> Sent: Saturday, October 31, 2009 1:14 AM
> To: PostGIS Development Discussion
> Subject: [postgis-devel] Buck Rogers and the 3rd Dimension
> 
> While updating the old geometry spheroid functions, I noted the existence of
> a length3d_spheroid() variant. It is actually the default call for
> st_length_spheroid() as it happens.
> 
> The kinds of things you have to pass into this function to get sensible
> results are pretty restricted, as it turns out. For example,
> 
> st_length_spheroid('LINESTRING(0 0 1000, 0 0.001 1001)', 'SPHEROID["WGS84",
> 6378137,298.257222101]')
> 
> Note that the units of Z are meters while the units of X and Y are degrees.
> To get a sensible answer out, in fact, the units of your altitude have to
> match the units of your spheroid.
> 
> Anyhow, my geography routines right now are strictly 2D so I haven't
> renovated this particular variant, but it's put my in the mind of wondering
> what the right thing to do is, in geography. If I get a '3D'
> geography, do I assume the third dimension is in meters? Do I calculate a
> "3D" length (or distance?) by default? That's what our geometry routines do
> right now, and it hasn't caused harm yet.
> 
> It seems like an interesting submerged assumption in the geodetic space,
> that the units of your extra dimension will match the units of the axes of
> your spheroid.
> 
> As I recall, we added this function many years back, to calculate as exactly
> as possible the drive lengths of roads in a road network (BC is a hilly
> place). Not sure if anyone else is using it. And still not sure if a
> "length3d_spheroid()" function is a wise proposition in general, given the
> required assumptions.
> 
> P.
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> 
> 
> 
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users