[wp-meta] [Making WordPress.org] #5562: Events: Exact city matches fail because of state abbreviations

[Making WordPress.org]

#5562: Events: Exact city matches fail because of state abbreviations
------------------------+--------------------
 Reporter:  iandunn     |      Owner:  (none)
     Type:  defect      |     Status:  new
 Priority:  normal      |  Milestone:
Component:  Events API  |   Keywords:
------------------------+--------------------
 These two searches (and probably many others) return the "wrong" Chicago.

 Instead of Chicago, Illinois
 ([https://www.geonames.org/4887398/chicago.html Geonames ID 4887398]) they
 return cities with an alternate name of Chicago, with a much smaller
 population. It may even match some buildings with population `0` that are
 [https://www.geonames.org/export/codes.html classified as `P.PPL`]?


 *
 https://api.wordpress.org/events/1.0/?number=5&ip=127.0.0.0&locale=en_US&timezone=America/Los_Angeles&location=chicago
 - returns Craigmont, Idaho (
 [https://www.geonames.org/5590063/craigmont.html Geonames ID 5590063] )
 *
 https://api.wordpress.org/events/1.0/?number=5&ip=127.0.0.0&locale=en_US&timezone=America/Chicago&location=chicago
 - returns `Chicago and Northwestern Railroad Station` in Kenosha,
 Wisconsin [https://www.geonames.org/5248432/chicago.html Geonames ID
 5248432]

 I've added some PHPUnit cases in r10553 (xref r10544 for info on the new
 test suite).

 It looks like the problem may be related to how cities are now being
 imported into `geonames_summary.name` as `Chicago, IL` instead of the
 canonical `Chicago` in `geonames.name`. So, they fail the exact-match
 search, and the fuzzy search turns up the less-desirable result.

 Possibly related to #3728, #5117, r16728-dotorg

 I'll look into it more tomorrow, but wanted to document what I've found so
 far. CC @dd32

-- 
Ticket URL: <https://meta.trac.wordpress.org/ticket/5562>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org