[master]Allow selection of previously defined locations

Yeah. With location3, it's now actually possible to associate the same location with multiple nodes, but we need to come up with a UI for doing this somehow.

Mockups and ideas appreciated.

wow... we were just banging our heads against this very same (geolocated) brick wall today because of an issue we're having where freshly-localized nodes "steal" and refuse to share locations from the original node... this is very nice news!

subscribing, and if any help is needed with mockups, I'd like to contribute - I'll start thinking, but if you have specific things you need, please get in touch.

Hi mgenovese. Yes, i think it's configurable as you describe, but the only thing that strikes me reading your implementation is that the Location module already stores individual locations as records in a separate db table, so you don't (I think) need to define content type A that holds a location and content type B that can reference those locations.

Perhaps the settings for requiring/allowing/disallowing "location names" could be moved from the "locative information" settings under /admin/content/types/xyz to the admin settings for the Location module itself, especially since all locations go into one table in the same format. In this way, even a "user", a "page" and a "story" could share a location without setting up extra content types.

At the moment I can envisage the "select an existing location" option in a content entry form working in one of three ways, two of which are already used and familiar in drupal:

1) as an autocomplete element - you start typing the location name and it looks up possible names in the db - this is like freetagging in the taxonomy module, but it requires you to know the name given to the location.

2) as a drop down of all location names (like the image attach module) - but the drop down list could quickly get too long to be useful

3) using a gmap - perhaps with a "show existing locations" button - this could be an option on the same input element as for a new location using location/gmap: you opt to see the existing locations as markers on the Data Entry gmap; if you click on one of the existing markers, up pops an info window containing a link or a button to "use this location" (and the standard [X] close window control). If you don't select an existing location, but click on virgin territory, you create a new location in the usual way for location/gmap.

The third option seems like the nicest to me, but means you have to use gmap as well, then that you have to navigate/zoom the gmap to find your location, which might slow you down. There again, it should avoid any errors or the frustration of not remembering the name you or someone else gave to a location before.

Does that make any sense?

An autocomplete box makes more sense really, I think it's unlikely anyone who is bothering to use the Location module has just one or two locations that a drop down box would be suitable for. Then if the GMap module is installed it would be nice to have the option to replace that interface with a map if required. But a map takes up a lot of room on a form and is probably slower to use if you know what your location is called.

I'm setting up a website for a university Geography department, and they have a project node type that has locative information. So all research projects have one or more locations, but some projects are in the same area, i.e. a continuation of a previous project. It would be nice if they could just type in the location name as they previously defined and have auto lookup. Even better would be to have autolookup on name AND lat long ;) I guess that might be asking too much though.

true, the autocomplete would be the most space- and speed-efficient way of filtering pre-inserted locations, but (as i half-said in my long-ish comment), it does require that you remember what you name you gave to a location, or know what name your co-authors (in your case, perhaps on another geography dept project, perhaps from a different year group; in our case, from another country, maybe in another language, and probably not connected to you at all) gave to it. In my experience (of myself and my appalling memory), users' memory isn't that good, nor are their language skills or their ability to second-guess other users.

Perhaps the answer is that when defining the settings for the re-use of locations in the module, you should be able to pick which way you want existing locations presented from all three suggested based on your user group and site scope?

A FOURTH way, just to complicate things, would be to do a kind of "hierarchical select" drill-down from most generic to most detailed info... pick the country, then the list of existing cities appears, pick the city then the list of existing street addresses / location names appears... like a guided "autocomplete" that stops you making macro-errors, like, for (a rubbish) example, assigning a "Harlem" (NYC, USA) location to a "Haarlem" (NH, NL) one because you don't remember the slight spelling difference. This might be faster and smaller than a gmap input, but less error prone.

Am I worrying too much?

That doesn't help if your location is a lat long coord in the middle of nowhere though.

True. Then in your case with expert users and that sort of location I guess an autocomplete location name field corresponding to a lat/long coord in the middle of a field probably would be the best and simplest option. In ours it almost certainly wouldn't, because we're doing a website in three languages so even the most straightforward location names vary too much between languages for them to be guessable or spottable in an autocomplete.

So perhaps in an ideal world the module could have a settings option to choose the best selection method from autocomplete, drop-down, drill-down or gmap?

I have no idea if this is feasible :)

