[development] Making a whole site location aware - a design question

[drupal at mclewin.com]

I have a question for the masters.  If you are an impatient master, jump
over the context and to the second to last sentence for the question.

A friend and I are well into building up a Drupal 4.7 based site where the
user's location is taken into account in nearly every display.  The site,
www.folkjam.org (or folkjam.org for some), is most simply a database of
acoustic music jam sessions (Irish sessions, bluegrass, folk, fiddle,
stuff like that).  When a user visits the site, we determine their lat/lon
from an IP to lat/lon database (a custom module we've added), or from user
selection based on US zip code or finally from the zip code that the
location module injects into the user's login record when a user registers
and configures it.

By the time we are done, every display in the site will show only nodes
that a) have no locative data on them or b) Have locative data that is
within a 90 mile radius of the user's configured location.  We've come
pretty far, but there is one key place where we need some direction.  We
intend to contribute much of our work back to Drupal (which is why I'm
asking for help - I want the changes to be palatable).

There are seven pieces of information that we need to store in a way that
other modules can leverage them.  Three are critical to a location-aware
Drupal site. Four are important for display.

They are: The site visitor's Latitude, Longitude, Radius (stored in
miles), Country code, Postal code, Province, City.  The Lat/Lon/Radius are
the critical three.

We are presently keeping these in session variables wrapped in accessor
functions.  The accessor functions are namespaced as part of the site
specific glue module that brings most of our customizations together, and
the session variables are too.  Neither are appropriate for direct calls
from contributed modules such as the event.module.

In making event.module capable of only showing event-enabled nodes that
are within $search_radius of a lat/lon, we started by adding GET style
parameters and passing lat/lon/radius into the event.module.  Because
these three pieces of information needed to go all the way down the event
module's call stack to the data retrieval routine, most functions had
their signatures extended.  Completing this work will require touching the
entire event module theme as well, since the 'next month', etc navigation
links all need the lat= lon= radius= parameters on the URL.  We are not
happy with this solution as something to contribute back.

What we would rather do is store the seven location awareness information
tidbits in a 'well recognized location' where other modules can know to
use them.  Then we want to add a setting to event.module that can be
enabled to restrict events to within a search radius of the visitor's
'current location', and then modify the core data logic and display
building logic in event.module to constrain the events it retrieves based
on the lat/lon/radius in the 'well recognized location' when the location
module is installed AND for nodes that have locative data AND when the
active user has a lat/lon/radius configured.

In reading the notes from the DrupalCon on Vancouver it seems that
location awareness was a topic - I hope there is already some thought
about this that I just didn't read.  While I suspect that the $user object
is probably the place to keep this,  I am uncertain of how much we can
rely on the $user object when the user is not logged in - we want to be
able to customize displays even when users don't register with us or log
in.  Before fixing that little pocket of ignorance and becoming expert on
the nuances of $user, I thought I'd seek advice.

Hopefully that is enough context for you.  Here's the question: What is an
appropriate "well recognized location" within Drupal to keep these seven
pieces of information? (latitide, longitude, search radius (storage in
miles), country code, province, postal code and city.

I'm looking forward to having an answer (or seven :) ) so that we can get
closer to having patches in the patch queue.

Scott