[wp-meta] [Making WordPress.org] #2823: Improve IP Geolocation Results

[Making WordPress.org]

#2823: Improve IP Geolocation Results
---------------------+-----------------------
 Reporter:  iandunn  |       Owner:  iandunn
     Type:  defect   |      Status:  accepted
 Priority:  normal   |   Milestone:
Component:  API      |  Resolution:
 Keywords:           |
---------------------+-----------------------

Comment (by iandunn):

 Replying to [comment:38 ocean90]:
 > Searching for "Köln" gives me a "We couldn’t locate Köln." error but a
 search for "Cologne" or "Koeln" returns the proper "Köln". "Münster" is
 working fine so I'm not sure if it's an issue with umlauts.
 >
 > Another oddity: "Düsseldorf" returns "Düsseldorf-Pempelfort" which is
 kinda unexpected because "Pempelfort" is just a city part of "Düsseldorf".

 I think most of the charset issues have been worked out, but there's still
 at least one that I know about (see the unit tests).

 @dd32 is working on upgrading our geocoding from geonames.org to Google's
 Geocoding API, which should fix all of that. See [attachment:2823.2.diff].

 Replying to [comment:39 pbiron]:
 > As I mentioned in the devchat yesterday, searching for "Gardner, CO"
 gives events in Kansas City, MO...which is almost 700 miles away. Looking
 into the community-events-location meta_key, I see that the lat/lng stored
 is for KC, MO, which explains why it showing event for KC, MO.

 I think that's an edge case just because there's not enough information to
 distinguish between the two Kansas Citys, since they're so close to each
 other geographically.

 [wp40774] might be able to help there, though, since we could use the IP
 geolocation as a signal. We'd also like to have the API start returning a
 list of alternate locations, and have Core display those in a dropdown for
 the user to choose. That'll probably have to be 4.8.1, though.

 > However, if Otto's comment is correct that place name searches are using
 geonames.org data then that is odd, because
 http://www.geonames.org/search.html?q=gardner%2C+co&country= correctly
 finds Gardner, CO (with the correct lat/lng) as the 1st result.

 Otto's definitely correct, but the code does a lot of gymnastics to try
 and parse the query and look it up in a lot of ways. There could be a bug
 in there, or just some conflicting edge cases, etc.

 Dion's work to switch to Google's API should help there too.

--
Ticket URL: <https://meta.trac.wordpress.org/ticket/2823#comment:40>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org