Did this end up going anywhere? It doesn't seem like the feature is visible yet in Location3. It would be a very useful feature for many projects; the current one I'm working on involves a calendar of events, where each event has a location. Most of these events happen in the same dozen or so locations, so retyping addresses is pretty cumbersome.

How difficult would it be to draw out a list of current locations and put it in a drop down or autofill box? If the API is straightforward enough, I might be willing to look into it.

I would really like something like this. I'm also working on a website with events and locations. I want to be able to choose a predefined or earlier used location for each event. Currently we use a custom node type with location info, and use nodereference to connect them to an activity. That way we can show gmaps populated with events by using relationships in views. Hell of a job and a messed up workflow.

looks like there was some good thinking about this feature! I'm tagging with cool idea, auto-complete and also master issue.

marked #391048: Reusable locations? as a duplicate. (check out the code there for ideas!)

marked #398714: Library of Locations as a duplicate of this issue

Any follow up on this? I'm trying to find this functionality as well.

I'm too feeling that location reuse should be addressed.

I did several mockups and would like to hear comments before i dive into code.

(Shots were made in Google Chrome for Windows, Drupal is skinned with Pixture Reloaded theme.)

First, existing form for CCK Location field (like it is at present) with Name, Street and City parts configured.

Than goes an imaginary form with location reuse capability.

Now, to get a better understanding of the problem i did a usage scenario:

• User is creating new item with a CCK Location field, trying to search for existing location with autocomplete widget.
• As it happens, location doesn't yet exist, so user is forced to enter a new one.
• User adds a necessary fields and posts the form afterwards.
• User is visiting saved node form. It's possible to edit fields.
• After reusing the location for another node, user is unable to edit it's fields from within the latter node.

That's all for now. Needless to say, that with enough JS trickery this form can be turned much more exciting: one thing comes to mind is to put location fields into lightbox or dropdown.

UPDATE: I've managed to build a working solution for location reuse, dropped sources to Google Code temporarily. Any brave soul wants to try? I'll come with a more description shortly.

Would love to get this working.
However when I try and enter and save a new location using your widget I am getting the following error.

# user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '*) AS weight FROM node n INNER JOIN location_instance i ON CAST(SUBSTRIN' at line 3 query: SELECT l.lid, l.name, l.street, l.city, COUNT(n.*) AS weight FROM node n INNER JOIN location_instance i ON CAST(SUBSTRING(i.genid FROM 29) AS INTEGER) = n.nid INNER JOIN location l ON l.lid = i.lid WHERE n.type = 'event' AND n.uid = 1 AND i.genid LIKE 'cck:field_existing_location:%' AND LOWER(l.name) LIKE 't%' GROUP BY l.lid, l.name, l.street, l.city ORDER BY name, weight DESC in /home/xxxxx/public_html/xxxxx/sites/all/modules/location_cck_widgets/location_cck_widgets.sources.inc on line 76.

Running the latest mysql and php.
And the latest Drupal.

I want to share some thoughts on location reuse:

My experience developing custom location reuse widget shows that the whole idea of it may well end up re-implementing every bit of functionality already available for nodes. Just think of it: after enabling user to select an existing location, the next thing that springs to mind is to implement some sort of role-based access to locations. Needless to say, You'll also need to have a location editing capabilities (at first, I looked at editview.module and even went that far to patch it to support locations), import/export, versioning, theming, and so on -- literary, every behaviour of the node should be reimplemented for locations anew.

The obvious alternative to this boring and unnecessary work has been already discussed somewhere here, on drupal.org: create a dedicated content type to hold a single location. This way, the whole problem will turn into referencing nodes, which by itself is a solved problem in Drupal.

subscribe

marked http://drupal.org/node/1049754 as duplicate

wonder if anyone did anything for this so far

Is this still a hot item for people? I think I have something that would work as an add-on module for the 7-3.2 branch.

It's a simpler scenario than the one above. It doesn't request the user to look for an existing location or enter a new one. It's an autofill based on the Location Name. The user can use the returned values exactly as is or the user can override with some new values. Upon submission the entries are checked against existing locations for exact and almost exact matches. If an existing location is found, the location ID is assigned to the newly entered location so that when it's evaluated by the location module, it's evaluated as an edit to an existing location, which increases the chances you'll get to reuse a location.

I'm still testing and will be going live with my mod soon. If it's something other people need, I'll put some work into making it releasable.

Closing old D6 issues as D6 is end of life