Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Geolocation: change lat/long from stored values to a lookup by city #2978

Closed
robocoder opened this issue Feb 26, 2012 · 1 comment
Closed
Labels
Task Indicates an issue is neither a feature nor a bug and it's purely a "technical" change. wontfix If you can reproduce this issue, please reopen the issue or create a new one describing it.

Comments

@robocoder
Copy link
Contributor

From #1823 (comments 38 and 39), Matt ponders a lookup of a city's lat/long rather than storing the lat/long in the log_visit table.

The question remains if we need to store lat/long, depending how fast/easy it is to query lat/long from a given City using GeoIP (maybe this is not possible?)

Greg posits:

Depends on what kind of database you're using. If you're using the CSV database and import it to MySQL tables, than you can run a query like

SELECT latitude,longitude FROM location WHERE city = 'Berlin'

in < 1ms. However, you will get ambiguous results when just looking for city names. Instead, a better idea would be to store the unique GeoIP location-id.

I don't know if any of the GeoIP APIs that work with the binary database (.dat) supports reverse-queries. All I saw was the IP --> location way..

MaxMind provides a CSV file of the world's populated cities (country, region code, city names, population (if available), latitude, longitude).

The space/performance tradeoff is:

  • storing lat/long in two DECIMAL(7,4) columns requires 12 bytes per row
  • the CSV file is a 32 MB download and about 126 MB uncompressed
  • the CSV file does not contain the internal GeoIP location id

Keywords: interesting

@mattab
Copy link
Member

mattab commented Feb 27, 2012

Storing lat/long sounds very reasonnable. I do not think the alternative solution is viable. If you agree, we can close as wontfix?

@robocoder robocoder added this to the Future releases milestone Jul 8, 2014
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Task Indicates an issue is neither a feature nor a bug and it's purely a "technical" change. wontfix If you can reproduce this issue, please reopen the issue or create a new one describing it.
Projects
None yet
Development

No branches or pull requests

2 participants