Make Google maps geolocation widget compatible with Geofield

Hey, I just noticed this issue so I thought I'd drop a line here (I'm the lead maintainer of the geofield module)

Indeed co-operation would be fantastic so we don't duplicate effort. It would be great to integrate your awesome HTML5 geolocation widget into geofield. I would also invite you to be co-maintainers for geofield if that would interest you.

Couldn't this be done fairly easily by adding a few field types to the widget info? My initial reaction is I would be opposed to folding this module into geofield, because this is a lighter weight module that works perfectly for applications that are only interested in address info. This module is also laying the groundwork for proximity searching and I don't know what geofield is doing in that area.

I was careful earlier to say it was my initial reaction, because when I don't know much about a subject, my initial reactions often change after I learn more. Phayes's project does require you to have ctools installed, and requires you to download a third party library, but the code itself is fairly lean and mean. I was under the impression that there was a lot of different storage types in geofield, and was surprised to learn that all geometry types are stored in a single WKT field. The WKT storage is a standard, and I like standards. These guys want your html5 widget. I also like the javascript google maps widget, which is different from what phayes did in geocode. It would be good if these worked with geofield.

On the other hand, I have now learned that storing lat and lon in their own database columns, as Geolocation Field does, allows lat and lon to be indexed, which optimizes distance searching. So it tuns out that your choice of storage solution may be influenced by how you want to use the data.

@gagarine, thanks for contacting me.

First of all: Unfortunately I got distracted from the active development of Geolocation Field, but I am following the discussions and I'm still trying to figure out the best approach for data storage.

