Working on adapting Location to work with Google's geocoding service.
After a lot of effort, have finessed Locate#geocode to mostly work. Had to remove support for sublocalities and administrative area level 3s, though, due to Google's geocoding service not supporting specifying what level of a hierarchy one is searching for.
Tweaking #geolocate to work better; it now delegates the initial lookup to #reverse_location_search, which performs a series of nested bounds searches over currently known locations. Still requires (a degree of) exact text matching, but is safer than what was being done before.
Attempting to get the newer mongodb geospatial queries to work.
(#5) While imperfect, have provided a fix for boundary searches which cross the anti-meridian. Such searches break a criteria chain, which makes them not work too good within the broader ecosystem. However, they should work properly for the purpose of geocoding.
Changed the way that #short_or_long_name works, in an attempt to bias results towards localities. See comment on #geolocate.
(#2) Both Google's geocoding and timezone APIs are being used by Location; as far as I can tell, usage should be mostly correct, though there are bound to be bugs lurking deep under the covers.
Testing the new geocoding functionality against the incident scraper.
The incident scraper will now add failed entries to the database without fully processing them. Added a note to location regarding a way to more properly target certain geocoded results.
(#2) #geocode now takes an optional type parameter which, if present, filters the geocoded result set. This allows greater precision in targeting specific levels within the hierarchy of geocoded results. Also, should avoid a few erroneous search loops from occurring.
The UI now takes into account the modifications brought about by the geocoding refactor. While the UI will change later, the system is at least where it was before the refactor began, which is something.