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: [email protected]
[mailto:[email protected]] 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
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-devel
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
