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.

My company uses geometry (the_geom) data type for storing geospatial data.

I've recently been acquainted to the concept of geography (the_geog) data type which, as I understand it, stores the SRID along with the geometry.

What are the differences between geography and geometry, and is there any advantage of using one of them in large databases?

share|improve this question
I suggest changing the title of your question to "PostGIS: What are the pros and cons of geography and geometry types" or something thing similar to that. –  dassouki Mar 2 '11 at 14:49
@dassouki thanks, changed. –  Adam Matan Mar 3 '11 at 6:27

4 Answers 4

up vote 22 down vote accepted

Geography features are always stored in WGS84. Measurements based on geography features will be in meters instead of CRS units and PostGIS will use geodetic calculations instead of planar geometry.

There is only a limited list of functions for manipulating/analyzing geography features (but you can cast between geometry and geography). Geography is supported by: measuring functions, ST_Intersects, ST_Intersection, ST_Buffer, ST_Covers and ST_CoveresBy.

I don't think it's possible to recommend either geography or geometry for large databases. It depends on what you are doing with your data. As calculations on the sphere are more complicated, I'd expect analyses to be slower on geography features. You also have to transform all your data to WGS84 to use geography.

If you do a lot of measurements and e.g. have to compare sizes of large polygons, it would make sense to use geography rather than geometry.

I found the following useful: http://workshops.opengeo.org/postgis-intro/geography.html

The topic is also covered in "PostGIS in Action" (ISBN: 9781935182269).

share|improve this answer
Nice edit. I guess that I might as well delete my answer now. –  DavidF Mar 2 '11 at 16:53
does anyone know if PostGIS in Action will ever actually come out in print? –  iant Mar 2 '11 at 19:17
PostGIS in Action should be out 2011-03-28 according to astore.amazon.com/bostongis-20/detail/1935182269 –  underdark Mar 3 '11 at 8:15
@underdark This had been postponed for a long time, AFAIR. –  Adam Matan Mar 3 '11 at 11:25
@Adam: Yes, it has been postponed often. It's faster to get the ebook and later on the hardcover for a reduced price. –  underdark Mar 3 '11 at 12:07

I use my intuitive "rules of thumb"... It is usefull for a rapid decision,

  • About your DATABASE: if features and/or spatial analysis are of continental-scale, and need precision (serious applications) use geography. If, on the other hand, all database is about same region, all at city-scale, you not need only geometry.
    See similar rule at the suggest lecture of @underdark.

  • About your needs in terms of PERFORMANCE/PRECISION BALANCE: if you need performance and think to use geography, do your benchmarks first, checking if geometry is better.


On this page, we see some key-words and the focus on some concepts: precision, performance, and something like flexibility/commodity of use.

As remembered by others, the difference, for store and calculations, is the use of sphere in geography and plane in geometry:

  • the sphere (geography) is better, more precise. See the Los Angeles/Paris example.
  • evolution of geography: as @DavidF say, "geography type was more recently added, so fewer functions are supported/implemented".

Perhaps on the year 2020 all GIS databases will be set to the same standard SRID/EPSG (equivalent to the nowadays 4326 code, for WGS84). Today geography is not a default choice because of performance and functional limitations.


In my opinion it is a question of "best practices", not a deep technical/theoretical problem.


After estimate the error on your data, do your tests and compare results: the precision gains with geography are higher than error of data? The ST_Distance function (with MAX and AVG aggregators) is the main reference in this kind of experiment.


Examples of benchmarks in an urban area of ~100km2 (diameter ~11km), all stored as geometry, in a planar UTM coordinate system. NOTE: starting with the frequently used geometry/geography conversion — frequently because some functions not exist and some others, like ST_Buffer and ST_Intersection, do conversion internally.

Bench1: a table with ~87000 polygons representing urban lots, each with poly with (avg) ~13 points,

        SELECT gid, the_geom FROM urbanlots; ROLLBACK;
 -- time 2080 ms   ~ 2.0 s
        SELECT gid, Geography(ST_Transform(the_geom,4326)) AS geog 
        FROM urbanlots; ROLLBACK;
 -- time 12374 ms ~ 12.4 s  ~ 6 * geometry.

so, geography_time=6*geometry_time.

Bench2: a table with ~3500 polygons representing urban blocks, each with poly with (avg) ~50 points: 0.6s vs 2.7s, geography_time=4.5*geometry_time.

Bench3: ~10000 lines representing urban streets, each with ~5 points. ~0.87s vs ~0.36s, geography_time=2.4*geometry_time.

Back to Bench2, creating the tables and doing queries,

 EXPLAIN ANALYSE SELECT ST_Area(g.the_geom)+ST_Distance(g.the_geom,t.the_geom) 
         FROM temp_geom g, (SELECT the_geom FROM temp_geom WHERE gid=1) as t;
 -- time 182 ms   ~ 0.2 s
 EXPLAIN ANALYSE SELECT ST_Area(g.geog)+ST_Distance(g.geog,t.geog) 
         FROM temp_geog g, (SELECT geog FROM temp_geog WHERE gid=1) as t;
 -- time 58657 ms  ~ 59 s  ~  300*geometry
 -- curioselly for only distances, geography=4*geometry

Conclusion: for little tasks and good hardaware, the times converge to the "acceptable-same time", but for big tasks, there are performance ratings to consider.


On the benchmarks I do a day-by-day task, checking the number of points (by ST_NPoints)... It is an example of operation that not exists for geography, needs cast. The "geography/geometry cast" is an annoying task for programmers, masters, etc.

When reusing libraries of SQL and PL/pgSQL functions, geography need adaptations. And, if you want to optimize code, or avoid precision problems with a lot of intermediary conversions, the absence of a complete set of build-in functions, with geography, is another problem. Program for geography, is not a easy task.

Process-only, data interchange, etc.

For non-usual demand, with no intensive user like Mapserver, when your only (PostGIS) work is to process input data and return at any time (like hours or days) the processed data, the rule of thumb is "use geography if you are comfortable!" (see "Flexibility/Commodity" above). If not, check usual rules.
NOTE: of course, if your (non-usual) task is only show data from PostGIS to Mapserver, with no process need, to preserve the same (geometry or geography) of your input data, is better decision.

I believe the data centralization is another task where geography is better: in context where the diversity of input formats and reference systems are usual, the use of a standard, such as that enforced by the geography, is beneficial... Convention over configuration is a good principle when centralization and data interchange are the business focus (see Google Maps!).

share|improve this answer
+1 Thanks for the very comprehensive answer. –  Adam Matan Sep 18 '12 at 17:34

I believe that the most significant difference is that with the geography type, calculations are made on a sphere representing the earth as opposed to the flat surface used in calculations made on geometry type features.

The docs are pretty good: http://postgis.net/docs/manual-1.5/ch04.html#PostGIS_Geography

The geography type was more recently added, so fewer functions are supported/implemented.

share|improve this answer

Maybe you find this feature - and answer - is useless, but one of the advantages of working with geometries is that you can work without without any spatial reference (that is, SRID set to -1).

Currently I am working in an application that filters airborne LiDAR data, among its data sources is a PostGIS database, that provides first class spatial indexing (RTree over GiST) and copes with high volume of data without problem. Since that application does not require manipulating or analyzing geography features no SRID is needed, thus avoiding the overhead it can bring.

share|improve this answer

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.