Polygon needs to have a 'hole' to be accepted in MySQL 5.7.11?

[holtkamp]

I am not sure whether this issue 'really' applies to this library, but it might be good to be aware of, for example when dealing with validation issues like #130

While trying to migrate a database from MySQL 5.6.29 to MySQL 5.7.11, the import of a table with geographic data kept failing with an error "Invalid GIS data provided to function st_geometryfromtext.".

Further investigation pointed to a specific row which used a POLYGON that was accepted in MySQL 5.6.29, but no longer in 5.7.11. I first expected that the POLYGON was not properly closed, which is required as of MySQL 5.7.8. It turns out this was not the case, it seems a minimum number of 4 points is required for a POLYGON (it needs to have a 'hole'?). Not sure how to explain better:

#Works in MySQL 5.6.29
SELECT GeomFromText('POLYGON((0 0,0 1,0 0))');
#Fails in MySQL 5.7.11, note the POLYGON is closed
SELECT GeomFromText('POLYGON((0 0,0 1,0 0))');

#Works in MySQL 5.7.11, note it is closed and has at least 4 POINTs
SELECT GeomFromText('POLYGON((0 0,0 1,1 1,0 0))');

While glancing at the current validation mechanism of a ring, it seems this check is not included.

Note sure how to deal with this, maybe one should be able to configure the strictness of the validation (strategy).

PS: I now find myself programmatically iterating over all entries and discarding all POLYGONS that have less than 4 POINTS, hope that will result in a data set valid for MySQL 5.7.11. In case a more efficient approach in MySQL is available: suggestions are welcome. The ST_isValid() and ST_validate() functions seem to only work with geometric values, which are not available, since GeomFromText() already chokes on the provided string.

[djlambert]

Thanks for the heads up.

There's a lot of issues with validation at the moment. I've been working on a rewrite of the PHP objects to deal with this and a number of other shortcomings. I'll make sure to take this into account.

[sadortun]

@djlambert can specify the MySQL version on our Travis tests ? Would be nice to test a wider range if there is such compatibility issues.