I'm trying to understand the data conversions that happen in PostGIS when calculating distances in SRID 4326.

Why is it that when I run on my marin_jobs points table:

select cast (the_geom as geography), the_geom from 
marin_jobs where blockid10 = '060411141001010' limit 1;

I get

the_geom      the_geom
geography     geometry
010100....    010100....

And the wkt output values are exactly the same?

I came to this question because when I run a distance query (see below for code) on two points in my dataset, if I don't use cast () as geography I get out degrees, just like the Boundless Geography tutorial said I would. http://postgis.net/workshops/postgis-intro/geography.html

But I don't understand how if the inputs are (seem to be anyway) exactly the same, the outputs are different. Or should I ask...are the outputs really different?

Does that mean that the value of 0.0616262566763201 degrees and 6007.875564598 meters are the same, but just in different units?

But this doesn't jive with what the Boundless Tutorial says,

"On a sphere, the size of one “degree square” is quite variable, becoming smaller as you move away from the equator. Think of the meridians (vertical lines) on the globe getting closer to each other as you go towards the poles. So, a distance of 121 degrees doesn’t mean anything. It is a nonsense number."

Any plain English claficiation would be really helpful. This is keeping me up at night.

Distance Queries:

select st_distance (
               (select the_geom from marin_jobs where blockid10 = '060411141001010' limit 1),
               (select the_geom from marin_jobs where blockid10 = '060411070005007' limit 1)

output: 0.0616262566763201

select st_distance (
                (select cast (the_geom as geography) from marin_jobs where blockid10 = '060411141001010' limit 1),
                (select cast (the_geom as geography) from marin_jobs where blockid10 = '060411070005007' limit 1)

output: 6007.875564598

3 Answers 3


The PostGIS manual explains well the difference between geometry and geography and why ST_Distance gives different results in chapter 4 http://postgis.net/docs/using_postgis_dbmanagement.html#PostGIS_Geography.

ST_Distance with geography type gives as a result the great circle length that follows the surface of the globe (actually WGS84 spheroid). ST_Distance with geometry makes distance calculations as if the globe were flat as in the image below. You can measure with a ruler that both Greenland and Africa are about 60 degrees wide but only by using geography based distance you can see that 60 degrees at the equator is 6668 km while at 80 degrees N it is only 1106 km. enter image description here


Both geometry / geography have the same canonical output representation but use entirely different functions to compute distance. geometry computes along a cartesian plane (mapping degrees to flat X/Y) and geography around a sphere. Don't be confused by the fact they show the same visible output. They would show the same too with ST_AsGeoJSON etc. since they use the same coordinates.

  • geometry uses en.wikipedia.org/wiki/Cartesian_coordinate_system and in theory geography uses en.wikipedia.org/wiki/Spherical_coordinate_system to measure distances, angles and areas, in practice most functions convert geography to suitable UTM projection and use cartesian system to calculate values, see postgis.refractions.net/docs/… for reference May 26, 2014 at 8:32
  • So many question still...sorry! So when I'm casting as geography I'm changing the metadata? How come I have to do that when srid 4326 is already in a spheroid system, not a cartesian one? And how does PostGIS choose which cartesian plane it will be using when it calculates distance of geometries? And since (if) PostGIS is transforming my spheroid lat long points into a cartesian plane, how come the ST_Distance output is in degrees and not meters?
    – tapzx2
    May 26, 2014 at 20:31
  • 1
    simplexio -- you are wrong about geography. IT does not cast to UTM for ST_Intersects/ST_Distance/ST_DWithin - these are all natively calculated around a sphere. The only functions that cast are ST_Intersection and ST_Buffer. Also that's the old site. New site is postgis.net
    – LR1234567
    May 27, 2014 at 6:09
  • tapzx2: 4326 in geometry is what is known as Plate-Caree. sharpgis.net/post/2009/02/06/… . Geometry only understands planar coordinates. When you are casting to geography you are changing the postgresql data type. It's like if you have json as text, you can't use json functions on it without some implicit or automatic cast to json. Same goes with 4326 wkt. Cast it to geometry it it is flat x/y, cast to geography it is sphere
    – LR1234567
    May 27, 2014 at 6:12
  • LR1234567...this make sense now. I've been mislead about 4326. In PostGIS it isn't a cartesian or spherical system. Its both. Thank you very kindly for the clarification.
    – tapzx2
    May 27, 2014 at 9:50

SRID 4326 is a geographic coordinate system (WGS84). There is no conversion between degrees and metres/feet as it depends on where you are standing on the earth.

The only way to get metres is to convert the whole geometry to a projected coordinate system, a suitable UTM will exist to convert to like 32626: WGS 84 / UTM zone 26N, have a look here for a list of UTM projections with zones. I remember vaguely that there was a way to cast a geometry to a different coordinate system on-the-fly in PostGis but can't remember the exact syntax. You will need to know what zone it's in (6 degrees wide) have a look here at the possible zones.

It looks like the st_distance understands this and selects a suitable generic projected coordinate system to calculate the distances in, which might not be so accurate. It would be best to take charge of the projection to instill some confidence in the final measures; the difference is likely to be sub-metre between a generic and specific coordinate system in the order of 6km, so only if that's a concern would you need bother with a specific projected SRID.

BTW. 121 degrees is a very long way. As a zone is generally 6 degrees wide it would cross zone boundaries (unless it's north-south) and would require a special projection to measure: Lamberts' conformal conic is one I've used for multi-zone features.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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