-----Original Message----- From: [email protected] [mailto:[email protected]] 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 <[email protected]> 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: [email protected] > [mailto:[email protected]] 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 > [email protected] > http://postgis.refractions.net/mailman/listinfo/postgis-devel > > > > _______________________________________________ > postgis-devel mailing list > [email protected] > http://postgis.refractions.net/mailman/listinfo/postgis-devel > _______________________________________________ postgis-devel mailing list [email protected] http://postgis.refractions.net/mailman/listinfo/postgis-devel _______________________________________________ postgis-users mailing list [email protected] http://postgis.refractions.net/mailman/listinfo/postgis-users