The question is: what is a geolocation?
- lat/lng-pair
- Address (this how humans read/store/process geospatial information)
- an array of lat/lng-pairs (a street is not located at one single point, an area can't be described by one point).
- Sometimes it makes sense to store more information than a lat/lng-pair. A place of birth e.g. is more or less location in "space time", so we'd need to store a timestamp along with the lat/lng-pair.

The geofield module can store geographic location data for points, lines, and polygons. So it solves a specific problem. But it does not solve all possible problems. We could use Address Field for storing addresses, geofield for lines and polygons, store timestamp along with lat/lng in Geolocation Field. I don't know if this is a good approach.

Is there a way of storing all relevant information in one module? Does it make sense to use different modules? I really don't know. The question is where is the best point of splitting the functionality in different modules.
- Geolocation Field only as a widget (HTML5 / Gmap / ...)
- Geolocation Field as a widget/storage tool (maybe even only storing part of the data)
- Geolocation Field as a widget/storage/processing-tool (proximity search)
- Geolocation Field as widget/storage/processing/formater

Somehow my gut tells me that storing all in one place could be the best approach.

Opinions?

Maybe the best approach is to store lat/lng-pairs in one "lan/lng" table:

• latlng_id
• lat
• lng
• array_id (points are always part of an array)
• array_position (0=start, 1, 2, 3, ..., x=end)

and meta information in a second "array" table:

• array_id
• array_type (0=point, 2=line, 3=area)
• array_timestamp (optional)
• array_meta (The name of point [e.g. Adress], line [e.g. Street], area [e.g. Country], spacetime event [e.g. Date of birth, Arrival, Departure, etc.])

Could this be a generic approach for geospatial information?

@gagarine You are right, I missed that lat and lon have their own fields in geofield.

@derjochenmeyer. Somehow I managed to stumble upon some useful information. You might want to take a look here and here. These are what I've been working from. I think we all need to realize that working with nodes and fields has some inherent limitations, and as long as we're using that format, we're not likely to come up with an ideal, standards compliant solution.

To summarize, the standard way to implement this would be to have the geometry and indexing columns in one table, and features information in other tables. Nothing is written in stone. It's fine to put some feature attributes in the geometry table if you need to. If you're trying to build a system that will handle every possible situation and be interoperable with other systems, that's one thing. If you're building a system for limited use cases, that's another. I think our main concern with Drupal is how to play nice with other modules, within the limitations of the system.

If geofield wants to use your widgets, I think that could be done fairly easily. In fact, I think phayes could probably do it within his own module (with an alter hook), but he might have to list Geolocation Field as a dependency. Of course if you want to merge with geofield, that's up to you. All I'm saying is I don't think that's necessary just to get your widgets to work with geofield.

Sub.

Subbing

Joining the conversation

I think a good option would be to have Geolocation store its data if users wants a one module solution, but we can make the widgets compatible with geofield in case more functionality is required. Because even when it might seem like dup of efforts, from a admin/user point of view, installing 2 modules + 1 library and keeping track of them might be too much effort if they just need a simple "location" field.

I would like to offer a very simple module for very simple needs.

As for the Address deal, I do like the idea of using Address Field. I was actually playing with that idea on my mind even before reading this issue.

@jherencia
I see in your patch you change from rightclick to click. The reason I had it as right click is that in V3 of the google maps api there is no way to differentiate a single click to a double click, so when a user zooms in using double click, 2 single clicks as detected, which triggers the georeference method, and after a few zoom clicks, gmaps blocks the calls for the "offending" IP because of excessive georeferencing requests. I think we could use a delay to detect whether there were 1 or 2 clicks, but until then, right click seems better.

Well, I am sorry, I add that line to the patch by mistake. It is something out of this issue, we should create another one, because in the current help message it does not mention to press the right button.

The patch I attached lets geofield use both the widget and the formatter.

See this issue for the right click thing #1158738: 'Set location' button in GMaps-widget is duplicated on ajax_submit

Ok, so 1 single storing module and plenty of widget modules.
I haven't tried geofield, would it be possible to have it so that the external library is optional, and widgets that require it are not available if not installed?

@jm.fedrico - "would it be possible to have it so that the external library is optional, and widgets that require it are not available if not installed".

Sadly no, the external library (geoPHP) required for geofield forms an integral part of the system and it's not really possible to offer a subset of functionality that's not dependent on geoPHP.

sub

sub

sub

Marking as needs works since module has changes lately.

I'm a bit late for the party :þ

I need a map input widget to draw lines and polygons. I have something custom-made by someone else based on gmaps that works pretty well, there is a start of a widget input on the geofield side #1273802: Geofield/Openlayers widget refactor and now I just found this issue. I'm not even talking about the doomed openlayers widget currently used in geofield.

From what I understand a new module separated from the two which provide only the javascript to display a map and draw on it, with maybe a couple of php function/hooks for other module to configure what is possible to draw and where to send the data from JS so that whoever is in charge stores it however it want.

So i'd like to know after 5 months what's the status ? I'd be happy to port/help/describe whatever is needed to make it happen but i'll need to know what the module owners would like to do.

I agree with the idea of making this into a widget that can be used on geofield. The geofield/geocoder/addressfield combination is emerging as the best combination to use any place you want to work with geo data. The only thing that combination is missing at this time is this widget and a proximity search solution.

In earlier versions we have ended up with megolithic modules that try to do everything, like location, and you end up with tons of code that you don't need and don't use. It seems inconvenient to install multiple modules to get the bits of functionality you want but it is much more efficient that way, and each module maintainer can focus on perfecting that part of the puzzle.

I would be highly in favor of making sure this widget will work with both geofield and addressfield and let them handle storage.

And I think #22 is off-topic. That should be a totally new issue. This issue is about changing the storage back-end for this widget to use geofield and/or addressfield.

The patch listed in #12 does not appear to be relevant anymore, but I could be wrong. Has anyone had an opportunity pushing this to 7.x-1.0-beta2?

Also germain to this discussion: There is also an open issue on the postGIS module page to merge with geofield: #1436752: Implement new Geofield pluggable backend

Supporting #23. Synergy between geofield/geocoder/addressfield PLUS Commerce PLUS Openlayers PLUS Views will be a winning combination for Drupal.

Surely the greatest strength of Drupal, besides the fantastic community, is the interoperability of modules.

These amazingly talented and hard working module developers blow my mind again and again.

Hello guys!

I hadn't given much love to this module lately, but I'm back!

I'm with all of you in:

• 1 module that does it all is a NO-NO
• Integrating the mentioned modules (views, geocoder, addrefield, etc etc) would be such an awesome combination!

There is only one thing that I've mentioned before: we must be able to provide a download and enable solution. Forcing users to rely on external libraries or too many modules shouldn't be absolutely necessary.

Imagine a site needs a really simple map solution, and we integrate all those modules to work nicely. So a user would have to:

• Install addressfield for capturing the address
• Install geofield to store the location
• Install geophp because it is required by Geofield
• Install geolocation because it has the widget it needs

That is an overkill, I believe we should be able to come up with a solution that

• If they are all installed, then you have the perfect kit
• If not, there must be a simple one module (2 max) solution for a simple need.

I guess we have 2 use cases:

• Showing locations in a map (e.g. simple store location).
• Awesome proximity search (e.g. automatically select the closest warehouse that should dispatch an item for an online store).

And yes, it sounds like I'm making a big deal out of a small thing, but I do believe we shouldn't sacrifice simplicity. We should be able to provide a simple yet scalable solution.

Comments are welcome.

@ jm.federico,

Thanks for your thoughts. I want to spend some more time addressing your comment in a more complete way later, but just a quick note for now: Users no longer have to manually download the geoPHP library, as it's now bundled in the geophp module (http://drupal.org/project/geophp). Geofield, geocoder, views_geojson are all moving to be dependent on this new module. We couldn't do this before because of licensing issues, but those licensing issues are now resolved so we can. :-)

