Cannot get geometry object from data you send to the GEOMETRY field. about neatline HOT 14 CLOSED

Attempting to export and import one of the databases for my omeka 2.6.1 instance. I am currently running mysql 5.1 and trying to import the database into mysql 8.0. I get the following error when I attempt the import. It appears to be associated with the Neatline Plugin. ERROR 1416 (22003) at line 703: Cannot get geometry object from data you send to the GEOMETRY field. I also tried to import the mysql dump into mysql 5.7 and got the very same error message. Is there a fix available for this?

from neatline.

Hi tpegues2,

We've run into this issue with migrating to new versions of MySQL before, and have a potential solution - please see this troubleshooting post in our documentation for further info: https://neatline.org/docs/troubleshooting/

If you have any questions, or need further troubleshooting, please respond here and I will pass the issue on to our developers.

Thank you,
Elizabeth

from neatline.

from neatline.

Hi Tharrow,
I really thought that we figured out the migration issues with the null coverage, but I guess we missed something. If your records data isn't too sensitive, could I have you send a copy of your coverage column to me at [email protected]?

select astext(coverage) from omeka_neatline_records;

from neatline.

from neatline.

from neatline.

from neatline.

from neatline.

from neatline.

from neatline.

Hi Tharrow,

Sorry about the delay. I figured out pretty quickly that there were eight specific lines out of the data you sent me that mysql did not like. However, I'm not actually very conversant in WKT, so it took me a little bit of staring to figure out what distinguished those lines from the others. Turns out, it was actually pretty obvious.

Valid WKT Polygons must have at least 4 points: three or more vertices and one additional point equal to the first that closes it off. The eight lines contain polygons that do not meet this criteria. These are not meaningful polygons and should be redefined as points or lines instead. If there's some reason that you really want them to be polygons, it is apparently valid (at least to mysql) to simply add one or two identical end points.

So: POLYGON(0 0, 0 0) and POLYGON(0 0, 10 10, 0 0) are not valid, but POLYGON(0 0, 10 10, 0 0, 0 0) is.

I hope that clears things up. I will send you the 8 offending entries through email and leave this here for posterity.

This is of course concerning for us because neatline shouldn't allow the creation of these invalid polygons. We'll discuss it internally and probably create a new issue to add some validation logic to prevent this.

from neatline.

Hi @tpegues2, I'm not sure if this issue was resolved or not - but we now have a potential patch for the issues that have come up related to MySQL migrations. If you are interesting in testing out this plugin version, you can download it from this branch:
https://github.com/scholarslab/Neatline/tree/bug/mysql-functions

If you continue to seeing errors with the Neatline plugin, please let us know.

from neatline.

@eam5 Sorry, I just forgot to close this ticket. I sent the corrected SQL to @tpegues2 over email back in July and that seemed to have worked.

The most recent fix should have no impact on this issue. Since the MySQL docs indicate that "ST_GeomFromText(), ST_GeometryFromText(), GeomFromText(), and GeometryFromText() are synonyms", that update should not functionally change anything for older versions which still support GeomFromText.

That is, we still need to figure out how to mitigate the invalid polygon generation problem. Although knowing about the issue does allow us to guide users through migrations, it's certainly not an ideal place for this to be.

from neatline.

from neatline.