Maps: Does calculating distance between 2 points factor in altitude?

Question

Does Postgres' Spatial plugin, or any Spatial package for that manner, factor in the altitude when calculating the distance between 2 points?

I know the Spatial packages factor in the approximate curvature of the earth but if one location is at the top of a mountain and the other location is close to the sea - it seems like the calculated difference between those two points would greatly vary if the difference in altitude was not factored into account.

Also keep in mind that if I have 2 points are at the same ocean altitude but a mountain exists between the 2 points - the distance package should account for this.

Answer 1

If the distance formula you're using does not take the altitude of the two points as parameters (in addition to the Latitudes and Longitudes of the two points), then it does not factor in altitude to the distance calculation. In any event, altitude difference does not have a very significant effect on calculated distance.

As usual with GPS, the difference in distance calculations that altitude would make is probably smaller than the error in most commercial GPS devices anyway, so in most applications altitude can be safely dispensed with (altitude measurements themselves are pretty inaccurate with commercial GPS devices, although survey data on altitudes is quite accurate).

Answer 2

PostgreSQL does not factor in altitude when calculating distances. It is all done in a planar surface.

Most of database spatial packages will not take this into account, altought, if your point is 3d, i.e., has a Z coordinate that might happend.

I don´t have PostgreSQL in this machine, but try this.

SELECT ST_DISTANCE(ST_POINT(0,0,10),ST_POINT(0,0,0));

It´s fairly easy to know if it is taking into account your Z value, since the return should be > 0; If that turns out to be true, just create Z aware features, and you will be successfull.

What SQL SERVER 2008, for example, takes into account when calculating distances, is the position of a Geography feature in a sphere. Geometry features in SQL SERVER will always use planar calculations.

EDIT: checked this in PostGIS manual

For Z aware points you must use the ST_MakePoint function. It takes up to 4 arguments (X Y Z and M). St_POINT only takes two (X Y)

http://postgis.refractions.net/documentation/manual-1.4/ST%5FDistance.html ST_DISTANCE = 2D calculations

ST_DISTANCE_SPHERE documentation (takes in account a fixed sphere for calculations - aka not planar) http://postgis.refractions.net/documentation/manual-1.4/ST%5FDistance%5FSphere.html

ST_DISTANCE_SPHEROID documentation (takes into account a choosen spheroid for your calculations) http://postgis.refractions.net/documentation/manual-1.4/ST%5FDistance%5FSpheroid.html

ST_POINT documentation http://postgis.refractions.net/documentation/manual-1.4/ST%5FPoint.html

Answer 3

Hello Timtom,

Those factors are not being counted at all. Why? The software only knows about the two features (the two points you are getting the distance, the sphere/spheroid and a datum/projection factor).

For that to happen you need to probably use a developed linestring, in which you will connect your point with n vertices, each of them being Z aware.

Imagine this (loose WKT): LINESTRING((0,1,2),(0,2,3),(0,3,4),(0,10,15),(0,11,-1)).

Asking the software to calculate the distance between each vertex and summing it up, will consider the variations of terrain. But without something like that, it is impossible to map for irregularities in terrain.

All GIS softwares cannot tell, by themselves, what are those irregularities in terrain, and therefore, not take them in account.

You can create such linestrings (automatically) with softwares like ArcGIS (and others), using a line (between two points), and a surface file, such as the ones provided freely by NASA (SRTM project). These files come in a raster format, and each pixel has a X Y and Z value, in meters. Traversing the line you want, coupled with that terrain profile, you can achieve the calculation you want to achieve. If you need to have super extra precise calculations, you need a precise surface, and precise Z values in each vertex of this profile line.

That cleared up?