[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:              |
------------------------+---------------------

Comment (by dd32):

 Apologies for the rambling comment @iandunn.. I'm just working through it
 and noting my thought process for myself..

 After looking into this, there's several things happening:
  1. There was a data error, in that some of the source data had invalid
 UTF8 data which caused only partial Chicago data to be imported.

 I've re-imported the data after fixing the issues (not all committed yet)
 which results in a more complete data set, but still 'invalid' responses.

 Replying to [ticket:5562 iandunn]:
 > *
 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] )

 2. This looks correct with the current logic. Yes, hang on, let me
 explain..

  - Timezone trumps population, #3367 comes into play here.
  - Alternate names are treated as the same level of priority as
 "preferred" names

 I don't think timezone should be a trump here in every case, but rather
 only when it's a preferred name (ie. Portland, OR / Portland, ME).

 The Chicago examples has come up due to the greater number of cities after
 #3728, it looks like most of the chicago entries are ''probably''
 alternate names (There's Chicago's in every US timezone, just like there's
 a Portland in each timezone).

 As part of that, I've rebuilt the table again, this time marking alternate
 names as alts, so that preferred names can be prioritised.. Unfortunately
 I've done something wrong, and the `alt` field didn't get filled
 correctly, but from what I can tell, it'll fix these two examples and a
 few others I've been able to come up with.

 I'll loop back to this tomorrow, but if you want to Ian, you can run
 queries against the `geoname_summary_20210106082158` table to test with.
 Adding `ORDER BY alt ASC` to the start of the order by's seems to do the
 trick (Test failures such as `Dona ana` are due to the alt flag failure I
 mentioned above)

 I've struggled to test it with PHPUnit, as it keeps running out of memory
 and requires PHPUnit8 by looks (Not 6, 7, or 9 as I had installed)..

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