Boris suggested I cross-post this here (originally posted http://drupal.org/node/69957)
We are building out functionality to allow multiple locations associated with a content node. The idea is to make location nodes, changing nothing to the location module, but making a new module which will facilitate in the creation of and association between location nodes to their content nodes.
We plan to allow node publishers to create and relate location nodes during the node creation process, via the location drop down on the node form. The mockups depict a gmap will make it possible to select a location when multiple locations are found based on the user's initial query. The query is done in one single text field to make things simpler. Based on the results of the address query, the latitude and longitude boxes are populated if there is an exact match (using the geocoder API from google) or when a user clicks on a marker from the gmap when there are multiple results.
The user can then click to add the location, then query again, and add as many locations as needed. If a user wants to delete a location, they can do so, then add another location, etc., all without reloading the page.
Overall, when you are creating a content node, like a blog post, and you create related location nodes on the fly, the actual location nodes will not be created until the blog post is saved. This will prevent creating location nodes which may never have a related content node.
Settings
The site admin will be able to assign a cck node type to be the designated node for location nodes, or use a basic node type made available by this module.
There will be settings to turn off the inline location node adding at admin/settings/content-types/node-type-x
There will also be user access which determines who can use the inline location node adding.
Other
The first location added to a node will be what is used in the RSS feed.
What do people think of this plan? Any additional ideas, thoughts?
References
http://drupal.org/node/41088
http://drupal.org/node/18917
http://drupal.org/node/59683
Comments
Groking...
Let me see if I understand this:
This sounds exactly like what I propose for taxonomy2:
http://groups.drupal.org/node/246#comment-1625
I would implement your idea (which I think is good) in the same way I suggest implementing taxonomy2. The module imports a CCK type (i.e. "location"). Via the CCK -> nodeapi bridge (doesn't exist yet!) a "location" field is added to every other node type. This field is a multi-option form field, like the one for freetagging. Instead of popping up a list of possible words, instead a map is populated with markers.
Another nice thing to add would be a widget for the node reference field that presented a map to the user and allowed the user to select a node from the map.
If this sounds like a good implementation to you, I would suggest that you start looking at how to make the CCK -> nodeapi/form_alter bridge. I'm working on the import/export/save functions right now.
-M
Hi Mark, I read your thread
Hi Mark,
I read your thread over there about taxonomy vocabs becoming content types, w/ terms as nodes, and then the idea of using category module to perhaps hold relational information. It sounds like people are getting fired up about Jaza's category module, and that there's some potential w/ using CCK and the node system.
I am stuck whether location nodes should be able to be used for more than one node, which would be #3a of what you've listed above - "Locations can be selected from the existing location list"
What happens if you need to change a location node, and make it not Washington, DC, but the Peruvian Embassy, Washington, DC? Do you make a new location node, or do you modify an existing location node? What needs to be clear to users/admins is if they modify a location, it may be used/related/tied to more than other content node, and this needs to be clear. Then, the user can decide whether to make a new location node, or change an existing location node's coordinates.
I also had the thought of letting a content node inherit locations from another content node. Take this example - say you have a site w/ Ikea retail stores, then you have 50 US states. Say each state is a cck node. Then, each ikea store is a cck node. Say you have California and there are 10 ikea stores in California. You should be able to let California node inherit the locations of the 10 ikea store nodes which are in California. Inherited locations by association. Then, say one Ikea store is disassembled in a day and reassembled two counties over (a little Ikea humor) - you never have to go edit the California node to adjust its inherited locations, you just edit the location node tied to the Ikea store node.
As you can see, the functionality here is all more about relationships than it is mapping/geocoding. The ability to create nodes on the fly and define relationships is maybe something that can be reused like you are saying w/ the cck bridge.
Ian
Use case
Thanks for taking a look. Everything is still sorting out with Category/Taxonomy/Taxonomy2. A large part is that we don't have the maturity of code we need in CCK yet to try other options. But we're working on it...
Let me deal with one statement you made:
I think it depends if a location is "Washington, DC" or if it is "My Embassy". If locations are just lat/long coordinates, those should always be static. The 35th parallel doesn't become the 49th parallel by sheer strength of will!
However, if locations are aliases to something else, then changing their geo spatial positioning makes a lot of sense. If I pick up my embassy and move it to Maryland, changing the "My Embassy" location would transparently update all the data that relies on the location of my soveriegn nation's soil in America.
I don't know that this answers a question or just defines the problem again....
On a more helpful note, perhaps you should look into the prepopulate and clone modules to see if they can help you clone locations when appropriate and edit locations when appropriate.
-M
integration with gmap
Have you looked at using gmap to do the map drawing etc.? I am in the process of integrating it with mapthing - which already provides an interactive AJAX based map editing mode. It seems at first glance that a lot of the functionality you are looking for is already coded.
Hi Dan, Yes, we are seeing
Hi Dan,
Yes, we are seeing that most of the mapping functionality already exists, in various areas. What we're seeing is what needs to be done is the relationship module, and node creation/relationship defining on the fly, via ajax or form methods. We don't really want to make a relationship module that will just handle this custom job, but I'm not sure of the extent a generalized relationship module will be any help. It's almost like the idea of making more things nodes makes handling relationships that much easier. I need to think about this more and catch up more on the category module ideas that Mark links to in regards to taxonomy2.
Ian
Yup this is more about relationships
Agreed - my thoughts exactly. Why don't you cross-post in Relationships? There are 4 relationship approaches from my understanding. We've had similar discussions vis-a-vis events - I'm not sure how ready "relationships" will be for this.
this sounds great
i love the direction this is going in. i agree w/ drob -- there are a ton of parallels to how event handling (e.g. signup, RSVP, etc) should work. a few quick comments:
we shouldn't decide ahead of time the mapping between nodes and locations, nor mandate what it means to edit an existing location. that should be up to the user/site admin. there are obvious use cases for every possible combination, and any hard-coded decisions we make will be wrong for someone. for example, on my band's website, we use a similar system (events are nodes, locations are nodes, each event has a link to a location node). most of the time, a new event will just point to one of the existing locations where we hold regular events. so, you definitely shouldn't prohibit a given location being associated with many nodes. however, in the some cases, a location is rather vague (e.g. "Oakland, CA") if that's all the detail we have at the time -- once a location has been nailed down, we'd probably just want to make a new, more specific location, and change the event to point to the new one, so we'd have (at least) 2 location nodes that both have "Oakland, CA" as the city/state, but one might have a more detailed address in it...
a CCK "relationship" field widget would be fantastic. that's really what this boils down to. ideally, there'd be some flexibility about what data from the child node was displayed along with with the relationship field link itself. there might be implications for views here (though i've never played with views, yet).
dynamically adding new locations on the fly would be slick, but i'm curious how y'all envision the UI looking so it doesn't get hopelessly complicated/confusing. :)
thanks for working on this! i eagerly look forward to the results. once i'm back from vacation (mid july) i might even be able to help work on code. i'll certainly be an enthusiastic alpha/beta tester. :)
just cross posted to relationships group
since this (like so many other bright ideas for the future of drupal) boils down to node relationships, i'm cross posting this into the relationships group...