Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It only takes a minute to sign up.
Sign up to join this community
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?
Geography features are always stored in WGS84 prior to PostGIS 2.2; since then any lon/lat-based spatial reference system can be used. Measurements based on geography features will be in meters instead of CRS units and PostGIS will use geodetic calculations instead of planar geometry.
No all functions support geometry but you can cast between geometry and geography. For the current function list see: https://postgis.net/docs/PostGIS_Special_Functions_Index.html#PostGIS_GeographyFunctions
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://postgis.net/workshops/postgis-intro/geography.html
The topic is also covered in "PostGIS in Action" (ISBN: 9781935182269).
I use my intuitive "rules of thumb"... It is useful for a rapid decision,
About your DATABASE: if features and/or spatial analysis are of continental-scale, and need precision (serious applications) use geography. Else use geometry: when all database is about same (city-scale) region, or you not need precision, etc. you need only geometry.
See similar rule at the suggest lecture of @underdark.
About your needs in terms of PERFORMANCE/PRECISION BALANCE: geometry is faster; if you need performance and think to use geography, do your benchmarks first.
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:
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.
Bench#1: a table with ~87000 polygons representing urban lots, each with poly with (avg) ~13 points,
BEGIN; EXPLAIN ANALYSE CREATE TABLE temp_geom AS
SELECT gid, the_geom FROM urbanlots; ROLLBACK;
-- time 2080 ms ~ 2.0 s
BEGIN; EXPLAIN ANALYSE CREATE TABLE temp_geog AS
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.
Bench#2: 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.
Bench#3: ~10000 lines representing urban streets, each with ~5 points. ~0.87s vs ~0.36s, geography_time=2.4*geometry_time.
Back to Bench#2, 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.
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!).
ST_GeomFrom* and ST_As* seem very handy, especially combined with the ability to define custom CRSs, letting PostGIS handle the transformations during queries and exports in a single CRS?
Sep 2, 2016 at 2:05
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.
Maybe you find this feature - and answer - is useless, but one of the advantages of working with geometries is that you can work 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.
