do more with geog_auth_rec.wkt_polygon

[dustymc]

Geography with supporting WKT data is immensely better than those without.

http://arctos.database.museum/guid/UAM:Mamm:62505 has 3 event determinations. Two of them are at least close, and unaccepted. The accepted one maps to the wrong continent.

http://arctos.database.museum/guid/UAM:Mamm:21632 was used in a range distribution publication and maps a few hundred miles from where it was collected.

Etc., etc., etc.

Finding those outliers depends more or less on chance without geography polygons, but is completely obvious with spatial data.

There are two paths to spatial data

• edit geog, find "outside"
• map border color on specimendetail

I'm not sure how I can improve that with current tools; I have to use JS for everything spatial, and it's very everything-intensive. Better interfaces should be trivial with a spatial DB; flagging this infrastructure-limited.

I think the ideal is not allowing geography which lacks WKT, but I also don't think that's realistic.
We could somehow "promote" geography with WKT data.

• geog pick: somehow prefer geography with WKT?
• do something more obvious than the map border on specimen records?
• can we somehow share "these have better data and are probably more trustworthy" in downloads, via DWC, etc.?

Perhaps a "maps to polygon (yes/no)" flag (populated only by scripts) in locality as part of #1705 could serve as a kludgy and hopefully temporary replacement for spatial tools?

Fairbanks Quad according to Arctos:

Fairbanks Quad according to USGS:

How can we improve this?

[dustymc]

add geography polygons to the map on edit locality
Edit Locality now supports remote WKT

[dustymc]

"Immensely" might be an overstatement. We recently created ~150 (USGS Quad) polygons. Around 150K specimens with coordinate data use the geography records to which we attached WKT data. Around 3K of those map outside the polygons, which puts the base error rate around 2%. Without "real" spatial tools I'm looking at points rather than overlap, so this:

And this:

both just count as "wrong."

Reducing priority.

[dustymc]

Re-elevating; incoming collections tend to have a lot of data which has never been under spatial tools, and it's still too easy to find problems in long-term Arctos data.

1. A script to check for localities from a place which do not fall within the polygon defining that place would be immensely useful. This may violate Google's TOS - "No use of Content without a Google map." Without that, the only check is someone clicking edit geography-->Find specimens with coordinates "outside" the WKT. @mkoo is this something you could discuss with UC's legal folks? Am I reading that completely wrong?

#2059 is potentially a small step in this direction.

1. Checking "parent" geography would be very useful. For example here's Alabama according to Arctos:

Localities attached directly to the state are fairly clean

Finding the stuff that maps to never-never land involves stumbling upon them or checking every county.

There are also many eg, sub-county geography entries (Drainage, Feature) which do not have spatial data.

Adding a "find stuff where state=Alabama and the locality doesn't map to Alabama" option would find provide broader-scale spatial data to many specimens which currently have none.

[dustymc]

I think #2916 plus #3108 address this to a reasonable degree; closing.