Buck Rogers and the 3rd Dimension

[Paul Ramsey-4]

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@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

[Paragon Corporation-2]

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

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 .

Thanks,
Regina

-----Original Message-----
From: postgis-devel-bounces@...
[mailto:postgis-devel-bounces@...] 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@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel



_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

[Paul Ramsey-3]

On Sat, Oct 31, 2009 at 7:59 AM, Paragon Corporation <lr@...> wrote:
> 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)

If anyone can answer this, I'd love to know...

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

Again, if anyone can answer this...

I think I can wrap my head around POINT(lon lat altitude), since, as
with POINT(x y z) there is an underlying SRID which defines the units.
In the case of POINT(lon lat altitude) that SRID specifies a spheroid,
which supplies the units for the altitude (the units of the
major/minor axes). So I think I can z-enable my geography handling
code with a semi-clear conscience.

We still have the question of 2.5D versus 3D answers though... does a
horizontal line 1000 meters above another line intersect that second
line? Yes in 2D, no in 3D... for people working in pure 2D there is no
problem, for people w/ 3D, inevitably there will be people on each
side of the fence.

P.

> 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 .
>
> Thanks,
> Regina
>
> -----Original Message-----
> From: postgis-devel-bounces@...
> [mailto:postgis-devel-bounces@...] 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@...
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel@...
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>

_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel