Port Geocode to D7 (Geocode was forked to geocoder)

I will certainly need one time geo and geocode for D7. But first it will be great if some patch can be committed.

So if I nead geocode for D7, I can work on a port (geo look to complicate for me, specially the SQL part) but not if they are no chance than any commit append. In this case I will prefer to look for alternative solution.

Okay, i've made an initial D7 port.

You can check it out over at https://github.com/phayes/geocode

It's still very rough around the edges, but it does work. For example:

$geocoded= geocode('geocode_google','1600 Pennsylvania Avenue, Washington DC');
dpm($geocoded);

subscribe

@phayes thanks for the port, looking good so far.

I see the code in there for parsing GPX files -- but can't seem to see them in the field configuration anywhere. How do you get geocode for D7 to support GPX files?

Point the geocode widget at a file-field at it should work (untested)

It's not giving me an option to do that...

I'm using the Geofield module, setting it to "Geocode from another field". Then on the field edit page, I just see a drop-down for the field source, and it's not noticing the filefield I have attached to the content type.

What am I missing?

Hmm, from the sounds of it you likely are not missing anything and my port is partly broken. I'll take a look

@phayes

I just tried the latest update to you port. I selected "Geocode from another field". and its not showing the addressfield that has been added to the content type.
I also update geoPHP as you instructed.

Hrmm...

Some possible problems:
1. Make sure you have ctools and libraries modules installed. These are now requirements but if you just upgraded then you may have missed this.
2. Clear the cache to regenerate the ctools plugin cache
3. Make sure geoPHP is at sites/all/libraries/geoPHP/geoPHP.inc

The the above. Then perhaps you could export your content type as a feature and post it here so I can try it out?

Thanks

Followed your directions and it still doesnt work.

If it helps, I am getting this error.

Notice: Undefined variable: available_handers in geocode_field_widget_settings_form() (line 155 of /var/aegir/platforms/dev2/drupal-7.0/sites/all/modules/geocode/geocode.module).

My content type is very basic. I only added an address field & geofield. Thats it.

Aha! I see a typo right there... It should be "geocode_handler" Sorry! I'll fix this tonight.

Actually - I've just fixed this and committed it. I'm at work so I don't have time to test it, but feel free to download again and try it now.

Well the good news is that the error is gone but I am still not getting the option to select the address field.

Okay. I'll try again this evening on a clean install.

I've tried it on a clean install and it works for me.

Step 1. Install Drupal using standard install profile
Step 2. Install geocode (git checkout from github), geofield (git checkout), and addressfield (7.x-1.0-alpha1) modules
Step 3. Add addressfield to Article
Step 4. Add geofield to article, select "Geocode from another field" as widget
Step 5. Click "Next" on first field config page.
Step 6. Get the following (image-attached) field-edit page to select your addressfield as the "Geocode from field"

Another thing to check: Check your status-report page and make sure that geofield is happy about geoPHP library

I have tried completely uninstalling & reinstalling, but cant get it to work

What..the..hell..

What about ctools? I'm running 7.x-1.0-alpha4

i am also running alpha4

Just tried it on another fresh install. Same result.

So lloydpearsoniv and I have resolved this issue offline. He had a badly named file that was breaking things. His issue was an isolated misconfiguration that does not affect anybody else.

Yeh, thanks for your help on that.

So I submitted some content & I got this error.

Notice: Undefined index: sub_administrative_area in google_geocode_field() (line 39 of /var/aegir/platforms/dev2/drupal-7.0/sites/all/modules/geocode/plugins/geocode_handler/google.inc).

And now, even a few more errors when saving the field to the content type.

Notice: Undefined index: language in geocode_widget_validate() (line 196 of /var/aegir/platforms/dev2/drupal-7.0/sites/all/modules/geocode/geocode.module).
Notice: Undefined index: language in geocode_widget_validate() (line 196 of /var/aegir/platforms/dev2/drupal-7.0/sites/all/modules/geocode/geocode.module).
Notice: Undefined index: field_address in geocode_widget_validate() (line 203 of /var/aegir/platforms/dev2/drupal-7.0/sites/all/modules/geocode/geocode.module).
Warning: Invalid argument supplied for foreach() in geocode_widget_validate() (line 203 of /var/aegir/platforms/dev2/drupal-7.0/sites/all/modules/geocode/geocode.module).
Notice: Undefined index: language in geocode_widget_validate() (line 196 of /var/aegir/platforms/dev2/drupal-7.0/sites/all/modules/geocode/geocode.module).

Aha. I think it should work fine even with those notices - but I'll fix them up.

P.S Perhaps we could take these issues over to the github issue queue so we don't spam d.o with a module that isn't even posted here yet....

sure, no problem

Alright, now would be a good time to check out the version over on github: https://github.com/phayes/geocode .

All the architectural changes I've implemented are basically done. There are still some bugs in a few of the geocode handlers, but all systems and interfaces are in place.

The following geocode handlers should work:
- Google (addressfield, text, textfield)
- exif (geotagged images) (image and file fields)
- WKT

The following could use some love:
- KML
- GeoJSON
- GPX

All the ones that could use love should be dependent on GeoPHP - so the love should actually go over there!

Subbing.
Any idea when this might actually get onto d.o? It'd probably get more attention that way.

@phayes: do you have an objection to managing this on d.o?

@allie: have an objection to making a branch for him and commit access on it?

d.o has testbots and alot of people interested in a turnkey addressfield > geocode > geofield >openlayers solution.

I would prefer to manage it on d.o as soon as allie gives the go-ahead

@phayes: I have the same issue as #17 what was the solution?

This was my fault. I updated the modules and GeoPHP library remained an old version. It works now.

I'm posting here as there is no queue for D7 and this issue is the only "7 version" related.

I'm trying to get this solution in Drupal 7: exif data (encoded gps lat/lon in jpg images) > geocode (from git) > geofield (7.x-1.0-alpha3) > openlayers mapping.

I'm geocoding from my image field ("Geocode from another field" widget) and geocoder is "image/exif".

When I save the node (the uploaded jpg image has exif/iptc data filled with external software - I checked), I get:

Warning: exif_read_data([myimagename].JPG) [function.exif-read-data]: Error reading from file: got=x3FE8(=16360) != itemlen-2=x4424(=17444) in geocode_exif() (line 16 of /home/(mydomain)/public_html/sites/all/modules/geocode/plugins/geocode_handler/exif.inc).
Warning: exif_read_data([myimagename].JPG) [function.exif-read-data]: Invalid JPEG file in geocode_exif() (line 16 of /home/(mydomain)/public_html/sites/all/modules/geocode/plugins/geocode_handler/exif.inc).

I'm not a programmer so I do not fully understand the code.

In the absence of a response from Allie, perhaps this should be brought to the attention of the d.o webmasters?

FYI. I've been working off of https://github.com/istos/geocode

Any update on if there will be a transfer of maintainers? Seems like it could be useful, particularly for the D7 port...

Both of the maintainers are active on drupal.org in other projects, so it is likely that they just haven't seen this issue or phayes' work.

It would probably be best if phayes were to raise an official request for co-maintainership in an issue.

@Shadlington
That sounds like a great idea. I didn't mean to be pushy, I know we all have a million things on our plates, etc :)

Sub

subscribe

subscribe

subscribe

following as well, thanks

Awesome! It works! Phayes, thank you very much!

It would be great to merge Phayes' work back into the d.o. repository. The code on github seems to work, and it would be nice to be able to file issues/feature requests in the issue queue against a proper 7.x branch.

Hi everyone,

i am using a filefield to load a kml file to my node.
Using geocode and i want to display an openlayer map, but nothing shows up ?
Has anayone succeed into this kind of use ?

Thanks

Using phayes' d7 port on a project I have going on right now, and seems to work great so far. Seconding the request that his code be made the 7.x branch of the module - in the meantime I'm submoduling his code into my project.

I've pulled the code from the Tree House Agency branch at https://github.com/treehouseagency/geocode. It would be very nice to see a feature where the geocode module can be specific with which fields to geocode in the Address Field form. There are cases when a person might want to write in a complete address but only have state or city, state and country geocoded. An example is the case of anywhere in the Caribbean. Most addresses other than city with island name will fail to geocode.

