On 2/26/2015 4:08 PM, Joseph Spenner wrote:
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.
I haven't played with geography much as a data type, ymmv
Try casting the St_Intersection back to geometry and do an
ST_IsValidReason (and ST_GeometryType) on
ST_Intersection(ST_GeomFromGeoJSON('$jsonPoly')::geography, geom::geography)
or change the order on the cast to (**with correct SRIDs):
ST_Intersection(ST_GeomFromGeoJSON('$jsonPoly'), geom)::geography
and see what it says. You may be able to test for a non-polygon
(ST_Area of a (multi)linestring or (multi)point makes no sense) and/or
add ST_MakeValid around it. [not saying that is the problem - it just
might be tho]
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.
Not necessarily - just a more robust way of testing edge use cases.
and/or maybe...
is not ST_Touches (for boundary only intersections)
and is { ST_Crosses (some but not all interior points in common) or
ST_Contains(one is wholly contained in the other) }
and then test ST_Area... essentially filtering out the edge cases before
Area is taken.
and again - the specific fix is dependent upon the specific cause.
Any idea on a better way to handle this?
Thanks for your help! I owe you a beer. :)
mmm beer
------------------------------------------------------------------------
*From:* Roxanne Reid-Bennett <[email protected]>
*To:* [email protected]
*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 <[email protected]>
<mailto:[email protected]>
*To:* PostGIS Users Discussion <[email protected]>
<mailto:[email protected]>
*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 <[email protected]> <mailto:[email protected]>
*To:* PostGIS Users Discussion <[email protected]>
<mailto:[email protected]>
*Cc:* Joseph Spenner <[email protected]>
<mailto:[email protected]>
*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 <[email protected]
<mailto:[email protected]>>:
On Wed, Feb 25, 2015 at 12:14 PM, Joseph Spenner
<[email protected] <mailto:[email protected]>> 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 <http://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
[email protected] <mailto:[email protected]>
http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
_______________________________________________
postgis-users mailing list
[email protected] <mailto:[email protected]>
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
[email protected] <mailto:[email protected]>
http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
_______________________________________________
postgis-users mailing list
[email protected]
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
[email protected]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
