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.
We show examples using geography.
Note geometry would use much the same except units are in the spatial reference units.
Finding closest things within 1609 meters (~1 mile)
SELECT roads.roadname, pois.poiname FROM roads INNER JOIN pois ON ST_DWithin(roads.geog, pois.geog, 1609);
Finding roads with nothing of interest within 1 mile.
We are using the fact that a LEFT JOIN returns null in the left table when no match is found
SELECT roads.roadname, pois.poiname FROM roads LEFT JOIN pois ON ST_DWithin(roads.geog, pois.geog, 1609) WHERE pois.gid IS NULL;
As of PostGIS 2.3, the postgis extension was changed to no longer allow relocation. All function calls within the extension are now schema qualified.
While this change fixed some issues with database restore, it created the issue of if you installed PostGIS in a schema other than the one you wanted to it is not intuitive how to move it to a different schema. Luckily there is a way to do this.
For this exercise, I will install PostGIS in the default schema and then demonstrate how to move it into another schema location.
You can run these steps using psql or pgAdmin or any other PostgreSQL tool you want.
The error ‘postgis.backend’ is already set comes up every so often in PostGIS mailing list. The issue arises often during or after an upgrade. I’ll go over causes for this I am aware of and how to fix.
The question goes something like this
After upgrading to Postgis 2.3 from 2.1, my server log is filled with these messages :
“WARNING ‘postgis.backend’ is already set and cannot be changed until you reconnect”
This raster question comes up quite a bit on PostGIS mailing lists and stack overflow and the best answer often involves
the often forgotten
ST_Reclass function that has existed since PostGIS 2.0.
People often resort to the much slower though more flexible
ST_MapAlgebra or dumping out
their rasters as Pixel valued polygons they then filter
with WHERE val > 90,
ST_Reclass does the same thing but orders of magnitude faster.