I also changed geocode.admin.js to load as a drupal js behavior. I'm not sure which branch to patch it against so if you're interested.

(function ($) {
  Drupal.behaviors.geocode_admin =  {
    attach: function(context, settings) {
      var field = $('#edit-instance-widget-settings-geocode-field').val();
      var field_type = Drupal.settings.geocode_widget_settings.types[field];
      var valid_handlers = Drupal.settings.geocode_widget_settings.handlers[field_type];
          
      // Filter the options list to ones that are valid for this field
      $('#edit-instance-widget-settings-geocode-handler option').each(function() {
        handler_type = jQuery(this).val();
        if (geocode_admin_handler_in_array(handler_type,valid_handlers)) {
          $(this).css('display','inline');
        }
        else {
          $(this).css('display','none');
        }
      });
          
      // If the currently selected handler is not valid, set it to the first valid handler
      if (!geocode_admin_handler_in_array(jQuery('#edit-instance-widget-settings-geocode-handler').val(),valid_handlers)) {
        $('#edit-instance-widget-settings-geocode-handler').val(valid_handlers[0]);
      }
        

      function geocode_admin_handler_in_array(needle, haystack) {
        var length = haystack.length;
        for(var i = 0; i < length; i++) {
          if(haystack[i] == needle) return true;
        }
         return false;
      }
    }
  };
})(jQuery);

I am also using the Tree House Agency branch at https://github.com/treehouseagency/geocode and it seems to be working great for my needs! From the looks of it, that branch combines code from the branches listed above and cleans it up a bit. It also has other code and fixes added.

I can't seem to figure this out. I've D7 with http://drupal.org/project/addressfield and threehouseagency version of geocode. I don't seem to find any setting and feel like i'm missing something ?! Any help would be apreciated.

@alex Did you download Geofield from phayes and the geoPHP files?

Ooops nope :) That was what i was missing then...Can you provide some links for that please ? A million thanks.

geofield: https://github.com/phayes/geofield
geocode: https://github.com/treehouseagency/geocode
mapbox: http://ftp.drupal.org/files/projects/mapbox-7.x-2.x-dev.tar.gz
openlayers: http://ftp.drupal.org/files/projects/openlayers-7.x-2.x-dev.tar.gz
openlayers_plus: https://github.com/developmentseed/openlayers_plus/branches/d7
OpenLayers.js: Taken from phaseII OpenPublic distrobution because it's a minimized slim version of OpenLayers

Hi everyone,

sorry to repost this question but i can't find the solution : has anyone achieved to display polygons on a map (using WKT, KML... whatever format) ?

thanks

SophieG, yup we've gotten it to work. Although I think the process is a little buggy and the module could use a refresh

ok, i can't display the polygon.
Could you explain me which format you are using (WKT...) and what are your parameters layer please ?

Thanks

I've tried this, thanks, and looks like to work with imagefield. But I need to use on mediafield, with that it doesn't enabled to set the media file field as source in geofield.

BTW, that would be nice, to create 7.x branch to this project, or move 7.x version to a sandbox. I think, the 7.x version is now near 'ready', so would be great to use own issue queue, not this one issue.

The 7.x branch needs to account for the case when the address doesn't geocode. It should return a warning message to the user explain one of the several different reasons why it might not work.

Not working for me either.

I am using the latest development versions of
* OpenLayers
* GeoField
* GeoCode from TreeHouseAgency

I am using geocoding from an other text field that contains GPX or KML markup.
I tried different conversions to WKT: GPX, KML, WKT Geocoders:

None was working and displayed a track.

When I was using a map as an input widget, and I was drawing some lines,
these lines were displaying as expected: So probably not a problem in OpenLayers configuration.

Do you have any suggestions what went wrong? Thanx

Please note that the Tree House Fork: https://github.com/treehouseagency/geocode is only tested with the Google plugin.

I am unable to get this to work (using the treehouseagency fork)
I am geocoding an addressfield into a geofield but no data is being saved in the geofield.

