importing dublin core Coverage data to Neatline

I'm not sure if I understand how to get spatial coordinates that I enter into the Omeka coverage field to show up in a Neatline record. I just upgraded to Neatline 2.2.0. I am entering "POINT (41.710718 -74.572792)" into Coverage then linking to that record in Neatline - I don't see any point automatically showing on map. I am a newbie at this so maybe I just don't understand how to format WKT?

I was having the same problem, and found that Neatline only imports the WKT when WKT is in the first Coverage field. It probably also only works if it is the only content in the coverage field.

When my fields were ordered

1. Coverage: Plain Text Location
2. Coverage: WKT POINT

Neatline did not read the WKT.

When the fields were ordered

1. Coverage: WKT POINT
2. Coverage: Plain Text Location

Neatline read the WKT just fine.

Hey thanks for your help, I had a similar issue. My problem is that "POINT (41.710718 -74.572792)" becomes "POINT (0 0)", any ideas why?

Bixente

I'm having the same issue as aherman and Bixente, and I only have one coverage field. I imported via CSV Import and "POINT (39.954119 -75.162482)" does not immediately show up on the map until I manually add it to the spacial data. Then it just maps "POINT (0 0)", but the spacial data doesn't change. Are the WKT coordinates formatted differently in Neatline's map?

Hi everyone,

So what's going on here is a projection issue, one of the harder problems to tackle in the interface. The plugin uses a Spherical Mercator projection (EPSG:900913), but the points you're using are in what looks like WGS 84 (EPSG:4326). I have a gist that will convert the decimal degrees used in 4326 to the meters used in 900913. https://gist.github.com/waynegraham/9213901


var degrees2meters = function(lon,lat) {
var x = lon * 20037508.34 / 180;
var y = Math.log(Math.tan((90 + lat) * Math.PI / 360)) / (Math.PI / 180);
y = y * 20037508.34 / 180;
return [x, y]
}

console.log(degrees2meters(x,y));
[-13002500.046098767, 4447672.181554736]


(You can use this in the developer tools in your browser too).

If you use this value in the in the WKT field, you should see a point in Arizona


POINT(-13002500.046098767 4447672.181554736)


There are actually two things going on here, you'll notice I swapped the order in which the values were added to the POINT definition. This is a weird thing, but we typically say the coordinates in latitude/longitude. If you can remember back to middle school and the cartesian plan, latitude would be the y-axis, and longitude the x-axis, so these get flipped from the way we say them. In the conversion of the points, they're basically outside the bounds and get rounded to what's affectionately known as null island (0,0).

Anyway, hope this helps clear things up.

Best,
Wayne

Hi Wayne,

Thanks very much for the clarification and javascript. If I switch the x and y values, it throws off the point. However, if I keep them the same (i.e. x = -73.96720826625824, and y = 40.802976285024634) they correctly map a point in New York City.

One more question: when I attach an item with the POINT coverage data in the coverage field, it does not auto-populate the Spacial Data field, and the map does not update, even after saving and refreshing. Is there a fix for this?

Thanks,
Caleb

Hey Caleb,

What version of Neatline are you using? That should work as expected in v2.2+. One caveat - the WKT has the be _first_ element text on the item. So, if you had three inputs for the "Coverage" element, and entered POINT(1 1) into the second input, it won't get sucked up by Neatline. This should be fixed - Neatline should iterate over all of the element texts and try to find a valid WKT string in all of them.

If the WKT is in the first input, and it's still not working, then something else is awry. Let me know!

-David

Hi David,

I'm using v2.2.1, and my sample CSV Import item data has the columns (in this order): Title, Description, Coverage. There’s only one input in the Coverage field, and it does show up on each item's page, as well as when I attach the item to a record.

Caleb

Hey Caleb,

Hm, that's strange, I can't replicate this. Can you paste in some of the exact values you're using in the "Coverage" fields on the items? Also, try this - open up the "Developer Tools" in Chrome, click over to the Javascript console, and try linking an item to a record and saving the exhibit - do you see any Javascript errors?

Also, when you save the record, do you get an error notification in the interface? Or just the "Record saved successfully" popup?

Thanks,
David

Hi David,

For my three examples, I'm using these values (respectively):

POINT(-73.96562576293945 40.78814511323808)
POINT(-73.95524024963379 40.77358687568842)
POINT(-73.98416519165039 40.77254687948199)

I'm not getting any errors upon linking the item and saving, but on the page load it looks like I'm getting a couple of resource errors, which have broken links, along with a function error:

Failed to load resource: the server responded with a status of 404 ----- (Not Found) http://vm-ds.haverford.edu/omeka-starter/neatline/items/25?record=59
Failed to load resource: the server responded with a status of 404 ----- (Not Found) http://vm-ds.haverford.edu/omeka-starter/neatline/items/25?record=59
event.returnValue is deprecated. Please use the standard event.preventDefault() instead.

When I save, I get the happy "Record saved successfully" popup—no errors to be found.

Thanks,
Caleb

Hi again,

Having tested it again, it seems that the WKT autofills now, but each point still jumps to null island. I exported these points from Google Maps KML.

Is this because they are still incorrectly formatted—WGS instead of Spherical Mercator? Is there some sort of plugin/CSV Import tweaking that can auto-convert Google Maps KML point data to the correct Neatline projection, without having to manually run it through the JS file each time?

Thanks,
Caleb

Hey Caleb,

Yep, that is indeed the problem. A number of people have run into this issue, and we've been talking about how's best to fix it - I _think_ it's possible to automatically reproject the geometries to match the projection of the current base layer using OpenLayers, which would make it possible to use either WGS or Spherical Mercator WKT without running into problems. I've filed a ticket on GitHub about this:

https://github.com/scholarslab/Neatline/issues/292

Anyway, this really should be abstracted away from the user - we'll try to get this fixed in a future release.

Best,
David

Hi All,

Picking up a year after the fact; this was really helpful thread, thanks.

I'm currently working with a history class that is using Omeka+Neatline; students were interested in "pinning" specific locations on a map (either via Omeka/coverage field, or via the Geometry options w/in Neatline).

For students who have lat/long coordinates for their artifacts and/or points of interest, my colleague Rich used Wayne's code to help students get from lat/long (WGS84) to the proper WKT for Omeka.

You can see the tool in action here: https://rich.shinyapps.io/geocoder/

Thanks to Wayne for posting his code, and thanks to all of you for the discussion.

cheers -
-kristin

Hi Kristin,

This is pretty cool. Would you be willing to write up a tutorial we could include on the Neatline site?

Wayne

Hi Wayne,

Sure thing; hopefully will have something for you by the end of the week.

-kristin

Hi all --

The geocoding / conversion tool is up and can be found here: https://rich.shinyapps.io/geocoder/

Documentation is fairly simple, in the left sidebar of the page. Thanks to my colleague Rich Majerus for making this possible.

cheers -
-kristin

Thanks Kristin,

We'll get a link to this in the documentation on Neatline.org. Thanks to you and Rich for putting this together!