sharing collecting events

[dustymc]

Can we do with collecting_events what we've done with localities WRT sharing?

[campmlc]

yes, please. Necessary for parasite/host relationships.

On Tue, Jan 3, 2017 at 9:40 AM, dustymc notifications@github.com wrote:

Can we do with collecting_events what we've done with localities WRT sharing?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/1017, or mute the thread https://github.com/notifications/unsubscribe-auth/AOH0hE6I0tW84EserRxH9xy-PJCDeuXMks5rOnoAgaJpZM4LZyqK .

[ekrimmel]

Ok, here's an example of why people probably didn't want to share collecting events in the past. Higher geography of "Africa, Kenya" got georeferenced despite the fact that none of the specimens have a specific locality. I could be misunderstanding what happened, but to me our specimens with this locality now look "wrong" because a point shows up on a map and makes it appear as though we know exactly where these came from (even though the error on the georeference is huge).

I think this is probably a social/procedural problem for us rather than a database issue. Although I'd also argue that specimens without a specific locality should not be getting point georeferenced.

[dustymc]

share collecting events

The georeferencing - anything you'd see on a map - happens to the locality, not event (which contains "verbatim coordinates").

point shows up on a map

Points are just wrong, but sometimes I don't have the resources to do anything else (circles are computationally expensive!). I THINK I have all the public interfaces dealing with shapes (circles) now, but definitely not the internal stuff. And edit locality is doubly-weird because the webservice suggestions are points, so even if we do have a shape then displaying it makes things hard to compare.

without a specific locality

Drawing precision inferences from the structure of the data is usually a mistake. Geography includes oceans and such, but also very precise things - the intersection of state/county/park/etc. might be a few acres. I collected a lot of "no specific locality" specimens because I was strapped to a very expensive WAAS-enabled GPS at the time - why would I want to introduce garbage by recording where I THINK I am when I KNOW where I am (just not in strings!)? I'm sure there are many more examples - structure and accuracy/precision are not related.

point georeferenced

Error=0 should ALWAYS be interpreted to mean "we have no idea" rather than "infinitely precise." I'm up for clever ideas on how we better convey that.

In any case, I don't see the problem here. The text data are "Kenya, and there's some weird field that demands we try to be more precise in the most imprecise way possible but we don't have anything else to say!!" and the spatial data do a pretty decent job of reflecting that.

That level of precision is useful for all sorts of things - it'll show up in my spatial query for "circle including all africa" and if I find a bog lemming from there I'll be concerned and for the specimens with an elevation of 14000-15000 feet I can eliminate everything except two floppy donuts (just need better spatial tools!) and .... - those are REALLY useful data, even if they're not tens-of-meters precision!

[ekrimmel]

Thank you for explaining, this makes much more sense to me now and I'll take back my above complaints :)

Would it be computationally expensive to default the google map interface to a more zoomed out view (one that captures the extent of the error, e.g. what's above)? I get why there's actually no real problem here, but I do still think it's misleading when the first map that shows up is way zoomed in:

Also, point taken on "no specific locality" equating to "not appropriate for point georeferencing." My head is always in legacy data land...

[dustymc]

If I already have the extents, it doesn't "cost" much to do stuff with them. #1129

[dustymc]

AWG consensus: go (but review #1023 first)

[dustymc]

1023 is implemented, so I don't think anything is holding us back on this.

• Has the shared locality model caused any problems?
• Are the emails useful?

Etc. - anything different we should do here, or shall I just do what we've done for localities to events?

I'll try to start on this next week if there's no further feedback.

[dustymc]

Lacking further feedback, I'll implement this the same way localities have been: changes will be logged and daily summary emails will be sent.

[dustymc]

This is now implemented