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
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.
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.
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...
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,
seattledance.org here in Seattle and
numerous others elsewhere
(please see my
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,
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:
- organizer creates a "page"
(actually a text file, not an HTML document)
accessible via HTTP
with their information (the data is in a specified format)
this page is fetched by a site that offers a regional web site
- the data is stored on the regional site, perhaps in a different format
- a user, seeking information about events, searches the page
- the organizer updates just one (1) file,
not several web pages
- the responsiblity for keeping the data current moves to the organizer
instead of the regional page's host
- new regional sites can pick up the data without involving the organizer
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:
Thank you for the visit.