Posted by kulfi on July 19, 2008 at 9:20am
| Project: | CCK GMap Address |
| Version: | 5.x-1.0-beta3 |
| Component: | Code |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
I'm not sure why I'm getting "The address in field_address[0] could not be validated as correct address!" error message. I'm entering an Australian address.
Comments
#1
I have this same problem. A typical American address (that works on maps.google.com) returns:
"The address in field_gmap_address[0] could not be validated as correct address!"
Also the page looks like this, with the map half-rendered.
See attachment.
#2
Did you set the correct Top-level-Domain in your field's settings?
I added a new dev-version to CVS, it should be provided this night. (Or simply download the attached new .module).
If the errors still occur, please give me a screen of your field's settings.
#3
set it to patch
#4
I'm still getting this error message with the current (Jul 01) dev and beta versions. Has the patch been applied to these?
#5
Unfortnately not, since my cvs update on July 24th there wasn't built some nightly dev release. Therefore please use http://drupal.org/files/issues/cck_gmapaddress.module.txt to replace the old .module. It'd be nice if you'd report the result (and on errors please take some screenshot of your settings).
#6
Hi, I'm getting the same issue of address not validating. One thing I've noticed is that after I set "minimum accuracy" in the data settings, when I save and come back minimum accuracy reverts to "0 unknown location." I've tried the current beta and dev versions, and the new .module file you posted above. I'm including a screenshot of my settings.
This is a great module, and I'd be happy to help with documentation, testing.
#7
Top Level Domain has to be set to 'com' instead of 'http://maps.google.com'.
Accuracy: you have to change line 30 to
'#default_value' => $field['accuracy'],Accuracy was saved correctly, but not fetched correctly on settings page. But that was not part of the original problem.
Sure you're welcome to help with documentation and testing ;)
#8
Patch seemed to work, though you still have calltime references in them which will generate PHP errors. Please update snapshot when you can and I'd be happy to provide a patch against it.
I initially missed a step to change the field display setting to Gmap - single, after which maps did indeed display.
Also, the address validation is slick... definitely have a few projects that could use this. Thanks for sharing!
#9
Hi – is the attachment in #2 still the best version to use?
Cheers!
Scott
#10
Yes it is. I hope this night the current .x-dev will be built, so you can download it in package. So CVS is actual.
#11
nightly dev build did not work, so I released a beta 1.1, so best version now is .beta1-1
#12
i'm having the same problem on the new beta3 version. I am using CCK Address module to collect the address data and I am using CCK GMap Fetch to use those fields. The CCK address was already set up so I figured the fetch would be perfect.
The problem doesn't seem to be the fetch module as I am getting the same geo-locating error with the "build a Gmap Macro" menu item. Which means that the Gmap module is somehow using a different geo-coder then what maps.google.com which may be just a matter of Google is providing a different geo-coder for it's Google maps API then what is used on maps.google.com
However, there is a small bug when "Rebuild the GMap Address Data" is used in that on line 149 you have $variable_set when it should be variable_set without the $
#13
The variables_set problem has allready been fixed.
Geocoding validation is a feature of the module. It uses the maps.google API (like gmap.module). For some reasons there can be differences on different top level domains, so you can select a specific one in your field settings. If there cannot found any geodata for the given address, the module returns an error. (Different validation modes are introduced with http://drupal.org/node/474994)
#14
Automatically closed -- issue fixed for 2 weeks with no activity.