Hi, i have a problem with geocoder+address_field modules.

I had a content type with address field and now I create a geocoder based on this address field.

When I manually save any existing node, all is OK, it stores latitude and longitude in database.

Problem is when I try to save all existing nodes (around 1500) programatically. I had tried with VBO, using node_save and using drush geocoder-backfill, but it doesn't store latitude and longitude in database.

How can I fix it?

Comments

mpisano’s picture

mpisano CreditAttribution: mpisano commented

+1

Simon Georges’s picture

Simon Georges CreditAttribution: Simon Georges commented
Category: task » support

Did you try the drush command (see #1451942: Provide drush-command to re-geocode all empty values)?

rudiedirkx’s picture

rudiedirkx CreditAttribution: rudiedirkx commented
Issue summary: View changes
Related issues: +#2159925: Geocode from virtual fields/entity property instead of just real fields, +#1515372: Caching Results

TL;DR

The difference between manually saving (node form) and programatically saving (VBO, drush etc) is meta data in the items. A diff makes sure it doesn't re-fetch unnecessarily, but the diff is 'wrong'. The solution is to always re-fetch, but cache the specific results: #1515372: Caching Results.

Explanation:

The difference between manually saving (node form) and programatically saving (VBO, drush etc) is meta data in the items. The old and new items are diffed, and only if the SOURCE FIELD has CHANGED, the coordinates are fetched from outside. Manually saving always saves some meta data in the field items. Programmatically saving doesn't, so you have to actually change something.

That manually saving triggers a fetch, is actually a bug. It'll be fixed in #2159925: Geocode from virtual fields/entity property instead of just real fields because the diff improves.

If we want to have a 'force re-fetch' option, we'll need to add something somewhere. Maybe on the entity object, or in the field item. VBO will add neither, but the drush command could. Another way is to add an option to the field/instance to ALWAYS re-fetch, just ignore the diff, but that's ridiculously expensive.

Also related: #1515372: Caching Results because caching is the solution for everything IMO. With caching enabled, it shouldn't diff ever, It should always fetch the coordinates (sometimes from cache) and the RESULT field might be updated, even if the SOURCE field hasn't changed.

#1515372 doesn't undo the diff, so it's not instantly the solution for this problem, but it's a long way.

basvredeling’s picture

basvredeling
Primary language Dutch
Location Amsterdam
CreditAttribution: basvredeling at Code Culture commented
Status: Active » Closed (works as designed)
Related issues: +#2514834: Force re-encoding of already geocoded data

You can force geocoding on unchanged, existing nodes by applying the patch I created in #2514834: Force re-encoding of already geocoded data.
Enable debugging mode by visiting the geocoder settings page. And do a bulk (or individual node) resave.
This should encode your address fields.

I concur on the opinion that a drush command to forcefully re-geocode or a caching related solution to circumvent the diff would be preferable.

Just a sidenote: If the numbers of geocodable nodes are too high you might be running into geocoder api limits by the selected provider. For instance: google only allows 2500 encodings a day. If you are on a shared hosting environment you might've run out before you even started.

I hope that solves your support request. For now let's close this issue.
Since
a) the support request is old,
b) a work around has been suggested,
c) the code works as designed (albeit troublesome) and
d) there are alternative issues in the queue to solve the diff / cache issue at a higher level.