If I were little younger and more of a smart-arse, I'd suggest that simple solutions are better suited to Wordpress or, ugh, Joomla. :D

There possibly is a place for less complex solution, but the respective modules need to be clear about the nature of their respective niches and make that explicit to the users. IMHO a key issue is to avoid creating confusion and unnecessary complexity.

@jm.federico
First of all, big thanks for all your work on this module. I completely agree with your thoughts. Geolocation Field should be a simple solution. I also agree with your 2 use cases (Simple Maps + Awesome Proximity Search).

The problem and the reason for all these different approaches and modules is the complexity of the topic (geo) itself. There are points, areas, polygones, routes, lines, circles, adresses, etc. all with meta information that should be stored along with the geospatial data. Its very hard to design a tool that covers all needs.

The niche IMO for Geolocation Field is a simple solution for "points"
- storage > lat,lng
- display > map
- find > proximity search

Beyond that I agree with smilne23. The power of Drupal is the LEGO-like endless possibility of combining different modules. I like the idea of possible integration with the modules mentioned by phayes, e.g. geoPHP could calculate the area/polygone/bounding-box of points returned by a view of nodes, ...

I think what the geo-community in Drupal is really missing is a kick-ass mapping install profile that brings all these different modules together and already has theme plugged together in a useful fashion. Not only would it be a launching point for building a website with maps, but also provide lots of examples for site-builders to learn about how to do mapping in drupal.

I would love to see these modules working together.

In response to the "simplicity" question, I think there's a trend in Drupal right now to imagine an amateur site builder as the target end user, and plan development and ux around them. But like derjochenmeyer says in #31, geo is a complex issue that requires some skills to utilize and a lot of moving parts. If your task is setting up a store finder, adding four modules and enabling them is going to be the easiest part of the job. Instead of looking for ways to make the install process easier, let's look at making the "create these 10 slightly different functionalities for the end user/visitor out of these four lego bricks" part easier.

I'm glad this issue is getting some love, and can't wait to review and test some patches.

sub

@cluther: what's the part you don't understand in the "follow" button on the top right of the issue?

@Pol - Thank you for kindly pointing out Drupal.org's new FOLLOW feature. I guess that I've not simply 'subscribed' to an issue since October 2011 (when this feature was implemented) and since my comment was at the end of a longish thread the FOLLOW button was no longer visible. Now that I am aware of the FOLLOW feature I will use it in the future, and I greatly apologize for any pain or offense that my utter ignorance of the FOLLOW feature has caused you.

No hard feelings dude, thanks !

-- EDIT: Irrelevant opinion ---

FYI @phayes : http://drupal.org/project/locationmap < feature that demonstrates all of this using geofield, geophp, openlayers, geocoder, views

I am also going to release a features module that uses bean and leaflet to create a simple geocoded map block type.

I really like the idea of using:

• addressfield for capturing the address
• geofield to store the location
• geolocation because it has the input widget

I believe having small focused modules(the unix way) that work together is more important than simplicity for new users. Those modules will be easier to maintain and document. A little documentation could go a long way with helping new users get set up.

Plus now we have drush make to download all these modules and libraries together easily.

So, what should happen next?

I already use the above modules you mentioned, except I use http://drupal.org/project/geocoder as it provides a 'geocode from another field' widget for geofield. It's really convenient. It automatically hides the geofield from the node/edit form and allows you to select from 4 different geocoding services, and allows you to select a field to geocode from - whether an addressfield or, if you want, a text field. You guys should do something similar!

Well, I'm back on geo modules since #12 - June 19, 2011 ;).

I see there is no clear direction on what to do about this issue. I agree there are too many modules, but that doesn't need to be a bad thing now that Drush and distributions have grown as they have in the last year.

I need this integration for the project I'm working on so I have to work on this again. The idea I have in mind is to separate the widget part of this module into a sandbox module and whatever direction we take do it in the future.

• Input widgets: the new module
• Storage: geofield, geolocation_field, addressfield...
• Display: OpenLayers, Leaflet...
• Views integration: Views GeoJSON...

I would advise storage in the form of addressfield, if that is the primary input, and then you can geocode to geofield (using geocoder), display with leaflet and views, no problem. I do this every day!

Here is the patch that makes this work again.

Now with the formatter working.

Now without the geolocation dependency, sorry for the noise.

Hi jherencia, removing the dependency makes sense if you want to use the Google Maps widget without Geolocation field. But since its in this package, removing the dependency makes no sense for all the users who want to usw Geolocation field WITHOUT Geofield.