I've started a conversation about how people are using location and mapping on Drupal7, what people want to be doing in 6 months time and what people are doing to help develop or test on groups.drupal.org at http://groups.drupal.org/node/174904. If there is enough people participating the conversation perhaps we can make a survey on Survey Monkey to see where we should be investing our location and mapping time and energy. There are several different projects and we should working together especially getting Drupal 7 releases of Openlayer Proximity, Geofield and Geocode onto drupal.org.

subscribe

.

I was unable to convince allie to use the ported module as a starting point for the 7.x branch. She wants a clean port but nobody i know wants to re-port it. This one works well enough for my uses and can be patched going forward as far as im concerned.

I created a new project to house the code so we can finally move forward here and report issues and provide patches against an authoritative source. I didnt fork it lightly but i didnt see another way forward in the near term.

The module should be functional and bug reports and patches are welcome.

Marking as fixed but understand if you want to reopen, etc. This is more of a PSA for people who want to work on the project.

http://www.drupal.org/project/geocoder

Dev release should be available within 12 hours as per drupal packaging system delay.

What on earth is a clean port? If new features or code cleanup is desired in 7, that's what 2.x branches are for. We're 66 comments in here with mostly positive reviews of the port to 7.x working. Forking yet another module to further confuse the namespace is not a good solution here, although it's far better than this thread for providing feedback.

The important thing is that we have code on d.o. If the maintainer of this module is preventing that from happening within this module, a new module needs to be created. Correct me if I'm wrong, but isn't the code in this thread the basis of geocoder?

Hi michaelfavia,

Thanks for taking the initiative - I've updated my github repo to point to drupal.org/project/geocoder

@jhedstrom: i couldnt agree more but this is the best we can ask for at this time i REALLY tried to get this into the 7.x branch here and offered to maintain it myself or change anything, etc.

@sammyd56 yes i spoke with indytechcook and pulled the code from the github repos. all future development from any of the people on this thread will be done there as they are maintainers as well.

@phayes: thank you for the porting work and sorry it has languished unappreciated here for so long. I hope you dont mind me making you a comaintainer of the new project without asking but i assume youll use the power for good and not evil.

This is a mischaracterization and an over-reaction. We discussed this on IRC, and the outcome was for me to post my goals and next steps. But what we all agreed to wasn't what happened. Instead, a misunderstood version of my concerns was paraphrased, the project was forked anyway, without waiting for the input we had all agreed to wait for.

My fundamental goal is to take the time to address overlaps and areas of collaboration for the different GIS modules out there. We should agree upon common data formats so that multiple developers can work on related projects without a lot of module_exists() function calls or duplicate work. My initial version of geocode was "mostly" good at this, but certainly not ideal. I'm very much open to ideas from others, and I tried - and tried - and tried - to open up a dialog with other GIS developers on developing some guidelines in common.

Finding this common ground is a requirement for building something that we all can use. And building something that we all can use is a requirement for having a sustainable solution.

But these discussions never happened. Instead, this module was ported offsite from drupal.org, and subsequently changed in many ways. Without any discussions to identify or agree upon - or at least understand - key goals, many changes were injected into this offsite version. Bringing the work back to drupal.org is something that everyone can agree upon. But I can't just check in all the work wholesale without understanding how the changes apply to my original intentions for the project.

If we're not able to have a civil conversation and then act on what we agree to act on, then it's probably best to fork the code anyway. However, in the long run, every drupal.org GIS end user suffers. This area of focus has a notorious history of partially-complete work and competing projects. Worst of all, every developer in this space has had to "disappear" to work on other projects, jobs, etc. So after investing a lot of time eschewing someone else's work to replace it with their own, multiple Drupal GIS developers have left the scene temporarily or permanently, leaving a partially-complete project behind.

This isn't a new problem but a continuation of the same challenges we've seen over and over again. It would have been nice if we didn't keep repeating history, but if we want something that works well for a lot of people - and not just a short-term itch, we need to take some time to understand each other.

So the bottom line is that this issue isn't "fixed". I still intend to support and port the geocode module. My energy level for this will increase if we have some lively, positive discussions; and it will decrease if people use this as a forum to vent their woes and/or speak on my behalf.

@Allie Micka This might just be a communication problem or a poorly designed Drupal implementation problem as in groups.drupal.org being very outdated software. So instead of a thread moving to the top of list when updated like on drupal.org nothing happens. The conversation about location and mapping should be over there and because of this design flaw the conversation keeps fizzing out.

