4

I am creating a PostGIS 2.X data base to store some 500 or so sites as points in it, which are distributed in the northeastern part of Germany, northern Poland and parts of the southern Baltic coast. I will also store some lines and polygons from the same in it, which will be needed to calculate distances and areas. In general an error of about 10-20 m would be acceptable for my task.

I was thinking of storing the spatial data as geography in ETRS89 Lat/Lon (EPSG 4258), which should allow for best compatibility over the entire area, but cost me some functionality compared to geometry. Since I am new to PostGIS, I don't know how strongly this will affect me.

So here are my to questions: 1) Is there a considerable downside to using lat/lon-data and geography for this task? 2) Is there a projected SRS I could use for this area without getting to much of an error to my measurements?

  • Are these coordinates already in existence? i.e. have they been collected and your job is to store them? If so, store them in their original coordinate reference system and then do conversion later, as needed. – alphabetasoup Dec 16 '19 at 0:18
  • I gathered the coordinates from different sources in different CRS. Usually i would keep them in the original CRS, but since I need to work with them as a whole, I wanted to bring them together in one system. At the moment they are all in EPSG 4258. – C.-F. Vintar Dec 16 '19 at 7:17
  • 1
    Geometrically, the storage data type doesn't matter much, as long as you stay in (the same) geographic reference system; the geometric predicates are unaffected, the topology remains unchanged. It starts to matter when you run functions on the types; for measurements with high demand in precision you absolutely want the spherical/spheroidal algebra behind the GEOGRAPHY type. But if you have to cast from GEOMETRY first does matter only in terms of performance. What are you every day, heavy duty tasks on that data going to be? – ThingumaBob Dec 16 '19 at 12:04
  • I think we can neglect the performance issue. I will run some analyses (mostly spatial statistics and some network analyses) on the data, but mostly the DB will be the data storage enabling me to create data assamblages I need for mapping in GIS, creating catalogues etc. – C.-F. Vintar Dec 16 '19 at 12:39
  • 1
    @ThingumaBob Thanks a lot. Would you mind putting the summary of your comments as an answer, so I can vote this question answered and let it be closed? – C.-F. Vintar Dec 16 '19 at 15:44
5

As a summary of the comments; I urge you to read more on the topic GEOMETRY vs. GEOGRAPHY, as this is only a limited comparison:

PostGIS' type difference between GEOMETRY & GEOGRAPHY is mainly defined by their underlying math:

  • the GEOMETRY type assumes coordinates to be planar, thus in Euclidean space (as in 'projected from the Geoid'), and it does so even for geographic coordinate references
  • the GEOGRAPHY type assumes the coordinates to be geodetic, thus in (non-Euclidian) Spherical 'space', and takes the properties of the referenced Geoid into account

Within PostGIS

  • a conversion (cast) between the types is seamless as long as the geometries are referenced in any geodetic SRS present in the compiled proj4 database (see the spatial_ref_sys table) (note, since you specified PostGIS 2.0 in tags and 2.X in your question; the definition of a geodetic SRS other than EPSG:4326 needs PostGIS version 2.2 and above!)
  • a type conversion has (almost) no effect on a geometries' geometric predicates (e.g. precision) and their topology; spatial relation analysis will yield the same results (in fact, some of those functions allowing GEOGRAPHY are wrappers around their GEOMETRY signatures and process the input based on a best-fit on-the-fly projection)

Some advantages of the GEOGRAPHY type are

  • globally equal precision and accuracy (of measurements) without the need to project coordinates
  • unit of measurement (and respective input for e.g. proximity functions) are in meter

while some caveats are

  • the cost of performance (heavier calculations)
  • the lesser support of functions
  • that most GIS (client) applications lack (full) support for the GEOGRAPHY type

A recommendation is hard to give, as it is heavily dependent on the use case.

Generally, keeping data in a (best-fit for precision, EPSG:4326 for interchangeability) geodetic SRS as GEOMETRY is a good choice, since

  • the power of geodetic measurement precision is readily available via cast to GEOGRAPHY, when necessary
  • all functions are available
  • the general performance is better, e.g. when running spatial relation functions (comparing topology)

However

  • if you plan to use proximity searches (e.g. ST_DWithin) or spatial relation queries on the GEOGRAPHY type for high precision analysis, you will (also) need a respective (functional) index:

    CREATE INDEX [<name>] ON <table>
      USING GIST(CAST(<geom_col> AS GEOGRAPHY))
    ;
    
  • all participating geometries need to be of type GEOGRAPHY

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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