How can we come around this?

Please describe in short what your patch does. And someone else => please test the patch :-)

I'löl be happy to include it in the dev version after we get some feedback here.

@derjochenmeyer

Maybe the way to go is to separate this into different and standalone module. I did this because I don't want geolocation module installed but I had to enable it to use the submodule. I think the ones who maintain the module should do this because there are other modules which store geolocations which could use this widget.

About my patch:

The main differences between Geolocation and Geofield is that they use different keys to store the Longitude. So what my patch does is use the correct key depending on the field type.
As you can see I do this in a validation function so the form names do not change in order to prevent possible JS references stop working.

Ok, I've splitted the work here into three different issues to focus in this one in the widget part.

• #1129512: Make Google maps geolocation widget compatible with Geofield
• #1764130: Remove Geolocation dependency from Google Maps geolocation module or move it to its own module
• #1764138: Make Google maps geolocation formatter compatible with Geofield

So this patch just makes Google maps geolocation widget compatible with Geofield.

Does it make sense to start an issue in the Geofield queue? Since these patches focus on Geofield maybe we could get some feedback by inviting people to test these patches here?

Done: #1765044: Help needed to review Geolocation field issues that adds compability with Geofield

First of all thanks for the patch and for testing it. Some annotations...

Why did you introduce an aditional validation function? This could be added to geolocation_googlemaps_field_widget_validate(). And we need some code comments please :-)

+function geolocation_googlemaps_field_widget_set_value($element, &$form_state, $form) {
+  $values = &drupal_array_get_nested_value($form_state['values'], $element['#parents']);
+  if ($values['field_type'] == 'geofield') {
+    $values['lon'] = $values['lng'];
+    $values = geofield_compute_values($values);
+  }
+}
+

And don't like this part too much:

-  $lat_value = isset($items[$delta]['lat']) ? $items[$delta]['lat'] : NULL;
-  $lng_value = isset($items[$delta]['lng']) ? $items[$delta]['lng'] : NULL;
+  $lat_key = 'lat';
+  $lng_key = ($field['type'] == 'geofield') ? 'lon' : 'lng';
+
+  $lat_value = isset($items[$delta][$lat_key]) ? $items[$delta][$lat_key] : NULL;
+  $lng_value = isset($items[$delta][$lng_key]) ? $items[$delta][$lng_key] : NULL;

I find a simple if/else statement is more intuitive to read/review.

$lat_value = isset($items[$delta]['lat']) ? $items[$delta]['lat'] : NULL;
// To make this widget compatible with geofiled we need to rename the keys for
// longitude. Geofield uses "lon" while Geolocation Field uses "lng".
if ($field['type'] == 'geofield') {
  $lng_value = isset($items[$delta]['lon']) ? $items[$delta]['lon'] : NULL;
} else {
  $lng_value = isset($items[$delta]['lng']) ? $items[$delta]['lng'] : NULL;
}

I use another validate function because I like to separate behaviours into their own functions, instead of developing a functions which does two different things. (http://london2011.drupal.org/conference/sessions/code-stinks)

About the lng/lat keys, you are right, let me work on this.

Very good link, thanks :) separate functions for separate behaviours make a lot of sense.

Commited. Thanks!
Sorry, tried to use git am but i messed it up. The code is clean, the commits are not :)

Great! Thank you.

@jherencia: But it seems the git am kind of worked.

Yes, it did. The reason it seemed to failed was that I didn't pull my local repository with the latest changes, sorry and thank you anyway.

Could anyone test the formatter?

i didn't see a google map formatter for geofield

@euroba

Here is the patch that adds compability to Geofield :) : #1764138: Make Google maps geolocation formatter compatible with Geofield

Was the patch committed? Geofield integration doesn't seem to work. Using Geofield 7.x-1.1 and Geolocation 7.x-1.x-dev. It would be great to have it as both modules are really great.

@endrus

Yes, it is, but it is not in the current stable version 1.1, it's in the dev version:

http://drupalcode.org/project/geolocation.git/commit/161a24d598037ce2197...

Was the patch committed to the current stable version 7.x-1.4

Getting some error message:
Notice: Undefined index: wkt in geofield_compute_values() (line 191 of /var/www/html/drupal/sites/all/modules/geofield/geofield.module).

when widget type set to google map in geofield

Yes it's in Geolocation Field 7.x-1.4

Which version of Geofield are you using? 7.x-1.2?
http://drupalcode.org/project/geofield.git/blob/refs/heads/7.x-1.x:/geof...

I didn't write the patch and committed it following the reviews, but it seems the patch only works with $master_column == 'latlon' only with $master_column == 'wkt'