Closed (fixed)
Project:
Location
Version:
5.x-3.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
26 Jan 2009 at 01:53 UTC
Updated:
4 Apr 2010 at 07:34 UTC
It appears that the longitude and latitude coordinates are transposed - this causes the proximity search to break.
I have attached a new sql script for inserting the zipcodes into the database.
| Comment | File | Size | Author |
|---|---|---|---|
| zipcodes-au.zip | 171.57 KB | ntt |
Comments
Comment #1
Chad_Dupuis commentedSlightly different issue, but I've noticed that neither of these files (your new one or the one that is shipped) can be imported because of duplicate keys....
The table is setup with country and zip as the primary keys so these will not import beyond the first two entries. As the primary key (zip) is identical in many of them - only the lat long, etc. is different
So either the zipcodes table should be setup differently, or I am missing something?
Have you changed your database settings to get this to work?
Comment #2
ntt commentedI changed the primary key of the zipcodes table so it is not keyed off country/zip, but rather state/city/zip. See http://drupal.org/node/42901.
Comment #3
Chad_Dupuis commentedFor an international site, I don't think that would work as an overall fix. In the US each city within a particular state might have many zipcodes.
So your fix will work in countries where the same zip is used in multiple cities, but not in countries where multiple zips are used for the same city.....
Comment #4
bdragon commentedJust fixed the primary key issue by dropping the key. Looking at the patch now.
Comment #5
bdragon commentedActually, the problem with the dump is it doesn't specify the columns... I can't guarantee that the columns of zipcodes are in the same order...
Comment #6
yesct commented#42901: Zipcodes are not necessarily unique WITHIN a country mentions Australia, so it might be related. Also, people searching for location.xx.inc might be interested in this issue. And, .... regarding bdragon's last comment, is some change to the sql script needed? Something to specify the column names?
Anyone, is this data update still needed?
Comment #7
yesct commentedclosed. no one has responded. if someone has more information, please update the status to reopen it. thanks.