Allow for locations to be shared (wrap locations in node, use nodereference)

I like the idea - makes a lot of sense to me. I'm also pretty new to this, but I don't think it would be a such a big change. +1, because enabling association with categories opens the possibility of grouping locations by whatever one needs for a particular situation, rather than just standard ways like postcodes, etc.

I don't think you need to do anything at all for this to work. Just create a new content type for your location nodes and location-enable that content type and you now have a location node. Then hook to these nodes however you like. This is marked as HEAD so I assume you're using 5.x.

This sounds like an interesting idea, especially in 5.x where node types are so flexible anyway. Reuse of a location is particularly appealing, as well as all the other great stuff that comes with the node system.

How would you deal with the input of locations on an existing node, or when creating a node that you want to assign a location to?

Not sure whether I understand the event-location relation correctly, but I think Karen's suggestion still would work for you. Create a content type LOCATION and all it holds is the location info and custom fields if you need any.

From your event you have a node-reference field that associates one or more locations with your event - of course you can also associate many events with one location.

What's missing is an easy way to add a new location if there isn't already one and an easy way to display the location in the 'parent' node. The display issue would be solved by any method to display a view within a node, there are lots of possiblities for that -- custom themeing, viewfield, insertview, probably others. To add a new location maybe editview or just a custom link to add a new location.

So it's not quite a completely seamless solution, but could be made into one with a little work if someone wanted to do some testing and either document the steps or maybe write a small module that would add in any missing parts.

Can't help with the coding at the moment - but this is exactly the sort of facility I'm looking for too.

I was thinking of trying to use Autocomplete to lookup a venue by name but then I'm stumped on how you handle not found to allow the creation of a new venue.

I'm changing the title for clarity. This is not about locations, but venues. I think there should be a locations_venue.module or just a plain venue module that relies on locations.

Location also needs re-factoring. It currently is associated with one and only one node. Many nodes may share the same lat/long, let's not duplicate.

I mostly agree w/ comment #8 in that perhaps another module should make use of the location module to set up a node type that records a location (or combination of locations) that is commonly referred to. Location re-use is programmatically more possible now that each location has it's own unique id (the 'lid' column, which also gets loaded in to the locations array). This can come in handy for the situation similar to one you might have on Yahoo! Yellow Pages where you want to search for stuff within a certain radius and have the choice between entering a location or using a drop-down select to choose from an existing location you've already saved.

In anycase, back to situations that might be better w/ copied locations: take for instance a transaction that might take place (whether its ecommerce or something else). If we use the same 'lid' for that location and a user later edits that location from somewhere else, then that location is changed the data that was submitted w/ a location (perhaps it was part of some credit card data or an address to which something was shipped) is changed and the data becomes incorrect. In this kind of case, it'd be better to make the user enter a new location or to *copy* an existing location previously entered by the user.

If someone wants to work on a location_venue module, please feel free to add it to the location/contrib directory. I'll help w/ anything you might need in regard to schema information or whatever. Ideally, we would do this thru CCK where we could somehow set up queries on node_references that refer to nodes w/ locations, but turning location into a CCK field isn't a 1 or 2 week project like location_venue might be.

I'd like to work on a location_venue_events module - something that utilises both location and events modules and a cck venue content type. In its most basic form it would be an easier way to enter data for an event or a venue.

Basically, if I go to the event entry form, I check whether the venue where I want to hold my event already exists in the DB (via node reference field).

If not, I have the option to add the venue, its location and finally the events data (perhaps via multi-page form). By filling out one form, I have added a venue, its location and an event.

Perhaps this already exists? What do people think?

Karen, could you elaborate on the viewfield and insertview suggestions? Are we talking about the same thing?

You shouldn't need to merge in venues AND events. A location_venues module could then be used by any events module. The event nodes would use either a CCK field (something else to think about for location) for the venue, or just use a nodereference, limited to nodes of type venue.

And probably one of the best models for this is Upcoming. I would start by trying to clone the user interface of Upcoming...it's pretty slick.

Do you mean Upcoming.org project SoC as it appears moribund? Which seems a shame as it sounded good too.

Trying to convert my existing site to Drupal, as I've had such success with work related sites, but I don't see a way to link events to venues, and to be able to tag venues... so far thinking of having a venue as a node, linking that to a location, using taxonomy / term to tag the venue node ( ie music, food, garden, non smoking ) and writing something new to link events to venue nodes.

subscribing

Anybody making headway on this. Is there a commitment to making a module to do this or is this a dead issue?

Status would be great.

thanks

I'd like to see this and I'd like to work on it, too, but have a limited amount of time. I'd also like it to work for both Events and with Date and Calendar rather than to limit it to only Events, so I hope it can be designed to be flexible enough to work that way. Here's my idea for doing it:

1) Identify venue content type(s). Having only a single venue content type is limiting and not in the spirit of the way things are headed in 5.x+, so I don't think we want a venue content type to be defined, just a method for identifying which content types are venues. In 4.7 you can create a CCK type for this purpose, in 5.x you can create a custom content type.

2) You can then attach location fields to the venue content type(s). No need for changes there, that already works fine.

