Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Related issues
Problem
When I click the "Re geocode" option in the location form while editing a node with some bad coordinates ("Source Geocoded (Exact)") and then save, nothing changes. However, if I delete the location and re-create it with identical values, I see the change I'm looking for.
It seems to me that this option just doesn't work.
Some history for my particular case: The site that I'm troubleshooting was recently running 7.x-3.2-beta2 which seems to have been generating coordinates that were slightly off (a fairly new behavior, it worked fine for most of its life). After updating to the latest 7.x-3.6, geocoding is getting me the correct coordinates now. I noticed the handy new 're geocode' option and tried to use it to fix my locations that were botched, but as mentioned - no dice. Only deleting and re-saving gets my coordinates back to normal.
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | location-re_geocode_option_effectiveness-2423769-2.patch | 2.69 KB | ndewhurst |
Comments
Comment #1
hyperlinked CreditAttribution: hyperlinked commentedI'm assuming that you're using Google Maps as your geocoding service. What's happening is that when at attempt to re-geocode is made, it calls the location_latlon_exact() function, which in turn calls the service that you'll be using. If it's Google, the function it tries to call is google_geocode_location().
Unfortunately, that function no longer exists. In 3.5 it was located in /location/geocoding/google.inc. I devised my own workaround to return the latitude and longitude for these cases, but it probably goes counter to workings of the location module.
Comment #2
ndewhurstI encountered this issue as well. The "Re geocode" option introduced in https://www.drupal.org/node/1948640 does prevent location_save() from returning prematurely when no data has changed, but _location_geo_logic() performs its own, geocoding-specific check to see if any relevant data has changed, which is where this breaks down. This patch pulls the option into a simple param that now gets passed through to _location_geo_logic(). I tried to mimic the existing code style with respect to the $inhibit_geocode var that was already present. Note that $inhibit_geocode, which is not derived from a user selection, takes precedence over $force_geocode.
Comment #3
podarokThanks a lot.
About to be pushed to latest dev