Closed (fixed)
Project:
GeoNames
Version:
6.x-1.1
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Reporter:
Created:
15 Nov 2008 at 14:37 UTC
Updated:
21 Sep 2009 at 13:50 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
gagarine commentedhttp://drupal.org/node/353619 marked as duplicate.
I can perhaps work on this bug...
Some poeple have already know the best way to implement this?
What do you think, is a hard job? I can start this project in one month.
My first opinion is to have exactly the same field of geoname http://download.geonames.org/export/dump/readme.txt
Comment #2
lyricnz commentedYes, of course we should have same format as the source data (but the issue above refers to the countryInfo format, while your posting is about the main geoname format).
Comment #3
gagarine commentedI have understand geoname use the same table for all geo data and one table for the alternate name. cityInfo is a dump with only the city but the structure is the same if you have city, place, country or anything else. The end of this page explain all thing about dump http://download.geonames.org/export/dump/
Correct me if I'm wrong...
Comment #4
lyricnz commentedJust open http://download.geonames.org/export/dump/countryInfo.txt in your browser, and look at the column names. These are not the same as the "main" geonames format.
Comment #5
gagarine commentedThank, Ok I understand... sorry. So i work first on this bug. After that what do you think about caching city and at the best all tables?
Here how import all tables on MySQL: http://forum.geonames.org/gforum/posts/list/732.page
I don't found graphical schema for the geoname database :/.
I assign this bug to me after I'm sure I can done this job.
Comment #6
lyricnz commentedWe've thought about this, of course. These are two facets to this;
- making it possible to load the data-dumps from geonames, and then query/search within this dataset (which will work very different to the existing web-services)
- using this data as a "local cache" for some parts of some queries.
Comment #7
Anonymous (not verified) commentedThis patch updates the schema and fixes the REPLACE statements.
Comment #8
Anonymous (not verified) commentedComment #9
lyricnz commentedCan you reroll, post code-style cleanups just committed?
Comment #10
Anonymous (not verified) commentedSure thing! Thanks.
Comment #11
lyricnz commentedApplied, thanks!
Comment #13
lyricnz commentedhook_update_n required
Comment #14
jmary commentedComment #15
lyricnz commentedjmary: why is this critical? just disable and uninstall the module, then reinstall it - and the table will be created correctly. The outstanding issue is just around the fact that the module doesn't update cleanly.
Comment #16
jmary commentedlyricnz : It is critical because the module just doesn't install correctly : the table geonames_countryinfo keeps empty.
Comment #17
lyricnz commentedjmary: did you actually _try this_? (using 6.x-1.x-dev)
It works fine. Here is a log of my session: I downloaded geonames into a default drupal6 site, unpacked and enabled it (which creates the table). I then downloaded countryInfo.txt straight from geonames.org, removed the leading comments, then use mysqlimport to load the file into the database table (checking number of records loaded against the number of lines in the file). I then queried the DB to verify that the data looked okay.
Comment #18
jmary commentedI needed to copy geonames_countryinfo.txt in /tmp to ensure that the file was in a directory which is readable by the user the MySql server is running as.
Using mysqlimport is really what does the trick. And it is fault tolerant comparing to import through phpmyadmin.
Without doing that I was getting an error 13. I'm running a Debian server.
Some remarks.
- So this is a tricky to install the module as it should work out of the box also for peoples who are not having an ssh access to their server.
- also the monthly updates to this db should also not work as the invoking of geonames_metadata_update() will fail as well.
- this way to import the data is not documented (now it is, through this topic)
- the module gmaps which is having geonames as dependancy is broken because of that problem in geonames.
- the import using directly phpmyadmin doesn't work as well as it is answering that there is a wrong number of columns.
What can be done to save others :
1- Providing the table geonames_countryinfo in the module.
or
2- updating the structure of the table geonames_countryinfo and ensure that peoples who don't have shell access can still have benefit of the module.
I have urgent things to finish this week, after that I'll provide my support to help you in that as soon as you have defined which plan you want we work on : 1 or 2.
Comment #19
jmary commentedIn attachement the table geonames_countryinfo
Comment #20
lyricnz commented1) It is not possible to include the actual data from geonames with the module, as it is licensed under Creative Commons Attribution, which is incompatible with GPL, which Drupal+Contrib is released under.
2) The format of the table created by this module matches the current format of http://download.geonames.org/export/dump/countryInfo.txt - any problems with tools like phpMyAdmin etc are not the problem of the module, as such.
3) Likewise other contributed modules (you mention gmaps) aren't our responsibility. We updated the table structure to match geonames.org - they should use our API functions, or update their queries to match the new structure
4) Agree that geonames_metadata_update() is broken. It should be updated, along with a new hook_update_nn() to allow the module to be upgraded cleanly.
Comment #21
jmary commented1- is crystal clear
2- I disagree (but not strongly) with that.
Many webmasters have only phpmyadmin to do such operations. And as the filling of the table at enabling module is broken this is leaving the module unusable and justifying the critical level of the bug.
3- Gmaps is definitely using the module API. The fact that geonames_countryinfo table is empty at enabling geonames prevents modules which are using correctly the geonames API to work.
4- It seems you persist to think that the module isn't broken at installing but only at updating. I wouldn't say so. As long as the table geonames_countryinfo is not filled at enabling the module and that is necessary to have shell access to proceed.
Comment #22
lyricnz commented4. This module never claimed to fill in the geonames_countryinfo table at install time, and there is currently no code that would do that. However, if geonames_metadata_update() was working it would load this table on the first cron call (and every month thereafter). Arguably, there should be a more human-friendly way to trigger this refresh. Feel free to file that as a feature request.
Comment #23
lyricnz commentedAdded hook_update support to 6.x-1.x-dev
Comment #24
lyricnz commentedUpdated geonames_metadata_update() to handle new columns, and use schema API. Committed to 6.x-1.x-dev.
jmary: If you want an easier way to refresh this metadata (than deleting the variable that keeps track of the interval, and re-executing cron), please don't hijack this issue - file a separate feature request.