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

 @dd32 has a really good idea to modify the process a bit. I think will
 make things simpler on the client side, while still staying within the
 EULA.

 When the client makes a request for events and provides the IP, we
 geolocate that IP from `ip2location`, and fetch the events that are close
 to it. We do not return the location data provided by `ip2location` to the
 client.

 At this point, the `response` object being built looks like this:

 {{{
 {
   'location: {},
   'events: {
     {
        'id' => 1234,
        'date' => 194323423,
        'type' => 'wordcamp',
        'title' => 'WordCamp Seattle',
        'location' => 'Seattle, WA, USA'
     },
     // more events here
   }
 }
 }}}

 The `response.location` is empty. The `response.events[0].location` field
 above is pulled from `wporg_events`, and originally comes from the
 WordCamp.org API.

 The next step is to take that `response.events[0].location` field, and
 search our `geonames` table for it. `geonames` is Creative Commons
 licensed, and provides `latitude` and `longitude`.

 So now, we can populate the `location` field in the response with the data
 we've pulled from `geonames`. Now the `response` object looks like this:

 {{{
 {
   'location: {
      'name' => 'Seattle',
      'latitude' => '47.200324',
      'longitude' => '-121.32523',
      'country' => 'US',
   },
   'events: {
     {
        'id' => 1234,
        'date' => 194323423,
        'type' => 'wordcamp',
        'title' => 'WordCamp Seattle',
        'location' => 'Seattle, WA, USA'
     },
     // more events here
   }
 }
 }}}

 This way, we can still return a location to the client in the initial
 request, but we're not directly exposing the location details from
 `ip2location` at all. The previous approach was essentially the same
 thing, but the `response.location` lookup was being done in a subsequent
 request (see comment:17), rather than all at once.

 @barry, do you see any problems with that?

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