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

Paul Ramsey pramsey at cleverelephant.ca
Mon Nov 2 11:43:54 PST 2009


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
>



More information about the postgis-devel mailing list