| Bug #76595 | "Invalid GIS data provided" reported with valid geometries | ||
|---|---|---|---|
| Submitted: | 4 Apr 2015 21:10 | Modified: | 4 Apr 2015 21:15 |
| Reporter: | Benjamin Morel | Email Updates: | |
| Status: | Not a Bug | Impact on me: | |
| Category: | MySQL Server: GIS | Severity: | S2 (Serious) |
| Version: | 5.7.6-m16 | OS: | Linux (Fedora 21) |
| Assigned to: | CPU Architecture: | Any | |
[4 Apr 2015 21:15]
Benjamin Morel
Actually it makes sense: the geometry is made of a non-simple LineString, hence it is not valid. Replacing any of the polygons with a point makes MySQL return false before checking for validity, which is expected as a point cannot be equal to a (valid) polygon.
[29 Dec 2015 13:33]
Uri H
I have a somewhat similar test case, in which we have polygons which are essentially point. Nevertheless - these are valid polygons as they have a valid starting and end point.
The simple query looks like this:
SELECT ST_Area(GeomFromText('POLYGON((2.2945 48.858222, 2.2945 48.858222, 2.2945 48.858222, 2.2945 48.858222, 2.2945 48.858222))'));
The response is: "ERROR 3037 (22023): Invalid GIS data provided to function st_area." instead of a simple "0" that MySQL 5.6 returns correctly.
It's important to note that this is working just fine on MySQL 5.6 and therefore the change of behaviour (or to be more accurate - the regression) should at least be documented.
Is there at least a way to filter such rows from an existing table before running the query?
Description: When providing valid polygons to ST_Equals(), MySQL sometimes fails with: "ERROR 3037 (22023): Invalid GIS data provided to function st_equals." If you replace any of the Polygons with a Point, the error disappears, so both geometries seem to be otherwise considered valid. How to repeat: SELECT ST_Equals(ST_GeomFromText('POLYGON ((1 2, 2 3, 3 4, 1 2))'), ST_GeomFromText('POLYGON ((2 3, 3 4, 1 2, 2 3))'));