[postgis-users] TopologyException: geom is invalid
Joseph Spenner
joseph85750 at yahoo.com
Thu Feb 26 13:08:51 PST 2015
Roxanne: I think you're on to something here. I just did more tests, and found the following:
This command fails with the error:
select ST_Asgeojson( geom ) from dynamic.polys where ST_Intersects(ST_GeomFromGeoJSON('$jsonPoly'), geom)=TRUE and ST_Area(ST_Intersection(ST_GeomFromGeoJSON('$jsonPoly')::geography, geom::geography))>500
== ERROR==
DBD::Pg::st execute failed: ERROR: Error performing intersection: TopologyException: Input geom 0 is invalid: Self-intersection at or near point 1543100.5176146738 389360.239110158 at 1543100.5176146738 389360.239110158 at ./foo.pl line 50.
DBD::Pg::st execute failed: ERROR: Error performing intersection: TopologyException: Input geom 0 is invalid: Self-intersection at or near point 1543100.5176146738 389360.239110158 at 1543100.5176146738 389360.239110158 at ./foo.pl line 50.
== /ERROR==
But this command succeeds, no error:
select ST_Asgeojson( geom ) from dynamic.polys where ST_Intersects(ST_GeomFromGeoJSON('$jsonPoly'), geom)=TRUE
The only thing different is the extra AND: ST_Area(ST_Intersection(ST_GeomFromGeoJSON('$jsonPoly')::geography, geom::geography))>500
The reason I did this was to prevent false positives for geoms which were simply tangent, or "touching".For example, if I searched for MN, and there was poly/county on the northern IA border, it would be returned.
Looks like I need to find a better way to deal with the geoms that just touch with a single point or line in common.
Any idea on a better way to handle this?
Thanks for your help! I owe you a beer. :)
From: Roxanne Reid-Bennett <rox at tara-lu.com>
To: postgis-users at lists.osgeo.org
Sent: Thursday, February 26, 2015 1:16 PM
Subject: Re: [postgis-users] TopologyException: geom is invalid
On 2/26/2015 1:40 PM, Joseph Spenner wrote:
I ran the following against all 4 of my GeoJSON files:
SELECT ST_IsSimple(ST_GeomFromGeoJSON('@poly')) SELECT ST_IsValid(ST_GeomFromGeoJSON('@poly')) SELECT ST_IsValidDetail(ST_GeomFromGeoJSON('@poly')) SELECT ST_IsValidReason(ST_GeomFromGeoJSON('@poly'))
where @poly contained each one of the following:
http://microflush.org/stuff/json/MN.json http://microflush.org/stuff/json/mnz091.json
http://microflush.org/stuff/json/CA.json http://microflush.org/stuff/json/nwsZone.json
The select returned no error. I tried to vary the input slightly to make sure I was using the proper syntax, and was able to get errors-- such as:
DBD::Pg::st execute failed: ERROR: geometry contains non-closed rings
So, it would seem my geoms are ok.
I've not yet tried the "ST_MakeValid". But wouldn't the above indicate they're already valid?
Yes ST_IsValid coming back true means that the geometry is "valid". (Topology Exceptions are most often thrown during operations on invalid geometries - so this test is the first that should be done when one occurs... in almost all cases)
In my (limited) experience - just because 2 geometries are valid, doesn't mean that operations on them won't generate issues.
Is it the cast to Geography, ST_Intersection or the ST_Area on the ST_Intersection that is throwing the error?
My guess is going to be the ST_Area on the results of the ST_Intersection.
So, is the result of the ST_Intersection of the two geographies valid?
Have you perhaps looked at all the involved geometries (since you are down to 4) at the point identified by the original Topo error in order to understand exactly what in the makeup of those geometries makes the error remotely possible within the operation you are performing on them?
ST_MakeValid and ST_Buffer adjust the geometry in (frequently insignificant) ways that help operations avoid Topos. But what adjustment is likely to avoid the error when using the related valid geometries is dependent upon the real cause for the error - and that is specific to the geometries at the point identified in the error. Whether those manipulations can validly be applied is dependent upon your business use tolerance for those adjustments. (buffering a polygon by 0.00001 will skew calculated area of a polygon but may not result in false positives for an Intersects).
Roxanne
Thanks!
From: Joseph Spenner <joseph85750 at yahoo.com>
To: PostGIS Users Discussion <postgis-users at lists.osgeo.org>
Sent: Thursday, February 26, 2015 8:05 AM
Subject: Re: [postgis-users] TopologyException: geom is invalid
Hello, and thanks for the replies! I'll try those suggestions.
Just curiuos though-- which geometry seems to be invalid? Is it the state poly, or the smaller county/zone poly? If there was an invalid geometry, wouldn't it always show up for that state or county? Here's what I observed for the CA issue:
1) I had 3 smaller county poly/geometries in CA. When performing my query, instead of returning the 3 polys, I received the error which I posted in my original thread. I identified it was 1 of those 3. I deleted that 1 offending geometry from my table. After doing so, my query against CA turned up the remaining 2, with no errors. So, that leads me to believe CA is ok. Or is this not a valid assumption? Perhaps the location where that offending intersection would have occurred in the CA poly has an issue, and it doesn't get tickled unless the smaller county zone intersects it?
2) I was able to plot the offending county described above in the GeoJSONLint validation page: http://geojsonlint.com/ There didn't appear to be any issues.
Thanks!
Regards, Joseph Spenner
From: Rémi Cura <remi.cura at gmail.com>
To: PostGIS Users Discussion <postgis-users at lists.osgeo.org>
Cc: Joseph Spenner <joseph85750 at yahoo.com>
Sent: Thursday, February 26, 2015 1:28 AM
Subject: Re: [postgis-users] TopologyException: geom is invalid
And also ST_IsSimple (that precisely check for self intersection).
Cheers,
Rémi-C
2015-02-26 8:32 GMT+01:00 BladeOfLight16 <bladeoflight16 at gmail.com>:
On Wed, Feb 25, 2015 at 12:14 PM, Joseph Spenner <joseph85750 at yahoo.com> wrote:
DBD::Pg::st execute failed: ERROR: Error performing intersection: TopologyException: Input geom 1 is invalid: Self-intersection at or near point -381688.06935935974 -1206669.4272876547 at -381688.06935935974 -1206669.4272876547 at ./test.pl line 151.
Did you try ST_IsValid to verify the geometry is valid according to the OGC standard? (See http://postgis.net/docs/using_postgis_dbmanagement.html#OGC_Validity. ST_IsValidDetail and ST_IsValidReason are also helpful in this regard.) What happens if you run it through ST_MakeValid? Be aware that ST_MakeValid can sometimes result in GeometryCollections if the input shape is malformed (usually "rings" without enough points are that have different start and end points).
_______________________________________________
postgis-users mailing list
postgis-users at lists.osgeo.org
http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
_______________________________________________
postgis-users mailing list
postgis-users at lists.osgeo.org
http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
--
[At other schools] I think the most common fault in general is to teach students how to pass exams instead of teaching them the science.
Donald Knuth
_______________________________________________
postgis-users mailing list
postgis-users at lists.osgeo.org
http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20150226/42f2d1ca/attachment.html>
More information about the postgis-users
mailing list