ST_Intersection is much slower than relation checks such as
ST_CoveredBy, and ,
In many situations you know the intersection of 2 geometries
without actually computing an intersection. In these cases, you can skip the costly
ST_Intersection call. Cases like this:
- geometry a is covered by geometry b -> intersection is geometry a
- geometry b is covered by geometry a -> intersection is geometry b
- geometry a does not intersect geometry b -> intersection is empty geometry
This kind of question comes up a lot: As discussed in stackexchange Acquiring ArcGIS speed in PostGIS
Every one or two months, someone asks on the PostGIS users list usually somewhat panicked, My geometry is missing when I look in pgAdmin III
This is documented in the PostGIS Frequently Asked questions section of the manual I tried to use PgAdmin to view my geometry column and it is blank, what gives?
Since this question gets asked so much, I thought it best to highlight it again.
Spatial objects can be big things and if your geometry, geography, or raster row field is big enough, pgAdmin is not going to load it
and will just show an empty field. This is by design. There are a couple of ways to verify you really have data and even how big your geometry, geography or raster column is
People often get confused between the
ST_SetSRID doesn’t change the coordinates but adds meta data to state what spatial reference system the coordinate actually are.
If you stamped your WGS 84 long lat data as a meter based projection. Guess what? Its still long lat.
A spade by any other name is still a spade so don’t use ST_SetSRID and expect to magically get meter coordinates.
ST_Transform is used to change the underlying coordinates
from a known spatial reference system to another known spatial reference system.
In PostGIS 2+ it’s pretty easy to correct mistakes you’ve made with standard ALTER TABLE commands. We’ll demonstrate a couple of scenarios
If you have a problem that involves finding the things within X distance of other things or finding what things
have nothing within X distance
do not use
ST_Distance for filtering and also do not try to use
ST_Intersects + ST_Buffer.
ST_DWithin instead. Why?
ST_DWithin can use an index and
ST_Distance can not
ST_Buffer is just an approximation of a buffer and not an exact buffer
Also note that
ST_DWithin is supported for both geometry and geography.
In mapping frameworks spatial coordinates are often in order of latitude and longitude. In spatial databases
spatial coordinates are in x = longitude, and y = latitude.
If you accidentally loaded data as lat,lon, you can always fix the mistake
by using the
ST_FlipCoordinates function introduced in PostGIS 2.0.