Take the 2-minute tour ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

As my client software uses lat/lon coordinates when communicating with my (spherical mercator) postgis database i decided to ST_Transform every geometry to WGS-84.

However i noticed that ST_Distance for WGS-84 returns units as degrees (i need meters). So i decided to use ST_Distance_Spherical(geom1, geom2, 'SPHEROID["WGS 84",6378137,298.257223563]') but this method seems to be extremely slow.

Therefor i switched back to using spherical mercator again and transforming my input and output to and from wgs-84 as that performs a lot better.

Am i using the correct method or is this a known issue?

share|improve this question
add comment

2 Answers 2

up vote 7 down vote accepted

WGS-84 is unprojected data. It uses a geodetic coordinate system, which means points are located on a spherical (ellipsoidal to be exact) modelisation of the earth.

As a consequence, euclidian geometry is not valid for this kind of data. PostGIS «geometry» data type and associated functions work with planar coordinates and euclidian geometry computations. If you want to use them you have to project your data to a specific coordinate system, which by definition are only locally accurate.

Non-planar Geometry computation will always be way slower than planar geometry computation. See the difference between distance computation on a plane and the Harversine formulae on a sphere as an example :



That said, recent version of PostGIS have a «geography» data type and some associated functions for those who must use unprojected geodata.

How do you choose between the two ?

If you just store and retrieve your data from the database, using latlon (geography or wgs84 srid) will be fine.

If you have a dataset with a worldwide repartition, you may be interested in using the geography type to be able to deal with all your data in the same manner, without having to deal with multiple projections. Computations will be slower though, and the functions set in postgis is narrower.

If you do processing on your data, need to be fast and want to use PostGIS pletoric set of functions, you have to project your data, and do dynamic coordinate transformation on input/output with st_transform, just as you do.

So yes, you're right, but still the real right decision depends on the specific use case.

share|improve this answer
Is ST_Distance used on spherical mercator (900913) geometry just as precise as using ST_Distance_Spheroid on WGS 84? And i conclude from your answer that my decision to do operations on Spherical Mercator instead of WGS 84 if speed is a necessity is a good one? –  mrg Oct 28 '11 at 12:21
Yes it is a good choice, but it depends of your dataset location. Spherical mercator is far from being the best projection for a lot of use cases and locations. You should rather use a local projection. Without knowing your actuel data repartition, no way to say which is best and what the precision loss would be. –  Vincent Oct 28 '11 at 12:37
I will mainly cover the area of Netherlands and parts of northern Germany. Maybe i should use RD_New? I do not need to be very precise. Less than 3-5% would be ok for me i guess. –  mrg Oct 28 '11 at 13:31
+1 Very nice contribution for its thoughtfulness and knowledge. Welcome to our site, Vincent! –  whuber Oct 28 '11 at 15:17
add comment

Distance measurements in EPSG:900913 are not a good idea since distances are very distorted in this projection. ST_Distance_Spherical() will be much more accurate.

share|improve this answer
Does this mean that if you use lat lon projection, A* will also be using degrees for its heuristic function? And even worse (as i had lengths of edges in meters) that A* will effectively become Dijkstra's algorithm? –  mrg Oct 29 '11 at 13:39
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.