3) You need a way to select from the venue content types when you're on an event (or date) node. Here's where I would use Views. Create a view of the venue content types and use that view as the selector. mfredrickson is working on a module to do this which I think is getting close to completion which might be one way to do it or you could use the CCK nodereference module for this purpose, which allows you to define a view to populate the selector.

4) Once you've linked a venue to the event or date node, you need a way to display it. You can do that with another Views view and use viewfield to display the view in the event or date node, or use nodeapi, or maybe our reverse link on the nodereference field (which is not yet committed but has been discussed forever).

5) The last piece of the puzzle is finding a way that when you do searches so that the search brings up not only the venue node itself, but also any linked event and date nodes. That could be done in Views using Location Views, or with some customization of search functions.

So I think all the elements are available, they just need to be pulled together to make it easier to do this.

fwiw,

You covered a lot of ground there that seems a little foreign to me mostly because you are trying to make this reusable on many levels.

what I would like to see however it's implemented is to allow one to do the following when both A) creating a venue node and B) assigning a venue to an event or date:

1) create a state select menu populated with states
2) drill down and select a state on state select menu
3) to ajax populate a city menu
4) which then populates the venue select menu

if you're on the venue create form, then you can add a new venue for that city or update/delete the existing one

if you're on an event or cck content type with a date field, whatever you select as the venue is what gets assigned to the event / cck w/date.

NOT having that drill down feature ON THE LOCATION DATA makes this whole exercise somewhat futile imho. Because the point of it is to REUSE venues and do so easily on a form. The way you organize venues is by location. (e.g. there's a house of blues in new orleans, la, nyc.. so if you don't differentiate by location, you're going to be tripped up by the generic name house of blues).

Also, there are how many thousands of cities in this country? If one has a robust schedule that's nationwide, they want to be able to lookup venues by state and city because they know what their itinerary is. Any other way seems to be a lot of finger fiddling imho.

NOTE: if you're only concern is that you hold events at the same 3 locations every year then all of this is overkill and you probably can use nodereference or just hard code the venue. But my idea is that this would really open drupal up to much bigger things for people with much bigger needs and itineraries.

Which means you're going to need a standard state, city databases to do it the way i want. In reality country, state, city databases would best for those outside of this country or who have global schedules. This would mean adding to and changing the current location module zipcode lat long dbs. Break out the date in separate country, state, city, lat/long dbs all linked via keys to the one higher up on the chain.

Anyway, that's my two cents. And doing it this way means changes across a number of modules : location, events, cck date and possibly venue. which wil require a LOT of coordination.

That's why i wonder if it's not better to somehow create a separate module to do this instead of tryign to coordinate all of teh pieces. I'm not even exactly sure how to go about this but i think defining what you want to do up front is important before you go down this path.

thnaks

Regarding my previous post..

Does anybody know where one can download free and uptodate open source ctry, state/province, city, lat-long dbs????

Because without having access to that makes this whole thing kind of futile as well. I mean who would be willing to compile all of that info and update it regularly for the community. not i. :-)....

If anybody has any links let me know. I'd like to start fiddling around with this and dbs are essential to make it work.

thanks

the general thrust of this issue is fine. however, location_venues.module sounds like a bad idea, IMHO, and not in the spirit of how CCK should be working.

i've been doing all this (in a more clumsy way with flexinode and urls) on my 4.6.x site for my band (http://baterialucha.org) for over a year. the basic notion of 2 node types: "events" and "places", where the places are re-used and each event contains a link to a place is clearly the way to go. i'm just now in the process of converting all of this to 5.x, CCK, nodereference, etc. there are only 2 missing pieces for a *really* slick UI:

1) i've always wanted to include info from the place node when you view an event node. i.e., instead of a link to a place (what i have now), i'd like a little box of all (or just some) of the content of the place node printed. i'm planning to just do this in my theme, but it'd be cool to consider extensions to the nodereference output formatter to allow settings like this directly in the CCK UI. i'll search the CCK issue queue about this and submit a feature request if there's not already one.

2) when adding a new event, it'd be great if there was an option in the drop-down of existing place nodes that said "add a new place". someone in IRC ("lionfish" -- don't know if that's their d.o user, too) was recently working on a nodeadd_widget, and was nearly done.

whether or not your place node is a CCK type with individual location-related fields as true CCK fields (http://drupal.org/node/125266), or whether you just "location-enable" the type with the existing location.module is pretty irrelevent to this plan. however, i see nothing in this where a location_venues.module would help, and it'd just be a throw-back to the inflexible module-defined-node-types that CCK is moving us away from.

-derek

@dww, I think you're saying the same thing I am, that most of this can be done with existing tools and there is no need for a new 'venue' node type. I see the purpose of a venue module not to create a node type but to simplify the process of creating venues by pulling the pieces together and adding in a couple features like the ones you mention. Some of the proposed improvements to nodereference to expose other info about the linked nodes will help a lot here.

@newdru, I do see your point about a need for ways to do lookups of the venue nodes by location, but one way we can get to that is by improving the Location search and/or Views integration with the Location module. Location Views has a rough proximity search feature that needs more work, but I haven't had time to work on it. Also, I disagree with the idea of building in huge location databases, I'd rather see us improve the integration with existing location web services to add geocode and other location info to our venues.

Regarding #21...

1) I think you took what i said in a different direction..

