I'm still trying to track exactly what causes this (as it sometimes works).

I have Location set up to show address & map for location entry. When saving a node with a full address entered including postcode but the user has not clicked on map to set location, an entry in table location_instance is created but no corresponding entry in table location. If you edit the node and use the map to set a location, an entry in table location is created. As a test I deleted the location using the delete checkbox and saved the node. Re-entering the address (again without the using map) the location table has a record for the node, but both lat & long are set to 0.000000. No failures are reported to the log.

I have a full UK postcode zipcodes table set up (has been working well with 5.x-2.7). I am using 5.x-3.dev as the location search does not seem to work with 5.x-3.0. Geocoding Options and Map Links for UK are set to Google Maps.

Comments

Balefire’s picture

Balefire commented

Additional - I have disabled the map entry, and the lat/long are set to 0.000000 when using the address form. I also checked the zipcodes table and the postcode is in it, with complete lat/long.

After a bit more testing, it appears that the zipcodes table is being completely ignored - I have tried a known postcode (BH9 2EN) which is in the zipcodes table with lat: 50.745684, long: -1.879453. With Google geo-coding turned on it is saved as lat: 50.760647, long: -1.859947. Without Google geo-coding, it is saved as lat: 0.000000, long: 0.000000.

Balefire’s picture

Balefire commented
Status: Active » Closed (fixed)

Update:
Think I have finally figured out why. I had copied the "location_latlon_rough_us" function from supported/location.us.inc into supported/location.uk.inc and renamed it to "location_latlon_rough_uk". However, in location.module "location_latlon_exact" is called, but not "location_latlon_rough". I added:

// Attempt exact geocoding.
elseif ($data = location_latlon_rough($location)) {
  $location['source'] = LOCATION_LATLON_GEOCODED_APPROX;
  // @@@ How about an accuracy field here?
  $location['latitude'] = $data['lat'];
  $location['longitude'] = $data['lon'];
  // @@@ How about address normalization?
}

starting from line 1484 and it seems to be working as intended again.

I have closed this thread, but hopefully anyone else having the same issue will find it useful.

Balefire’s picture

Balefire commented
Status: Closed (fixed) » Needs review

Not sure if I should have closed as it is not fixed as such, so re-opening for people to find. Also, as I had copied location_get_postalcode_data_us to location_get_postalcode_data_uk as well, that should have done the same job. Just noticed the queries are subtly different, will see if making them the same change the problem. Don't have time now, will try later.

yesct’s picture

yesct commented

I have a feeling there are duplicate issues in the queue... but I have to run.

This might be a lead for me or others to look into later:
http://drupal.org/project/issues/location?text=UK+saved&status=All&prior...

Also, try the latest dev version, as this might have been fixed.

yesct’s picture

yesct commented

I dont think this is a duplicate, but people who find this issue might be interested in #361655: Location data is not saved too.

yesct’s picture

yesct commented
Status: Needs review » Postponed (maintainer needs more info)

lots of changes in the new official release, and work on UK in other issues.
might be related #765564: Full UK zipcodes mysql file using Google

Please check the newest release and report back if this is still a problem, marking the status needs work (as the patch would need re-rolled).

ankur’s picture

ankur commented
Status: Postponed (maintainer needs more info) » Closed (fixed)

I believe this is no longer an issue in the currently supported versions (6.x-3.x, 7.x-3.x).