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

[Paragon Corporation-2]

 

-----Original Message-----
From: postgis-devel-bounces@...
[mailto:postgis-devel-bounces@...] On Behalf Of Paul
Ramsey
Sent: Monday, November 02, 2009 2:44 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Buck Rogers and the 3rd Dimension

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



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