search

performant-software / Neatline

A lightweight framework for building interactive maps and publishing them on the web.
www.neatline.org
Other
105 stars 34 forks source link

WKT strings in DC:Coverage is imported but not saved #388

Closed jeremyboggs closed 7 years ago

jeremyboggs commented 8 years ago

If you link a Neatline record to an Omeka item with a WKT string in DC:Coverage, Neatline successfully fills out its own Coverage field with that string, and the geometries appear on the map. But Neatline's Coverage field is wiped after you close the item in the Editor.

On Omeka 2.4 and Neatline 2.5.1.

jeremyboggs commented 8 years ago

User error. Invalid. Closing.

erochest commented 8 years ago

Still weird that it shows up on the map at all. That seems like a bug.

jeremyboggs commented 8 years ago

@erochest That is true. It wasn't saving, I guess, because I inadvertently put a comma between the values in the point string, e.g.:

POINT(-8081795.0304667, -4683545.4766366)

Once I removed the comma from the string in the DC:Coverage and imported the item again, it saved and persisted. Guessing Neatline is doing some sort of validation on its own Coverage field that doesn't like commas. The points did show up on a map with the comma in there. There was no error when I clicked "save" on the Neatline record either. It just went away when I hit the X to close the item and go do other things in the exhibit.

So...could reopen this, with a better description.

erochest commented 8 years ago

That would be the problem. Neatline on the server uses a different parser than the front end does. We at least need better error messages or something to make this less surprising.

akstuhl commented 7 years ago

Able to reproduce this bug with item coverage set to "GEOMETRYCOLLECTION(POINT(-60626.80528947, 6661916.076664))" — the point appears on the map after clicking Save, but the value does not persist in the record's geometry field, and the map marker disappears upon record close without reappearing.

This behavior is likely the same observed in #392.