You will find a LOT of people agreeing with you.

I agree with Allie Micka that we need to focus and colaborate in the same direction, a fork it is to make the same mistakes that were made in the past. As said, there are too many modules for common functionalities.

But in this post there is some work done on D7 migration that wasn't commited to any branch and it made difficult to the community to find.

I think the best option here is to make two different branches of 7.x:

• 7.x-1.x - with the current work
• 7.x-2.x - with a better aproach refactoring

@allie i spoke about our conversation (not on your behalf) because this issue is almost a year old and has been begging for your involvement and consideration but you havent commented on it once until now. I hope the people in this thread appreciated the update even if it was second hand information.

I would love to plot and scheme a perfect solution to our Geo space problems with a cabal of similarly interested partners in crime but the truth of the matter is that i need this (even) in its current state for a project I'm finishing up and two future ones as well. I wont make the perfect the enemy of the good.

@jherencia: that was my single and only request in my chat with allie in irc: To use this module as a starting point (dev branch for 7.x-1.x) so we can bring issues back to d.o and talk about a solid future direction. She wouldnt and still wont entertain that option from what i can tell above.

At this point we have something that works and is a starting point for improvement. I'm not going to re-straightport it myself and nobody else i've spoke to contributing to the effort wants to either. So a fork it must be if we want it on drupal and she wont accept it as a dev branch.

This is opensource software. It routes around censorship and is owned by the public and not any individual. The inactivity of this project (no commit in a year) and the demeanor and lack of involvement by its maintainer in the issue queue as well as the denial of what i though were reasonable requests above made me question its viability here so I started one where I welcomed all comers and invited the two authors who ported the module as maintainers (with anyone that is interested welcome). You don't have to like it, you don't have to use it, it wont hurt my feelings and i hope i didnt hurt yours. i just need it and wanted to share it with others if they did as well. no drama, just requirements for work.

I would have much rather not split the module and maintain it on the 7.x branch here but that wasn't permitted by allie and I have a need for a real home for this thing so i can do my job. If the 7.x branch of this module ever comes to fruition (ill reference it, and if it eclipses the functionality of the fork ill gleefully fold it back in if thats what the people using the module want. Until then, ill be accepting patches for improvement over at Geocoder.Thats all the time im spending talking about this when i could be improving it. Best wishes, -mf

Again, it's extremely unfair to assert what I "wouldn't and won't" do.

What I asked for was a process where people's needs are put on the table. To be given an opportunity to express my goals for geocode with someone who is a) willing to hear them out and b) familiar with the changes that were made to the geocode fork. At that point we can determine a way forward that meets everyone's need, and we can leverage the collective resources that everyone has towards the process. Open source is about solving your needs in a way that helps as many people as practical. It's not "my way or the highway".

So that's what I asked for. And that's where I'm coming from. I got no response at all for over a month. Within day of our conversation, what the community got was a fork and various assertions about what I "wouldn't and won't do" based on a wild misunderstanding of my request. When I attempted to clarify my position, those misunderstandings were posted yet again as a justification for your actions.

Ultimately, what I believe is going on is this: you do not want to take the time to have the type of conversations I'm requesting. That's OK. Rather than doing what we all agreed to do and have a dialog, you forked the code. That's your prerogative. I can't stop you from doing whatever you want to do, but you are making those choices all by yourself and you're not permitted to declare that I gave you no other choice. I gave you the choice between following a path that meets the goals of multiple people. If you chose that route then you would have my time and participation. The project would be better for our collective time and energy and everyone would get a lot farther in the long run. But you chose a path that meets your own short term needs. Fair enough, we all choose our battles.

Eventually you will realize that you have implemented a solution without taking more than your own short-term needs into account then you will be stuck with the responsibility of maintaining yet another partially-complete module. It's unfortunate for everyone here but it's nothing new.

I'm starting to see a pattern here with modules maintained by Allie: #1119168: Premium has been forked.

Fork, move on and let this module die a slow death seems to be the best option.

...better not change issue title entirely. Updating the issue summary would have been more appropriate i think.