If your data model expects strict containment (all parcels must be in
only one zone) then the simplest thing is to proxy the parcel polygon
with a point, then you get a guaranteed 1:1 relationship between
parcel and zone. Using ST_PointOnSurface() is required since
ST_Centroid() is not guaranteed t
Hey, if you want to do it the robust way,
you can use a shared surface distance :
for instance, ST_area(ST_Intersection(A,B)) / ST_Area(A)
where A is you polygon, and B your zoning information.
If everything is snapped, you could also use topology.
Cheers,
Rémi-C
2016-05-25 3:45 GMT+02:00 Paul
On 5/24/2016 6:31 PM, Timothy Asquith wrote:
- I’m experimenting with ST_Snap and filtering out ST_Touches, but
it still returning the same 3 results
You may want to use the dimensionally extended 9 intersection model
(http://postgis.net/docs/manual-2.2/using_postgis_dbmanagement.html#DE-
Thanks Paul,
You’re absolutely right that the intersect query should always have returned
touching polygons. I’m not sure how we were ever getting the desired results.
That’s what I’m looking into now.
Interestingly, the critical difference seems to be the use of binary geometry.
The land parc
The question is not why ST_Intersects() is returning boundary touching
results, it's why your old version did not (at least, as far as you
observed). Because, ST_Intersects(A,B) is *supposed* to return true
for any object B that is not disjoint from A. So, either you were not
observing what you tho
I have a table of land parcels in my PostGIS database, and I'm doing a basic
spatial join against zoning polygons.
I'm having issues where a previously-correct query is now returning different
results.
Up until now, I've been using a Geoserver WFS, and making these queries using
CQL's INTERSEC
