hey brandon, in supported/location.de.inc there's currently the function location_latlon_rough_de missing.
The location_latlon_rough* function scheme is deprecated, i know, but it is currently being used by your newly reimplemented proximity/distance views filter, so i implemented a simply pass-through function for the german country support-file (which of course could be rolled out into other country support files, too), see the attached patch location.de.inc.MISSING_ROUGH_FCT.patch

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

danielnolde’s picture

Title: missing function location_latlon_rough_de » 2 proposals: location_latlon_rough_default / extrenal geocoding of not-matching zips
FileSize
2.1 KB

When adding the abovementioned function i stumbeled along the question: Why not offer a default location_latlon_rough location-by-zipcode-lookup function in location.inc?! In case another country support file is missing it's own function, and most of the zipcode-lookups work the same way in many countries (exact match).
So i implemented this location_latlon_rough_default function and it's call, too, see the attached patch location.inc.DEFAULT_ROUGH_FCT.patch

Included in this latter patch is also a perhaps interesting proposal for doing an external lookup/geocoding for zipcodes which haven't been matched in the zipcode table (e.g. new zipcode or an incomplete zipcode list for some country), and storing the externally geocodet zip (if successful) for future use in the zipcodes table. That's pretty handy ... an incomplete zipcode table could be made "self-completing" this way. New externally geocoded zipcodes stored in the internal databse are missing some (not so important) data at the moment, but it may be a good start...? It worked at least for me (though i have now the zipcodes table completely filled with the data necesarry .., but other folks may profit from this functionality).

danielnolde’s picture

Priority: Normal » Critical

brandon,

the location.module is broken for german location for months now, due to an error/missing-function in location.de.inc provider, which completely break zip-lookup - the simple first location.de_.inc_.MISSING_ROUGH_FCT.patch above would solve that problem, but seems still to not have been included/committed in a current release ... this is really a simple patch which an important impact for german location users!
Could you give us an update on when this fix is going to be includec or which other solution may be in place?
If you need any help, please contact me.

regards,

daniel

YesCT’s picture

Title: 2 proposals: location_latlon_rough_default / extrenal geocoding of not-matching zips » 2 proposals: location_latlon_rough_default / extrenal geocoding of not-matching zips (location.de.inc location.xx.inc)

this is still marked needs review, can someone try out the patch and post back if it seems to work? Then change the status to Reviewed and Tested by the Community (RTBC)

marking with location.xx.inc (there are a few issues dealing with location.xx.inc that are in a similar status)

chaosprinz’s picture

Hello,
i am trying out "location.de_.inc_.MISSING_ROUGH_FCT.patch" at the moment and it seems to work good. I will give more intensive feedback tomorrow or sunday.

1st EDIT: There is one problem, but i am not sure if it is a problem of this patch, of location or a problem of views. I created a Page-Display as Gmap of a node-type called 'locations' and give it a exposed proximity-filter with postal-code-entry. This works fine.
Now i created a display of the same display as a tab. It also works.
And now i created a attachment-display as a tab and i attached it to the gmap-page and told the attachment to inherit the exposed filter. What happens is, that the exposed filter dont give the possibility to enter a postal-code. You just can enter the distance.
At the moment this is the only issue i have using this patch.

drupalok’s picture

subscibing

BartVB’s picture

:) Looks like I just implemented the same geocoding solution but limited to the dutch locale:

http://drupal.org/node/73714

The main thing missing in this general patch is something to validate/cleanup the postcode. I.e. in The Netherlands a postcode can be written as '1234 AB' or '1234AB'. This needs to be cleaned up before it can be stored in the database.

chrisimg’s picture

Category: bug » feature

In general, it seems that the location module could use that validation/cleanup for postcodes - for instance, in Canada sometimes people put in 'ABC 123' or 'ABC123.'

YesCT’s picture

Priority: Critical » Normal
Status: Needs review » Needs work

this needs to be rerolled against the most recent dev version. Thanks.

Summit’s picture

Status: Needs work » Reviewed & tested by the community

Hi, tested it and seems to work. Please reroll a patch so it can be commit in recent dev!
greetings, Martijn

rooby’s picture

Status: Reviewed & tested by the community » Needs work

Also, when re-rolling can you use the -up options.
See http://drupal.org/patch/create for more information.

It just makes it easier to review the patches.
Changed back to needs work as it needs a re-roll for current dev.

hutch’s picture

OK, here is the patch on latest CVS, rolled and named according to the inimitable rooby style ;-)

rooby’s picture

Status: Needs work » Needs review

Thanks that looks good.
I can't take credit for the naming convention though, I got it from drupal.org a while ago :) - http://drupal.org/patch/submit
Although I notice looking at it again now that in February it changed from
module-issue#-comment#.patch to module-description-issue#-comment#.patch
which makes more sense.

hutch’s picture

hehe I should rtfm more often :-)
I havent tested the patch in #11 apart from php -l location.inc but it makes sense.
It also might be worth checking wether Google can return more than just lat/lon and wether it can be collected sensibly.

rooby’s picture

Yeah, it definitely makes more sense to me too.

I have attached a file with 2 examples of google's geocode response.
Data in there that we currently don't add to the database is:

<AdministrativeAreaName> - which is the state/province.
<LocalityName> - which is the city.
hutch’s picture

Oh very good!

So function google_geocode_location() could be extended with some more preg_match.
Am I on the right track?

rooby’s picture

Yep, that's it.
I opened an issue to enhance the google geocode request.
#839412: Retrieve state/province and city/suburb information from google geocoding where available

rooby’s picture

Status: Needs review » Fixed

Committed #11.
The other discussion can continue in the issue mentioned in #16.

http://drupal.org/cvs?commit=387896
http://drupal.org/cvs?commit=387894
http://drupal.org/cvs?commit=387892

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Berliner-dupe’s picture

Status: Closed (fixed) » Active

removed

Berliner-dupe’s picture

Status: Active » Closed (fixed)
Jens_Pitch’s picture

Hi, this is my first post here. First I have to apologize for my english.

Now my question:
I don't understand where to put in this patch exactly. I found some of the lines in the location.de.inc but I don't know which lines shall be overwritten.
additionally I have to say that my scripting skills are less than worse. html and css are no problem.
Do I have the chance to get my search working under this conditions?

Thank You

rooby’s picture

@Jens_Pitch:
This patch has already been committed and it is in location 6.x-3.1 so you don't need to apply the patch if you use that version.

You shouldn't have to do any scripting.

If you are having trouble getting something working try creating a support request issue with the details of what you are trying to achieve (unless you find someone else already has the same issue).