Re: [postgis-devel] Buck Rogers and the 3rdDimension
Sufficool, Stanley <ssufficool <at> sbcounty.gov>
2009-11-02 19:30:19 GMT
My 2 cents.
Why do spheroid projections assume zero altitude is Z miles from core.
What about other planets? What if I want to map Mars?
Isn't the geography projection model is broken? You can't have a sphere
without a diameter and the Z measure is just a plus/minus of the given Z
constant from the core.
> -----Original Message-----
> From: postgis-users-bounces <at> postgis.refractions.net
> [mailto:postgis-users-bounces <at> postgis.refractions.net] On
> Behalf Of Paragon Corporation
> Sent: Saturday, October 31, 2009 9:00 AM
> To: 'PostGIS Development Discussion'
> Cc: 'PostGIS Users Discussion'
> Subject: Re: [postgis-users] [postgis-devel] Buck Rogers and
> the 3rdDimension
> 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 .
> -----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)',
> 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.
> postgis-devel mailing list postgis-devel <at> postgis.refractions.net
> postgis-users mailing list postgis-users <at> postgis.refractions.net