move georeferencing to geolocate

[dustymc]

Google's /geocode/ API has changed and is now even worse for the kind of data we normally have. Geolocate seems to do much better. Recommend we:

• feed text data to geolocate
• use the result for s$coordinates
• feed coordinate and s$coordinates to google, merge the results for s$geography

[dustymc]

This is done, but there is a related need for better documentation.

http://handbook.arctosdb.org/documentation/locality.html#specific-locality in general needs revised; the model has expanded greatly since it was written.

The idea that specific locality should be (at least in part) aimed at machines should be stressed. The GeoLocate service is generally very good when it can understand specific locality, but it just dies when it can't, and it can't understand a LOT of our locality data.

I revived Google (which isn't very good for 'rural' localities, but is excellent in cities and such) as a fallback for when Geolocate gets confused and refuses to play.

I modularized the georef function, added verbose debug code, and added a link to it in debug mode from the service window on edit locality.

Hopefully that will be useful in developing a formula for 'good' specific localities.

[dustymc]

temporarily(?) disabled pending a billing solution

[dustymc]

This is running again.

For documentation: geolocate is sometimes really picky on spelling. One locality of "Lodge Pole Creek" was coming back with basically a random point - near a lodge or something a state away. "Lodgepole Creek" (which is also the label on Google Maps) returns accurate data.

[Jegelewicz]

@dusty Are these examples and the proposed solutions still correct?

• There are some situations in which no Specific Locality is given, or no
  Specific Locality would be appropriate. For example, collecting events on the
  high seas which are specified by geographic latitude and longitude.

  • Example: North Pacific Ocean, 45 52′ 24″ N, 165 21′ 48″ W

  Or a collecting event on an island that is specified in the
  Higher Geography.

  • Example: USA, Alaska, Petersburg quad, Thorne Island

  In these examples, as well as in records for which appropriate data
  are missing, the correct value for Specific Locality is, "No
  specific locality recorded."

[dustymc]

That's not me, but...

The examples are horrid, the latter especially. Remove all examples??

Google is no longer used at all and should be removed if it's still hanging around.

Specloc as machine-readable verbatim locality is more important than ever (and #291 is relevant to that, but maybe not distilled enough for documentation yet).

There will be times when there's nothing to say in specific locality for various reasons, and No specific locality recorded. is the way to do so (for now?).

North Pacific Ocean is assertable geography, if that matters.

no specific higher geography is a sorta-new idea and could maybe use elaboration.

Given good shape-data (polygon or coordinates+error), any correct geography is about as good as anything, since all relevant geographies will be rounded up and cached (albeit eventually because https://github.com/ArctosDB/internal/issues/222). Whatever the geography given for the cooordinate example, it will end up findable by North Pacific Ocean. There's little functional difference between asserting North Pacific Ocean or no specific higher geography for the discovery of records at that point. (Asserting "Kansas" would not make it less discoverable, but would confuse anyone who found it. Asserting North Pacific Ocean might somehow lead to more believability, but I think that's really infringing on verbatim locality's job.)

Sorta-almost opposite that, given good geography and specific locality, Arctos will figure out the shape-data (and then use that to figure out appropriate geography, which might be a bit circular).

I wonder if the documentation couldn't be simplified in recognition of Arctos' spatial and webservice functionality? I think for most cases spending whatever time's spent trying to figure out geography would be better spent on writing really good specific locality data, or better yet creating a really good georeference. That's probably especially true on the end of the spectrum opposite those coordinates out in the middle of the ocean: a really good georeference that spans three counties in two states is MORE USEFUL in every way when the geography assertion isn't to a single one of those counties (in which case I'll never be sure if I should ignore the stuff in the other two, or if they just felt compelled to pick some county-level geography because that was seen as a best practice when geography was strings in spreadsheet-like structures). In other words, the georeference (plus maybe country-level geography or even 'no specific higher geography') is implicitly a geography assertion of the two states and the three counties; the record is findable by any of that.

Yea, I wandered off a bit, hope it's useful anyway....

[Jegelewicz]

Yea, I wandered off a bit

So have I - I've been editing the Locality documentation because #96 (comment)

But it looks like it really could use more and I think a lot of the examples were put there by @mkoo ? Many of them seem like good ideas (Best Practices?) that probably nobody ever sees....and I think this points to the need for deciding how documentation needs to be set up. See #251

[Jegelewicz]

Google is no longer used at all and should be removed if it's still hanging around.

Even for maps? The only references I find in documentation relate to using Google maps

in https://handbook.arctosdb.org/how_to/How-to-Search-for-Specimens.html

and to using Google to help figure stuff out

in https://handbook.arctosdb.org/documentation/higher-geography.html

https://handbook.arctosdb.org/documentation/locality.html

https://handbook.arctosdb.org/how_to/How-to-Enter-Data-for-a-Single-Record.html

and sometimes, I have no idea why

https://handbook.arctosdb.org/how_to/How-to-Enter-Data-for-a-Single-Record.html

So I think we can close this?

[dustymc]

Even for maps?

Speaking of wildfires...

https://github.com/ArctosDB/internal/issues/44

We are using Google for maps, at least until they pull the rug out from under us, again.