Interactive geocoding widget

I think Conditional Fields may be a dirty but working solution.

Geofield has the same request: http://drupal.org/node/1308510

@thlor: are you using conditional fields to expose the geofield map input and disable the geocoding?

@hnln: This is an interesting suggestion/request. Geofield stores the WKT/LATLON and openlayers is the input widget you seek. I've often run into the same issue and would like this functionality myself.

As the inheritor of this module I am interested to know if a "refine geolocation option" might be valuable to reexpose the geofield imput map if we already have a location stored or something similar. Thoughts?

@bago: thx for feedback

Ok then. Lets say we go ajax route. We currenlty geocode from pictures, files with gpx info, address_fields and regular text fields. Ar eyou proposing that we only perform the ajax look up on lose focus of the textfeilds and address fields? Ping the geocoder service on the lose focus event of each text area?

What happens if you adjust the point on the map further by hand and then update your address field (be it body, addressfield, or other) after that? Does it revert tyour map point or keep your manual adjustment.

I'm not a fan of the ajax approach as geocoding should happen in hook_field_attach_presave as otherwise you don't get any geocoding when you programatically save, batch save (vbo) or import content with addresses (and those are quite common to import :-), see also http://drupal.org/node/1297654 and http://drupal.org/node/1417078.

I'm also not a big fan of the location approach, it cluttered the form too much (address fields, map, some explanations a checkbox to delete location that confused people, ...).

'Refine geolocation' sounds good to me :-) Maybe a checkbox as mentioned in the geofield issue and if checked the form will display again on submit but this time it will also show the map widget. We should make sure then that the automatical geocding doesn't happen when map widget is used and a way to remove it as well.

Ya, we had this setup on a d6 client site and the real advantage for users was when they were able to see immediate results, ie ajax. The user needs to see the map locate based upon text field address input and vice a versa immediately, otherwise this is not a useful feature. This is the same reason autocomplete is so handy. Like bago alludes to, this is about reducing user error.

I agree: use ajax but keep vbo/import/presave.

These should be two different widgets: first-widget should be as-in, the second-widget can be ajax.

The first step is to do this: #1462364: Provide AJAX service

Now that we have our AJAX service we can proceed.

Long-term we need to wait until this issue is resolved in geofield: #1273802: Geofield/Openlayers widget refactor as we would want to base any really good, general purpose interactive widget on geofield's new openlayers map widget.

However, short-term I would be willing to accept a patch that does google maps to get SOMETHING in place. This should go in a new sub-module. (Called geocoder_interactive ??)

@phayes #14, what about using leaflet? project/leaflet

Leaflet would also be great. It looks like they have a feature-request out for a widget: #1284932: Leaflet field input widget . Once they build a widget perhaps we can riff off it for our geocoder powered version.

K, I'll see if I can get some to help jump start on the widget.

In general idea - geocoding + manual adjustment in one form - is good, because it would potentially allow feeding changes back to geocoding providers.

I think editing address would do re-geocode, since address can be changed significantly, some smart proximity check could be made to determine severity of address change or default behavior would be set by field settings.

i tried using conditional fields but didn't get it to work. How would you do this? i made a 'geolocated' field and tried to update the location field when this was filled, but wasn't able to fill it with the value of the dependee.

I hadn't found this issue before I implemented a workaround in #1585804: Optionally support direct digitizing of locations, using hook_field_widget_properties_ENTITY_TYPE_alter() to dynamically switch the widget through an AJAX call. Possibly that approach could be generalized, but there would be a number of issues. E.g., getting the settings required for the different widgets would be difficult.

The workaround in #1585804: Optionally support direct digitizing of locations works but has a lot of moving parts.

To reduce the complexity I sketched in a possible approach in #1627940: Add optional geocoding to map input widget.

My thinking is:

• If we're combining a map digitizing widget with a geocoding one, the map is primary. A particular location may be geocoded, but if it's been manually edited the manual edit is what we want to keep. In future edits, we won't want to programmatically repeat geocoding, because doing so would discard manual changes. In short, the geocoding is an optional step prior to manual digitizing. Therefore, geocoding functionality makes most sense as an optional enhancement to a map-based widget.
• The data processing in geocoder involves a complex interplay of widget settings and field processing to e.g. selectively concatenate fields prior to geocoding. Rather than reproduce this logic on the client side, it would be preferable to reuse the existing server side handling. So rather than writing a new openlayers behaviour, we should look to AJAX form submission with selective element replacement.

Not sure how sound either of these points are. Happy for comments and review.

Also posted two related issues:

• #1627906: Enable other modules to use geocoding field processing
• #1627908: Use #states for dependent form element visibility handling

1. Related issue, probably this issue would be dependent on this as well: #1461164: Reverse-Geocode support
Adjusting the marker manually on a map would require reverse geocoding, since the mapping service needs to provide an address based on lat long..

2. Sometimes, an ambiguous address field input may yield multiple results on the map. A "Did You Mean" feature would be great as well, for example:
http://econym.org.uk/gmap/didyoumean.htm

We will be tackling this issue in geofield here: #1627940: Add optional geocoding to map input widget, not in geocoder module. All comments etc should go there. I will keep this issue open as a pointer

This is now fixed. See geofield module.