A. Spatial Reference ID lookup
As we’ve seen, populating a geometry column with usable data requires specifying the spatial reference of the data. We also saw that geometries can be re-projected from one spatial reference to another using the ST_Transform() function. In both cases it is necessary to refer to spatial reference systems by an SRID (Spatial Reference ID). So where do these IDs come from and where can a list of them be found?
The answer to the question of where the IDs come from is that PostGIS uses the spatial reference IDs defined by the European Petroleum Survey Group (EPSG). As for finding the ID for a spatial reference you want to use there are a few different options.
All of the spatial reference IDs are stored in a Postgres table in the public schema called spatial_ref_sys.
- In pgAdmin, navigate to the spatial_ref_sys table and view its first 100 rows. Make particular note of the srid and srtext columns.
One way to find an SRID is to query the spatial_ref_sys table.
- Open the Query Tool and execute the following query:
SELECT srid, srtext FROM spatial_ref_sys WHERE srtext LIKE '%Pennsylvania%';This query shows the SRIDs of each Pennsylvania-specific spatial reference supported in PostGIS.
Another way to find SRIDs is to look them up in QGIS.
- In QGIS, go to Project > Project Properties.
Under the CRS tab, recall that the various coordinate systems are categorized as Geographic or Projected. If you’re an Esri ArcMap user, this sort of interface should feel familiar. Let’s say you wanted to find the ID for UTM zone 18N, NAD83.
- Expand the Projected Coordinate Systems category then expand the Universal Transverse Mercator (UTM) category.
- To easily get to this sublist you might want to use the Filter capability.
- Scroll down through the list and find NAD83 / UTM zone 18N.
- On the right side of the dialog you should see a column called Authority ID. Note that most of the Authority ID values are prefixed with EPSG which means those are the values you should use in PostGIS. In this case you would find that the desired SRID for UTM NAD83 Zone 18N is 26918.
Using the Prj2EPSG service
The Prj2EPSG website provides an easy-to-use interface for finding EPSG IDs. As its name implies it allows the user to upload a .prj file (used by Esri to store projection metadata) and get back the matching EPSG ID. The site also makes it possible to enter search terms. My test search for ‘pennsylvania state plane’ yielded some garbage matches but also the ones that I would expect.
B. Geometry metadata in PostGIS
We’ve seen that the public schema contains a table called spatial_ref_sys that stores all of the spatial references supported by PostGIS. Another important item in that schema is the geometry_columns view. Have a look at the data returned by that view and note that it includes a row for each geometry column in the database. Among the metadata stored here are the parent schema, the parent table, the geometry column’s name, the coordinate dimension, the SRID and the geometry type (e.g., POINT, LINESTRING, etc.). Being able to conduct spatial analysis with PostGIS requires accurate geometry column information, so the PostGIS developers have made these data accessible through a read-only view rather than a table.
Earlier in the lesson we used the AddGeometryColumn() function instead of adding the geometry column through the table definition GUI. An important reason for adding the geometry column in that manner is that it updates the geometry metadata that you can see through the geometry_columns view, something that would not happen if we had used the GUI.
C. Spherical measurements and the geography data type
We’ll talk more about measuring lengths, distances, and areas in the next lesson but while we’re on the topic of spatial references it makes sense to consider 2D Cartesian measurement in the context of planimetric map data versus measurement in the context of the spherical surface of the Earth. For example the PostGIS function ST_Distance() can be used to calculate the distance between two geometries. When applied to geometries of the type we’ve dealt with so far, ST_Distance() will calculate distances in 2D Cartesian space. This is fine at a local or regional scale since the impact of the curvature of the earth at those scales is negligible, but over a continental or global scale a significant error would result.
PostGIS offers a couple of alternative approaches to taking the earth’s curvature into account. Let’s assume that we wanted to measure the distance between points in the (U.S.) cities table that we created earlier in the lesson. We could use a version of the ST_Distance() function called ST_Distance_Spheroid(). As its name implies this function is designed to calculate the minimum great-circle distance between two geometries.
The other approach is to store the features using a data type introduced in PostGIS 1.5 called geography. Unlike the geometry data type, the geography data type is meant for storing only latitude/longitude coordinates. The advantage of the geography data type is that measurement functions like ST_Distance(), ST_Length() and ST_Area() will return measures calculated in 3D space rather than 2D space. The disadvantage is that the geography data type is compatible with a significantly smaller subset of functions as compared to the geometry type. Calculating spherical measures can also take longer than Cartesian measures since the mathematics involved is more complex.
The take-away message is that the geography data type can simplify data handling for projects that cover a continental-to-global scale. For projects covering a smaller portion of the earth’s surface you are probably better off sticking with the geometry data type.
With that we've covered all of the content for Lesson 3. In the next section you'll find a project that will allow you to put what you've learned to use.