[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  |  Resolution:
 Keywords:              |
------------------------+---------------------
Description changed by iandunn:

Old description:

> 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

New description:

 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 and r16810-dotorg 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#comment:2>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org