When i talked about the state, city, venue LOOKUP I was talking about ON THE EVENT CREATION **FORM** (not in a table or list DISPLAY of an event schedule - which i'm sure can be accomplished as you say with a views or location search).

I'm approaching this more from the perspective of someone who HAS TO **ENTER** THE EVENTS not someone who looks at what is entered post-facto. The pain in the arse part is FILLING IN the schedule (creating the event nodes) imho.

If you have to enter in 1000 events 1 at a time and lots of them reuse venues, if i've got 2000 venues to choose from in the country, i don't want to have to ever (and shouldn't ever need to) retype that data. that's bad db design (forget which normal form), wastes typing, is prone to errors etc.

I also want to be able to select the venue easily out of the 2000 that exist.

Lets say we're going to Okalhoma but i don't remember the name of the venue but i remember the city it's in. If i can pull up state, then city to populate a third select with venues in oklahoma, i'm going to recognize it when i see the name. But if i had a single list of 2000 venues, how am i going to recall that out of the list. There's no context.

I personally don't care how this is achieved - separate module or existing cck fields w node reference etc. As long as the function to REUSE and RESELECT existing venue/locations EASILY ON THE **FORM** exists is what is key for me. So if someone can tell me that the functionality i'm talking about is availble with existing cck/location etc, i'm game.

If it's not and can't be worked in, i think it's shortsighted planning.

I personally think that before you build anything, you need to figure out HOW IT WILL BE USED. And most of my concerns are around the event form inputter's experience. And when i say that, i mean entering lots of events NOT just entering 20 events a year. I guess i wonder if others are thinking in those lines or just limiting themselves to the experience of the mom and pop small business or smaller non-profit, etc.

We need to put ourselves in the shoes of both extremes imho. If drupal's not ready for that yet, that's cool. But putting it out there at least gives us the opportunity to do it if we can. :-)

2) You mentioned "proposed improvements to nodereference to expose other info" in the post. I think this is probably the heart of making this work. Could you say more about the "improvements", how they will help solve the current problem and an ETA for implemenation (roughly)?

2) Regarding your wanting to use "existing location web services" versus local dbs.

Again, i don't care how what i mention above is achieved. As long as it is achieved. But could you point me to an existing "location web service" that will allow me to pull the ctry, state, city info i want so i can create the targeted select boxes i want on a drupal form for my venue?

I could be mistaken but even the current location module requires a local db which has hard-coded geo lat/long info in them. Without that db to hook into, you can't use an existing location web service because you need the lat long to do the lookup. Now what about if I don't live in the USA? the location module only provides db's for USA and i think a subset of canada and germany. So that module is already limited in your eyes as well because as you state because it relies on a local db.

And for what i'm doing right now i'm not even concerned with lat/long mapping (although that's the next inevitable use). I state that just as a reminder that you don't forget about other uses of location data (like state, city, etc) at the expense of focusing on the currently more popular 'geo' targeting/mapping stuff.

IN SUM: if we use existing location module, i'd like:

a) to see it pull in ctry, state, city from either an existing db or web service and then use that info to populate forms in real time (ajax required) using targeted/chained selects AT LOCATION CREATION TIME.

b) when location is nodeapi'd to an exsiting content type like event, i want form alter to provide the same targeted ctry, state, city ajax selects (except this time only from current location nodes that exist in the local db) as described above AT EVENT CREATION TIME.

Actually, i just realized that may be the better way to go then using node reference!

c) On that same event creation form, i want a tab or link to 'create new location' if it does NOT already exist. This entire methodology enforces you to use pre existing locations which makes sense to me.

although above my head at this moment, it would be ideal to make this a popup with ajax so that the original form does not have to lose context or be retyped in.

fwiw, my approach looks like it will rely heavily on ajax. i'm not concerned about graceful degradation if the forms break without js here because this functionality would be required by the owner of the site. If they want the functionality, they have to have js turned on. Taht's all there is to it. A visitor to the site will not need this functionality only the persons that enter events..

just my thoughts

This is the angle I'm coming from too - data entry currently is a horrible pain especially with an international site (and coming from the UK 'our' counties are at the end of the list which is really annoying!) We definitely need a drill down so if you've said UK you don't see US states etc.. but that would probably mean location prompting for fields in a different order as currently country is the last choice....

We also desperately need reusable locations so we can slice the entered data to show all events on at a venue... I know there's some support in views but there are problems (such as only 'full detailed' countries can be selected and I also have problems with people not entering towns the same eg

Newcastle upon Tyne
Newcastle-upon-Tyne

are the same place...

Location at the moment seems an odd combination of free format and highly restricted! Which I think is why a lot of people resort to taxonomy instead to pull entries together and allow viewing by geography.

It would be really great if a bridge between the two styles (location and taxonomy) for location handling could be built.

http://drupal.org/node/217512