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

[Paragon Corporation]

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