Mike Schuh's Event Finder - Introduction

©1999-2006 All rights reserved.

Searching for events

 To search for an event, it is necessary to supply three pieces of information:
type of event
At present, only three types of events are available (folkdances, orienteering meets, and rowing). In the future, it is planned to allow for sub-categories, such as contra-dances and English country dances.
location of the event
A city (with state), a zip code, or latitude and longitude. If more than one of these is given, preference is given to latitude/longitude, then zip code. If latitude/longitude is blank, and there is no match for zip code, then the city is used. If there is no match for city, then the "center" of the state is used. If none of these work, then you're outa luck... In the future, it is planned to include Canadian provinces and postal codes, as well as handling overseas locations.
the date (or dates) of the event
This is either the single date or a range of dates.

In addition to the location, a radius may be specified (default is 50 statute miles). The Event Finder will return any event that is within this radius about the location given, and meeting the criteria of event type and date. This distance is the "great circle" distance, and most likely will be numerically less than the driving distance...

Entering events into the database

Every event must include the above information in some form. The location is recorded by means of a venue code, which is simply a shorthand way of refering to the venue. It is formed from the two letter state/province abbreviation, followed by a three letter abbreviation for the city, followed by an abbreviation of the name of the venue itself. The three letter abbreviation for the city is loosely based on the airport code. The FAA provides a database of codes.

In place of a date, recurring events need to specify how often they reoccur. For example, the first Saturday of each month, or every Monday and Thursday.

The other information pretty straight forward. The better (more accurate) the information you provide, the more useful it will be to those looking for your event.

Venue codes

A venue code is formed by concatenating the two letter state or province code (in upper case) with a three letter city code (also in upper case, adapted from airport codes), and a site string that is unique within the city and state or province. While useful if all of the venues within a given city use the same city code, this is not essential. What is essential is that each venue's code must be unique.

The site string can be mixed upper and lower case, but (at present) must contain only letters.

A few comments on location...

Because this Event Finder attempts to find events within a given area, it needs to know where the events take place. The best way to do this is to tie everything to latitude and longitude. Unfortunately, most folks don't know the latitude and longitude of their venue. Hopefully, however, they know at least the city, and perhaps even the street address and zip/postal code. From these (especially the latter), we can approximate the latitude and longitude.

From the above, we get the following algorithm: 

  If latitude and longitude are given, use them.
  Else if zip/postal code is given, use that to look up latitude and longitude.
  Else if city and state/province are given, use them to look up latitude and longitude.
  Else if state/province alone is given, use the center of the state/province.
  Otherwise punt.
This is applied to both searches and events. (If we had a database of street addresses - which would be several hundred million records long for the United States - we could convert an address directly to latitude and longitude.)

The difference between "find" and "list"

"Find" means look - search - within a fixed radius of a known point for events, venues, or web pages. "List" simply looks for these items in the given state (and city, if specified). Actually, the process for the latter is a simple case-insensitive compare of the city string entered by the user and the city in the database - if the city in the database contains the entered string, the item is returned (so, entering "lake" would match on "Lake Stevens", "Mountlake Terrace", and "Blakely"). Likewise, entering "Los Angeles" won't match on "Anaheim". 'tis a broad net...

Future Design

Web pages with schedules

As anyone who has surfed the web looking for information on events knows, finding up-to-date details about an event in a distant city can be difficult. Searching for contra dances in Small Town, USA, will work (via a search engine) if the dance organizers have created a web page containing the text "contra dance" and "Small Town". It won't work if the dances are held in Small Town's bustling suburb of Itty Bitty Hamlet and the web page makes no mention of "Small Town", even though this might be a completely satisfactory answer to the search.

A potential solution is the regional web page. For contra dances there are several such pages around the country, Matt Fisher's seattledance.org here in Seattle and numerous others elsewhere (please see my Dance Resources page for a partial list). These are very useful to someone seeking information for a distant region, as they typically include dances that the user might never have heard of (I found an enjoyable dance in Albany, NY, from such a regional list). However, these regional pages require a fair amount of effort to keep current.

Keeping Data Current

The usual process for updating a regional page is for the organizer of an event to send the updated information to the webmaster who then edits the page as needed. Variations on this theme include configuring the hosting site to allow the event organizers to login and update their own information. As currently (well, partially) implemented, this EventFinder uses this model and relies on the organizers of the various events to keep the data current.

However, an organizer might have to update the information on several sites. Presumably the information is the same on all sites, so why type in "this Friday's dance will start one hour late due to a schedule conflict" on every system?

A distributed solution

What if an event organizer didn't need to update anything beyond their own page? This is the Internet, and distributed processing is all the rage. Here is how it could work: I suggest that this will have several advantages:

Where is Itty Bitty Hamlet?

I welcome your thoughts and suggestions.

To EventFinder home page
To Mike Schuh's home page
Mail (but not spam) is welcome to: schuh AT farmdale D0T com

Thank you for the visit.