Location Schedules 1
Brightkite and Shizzow have demonstrated that people are willing to transmit their location electronically to at least their friends, sometimes more, in exchange for being open to ad-hoc meetups .
What the leading services to date have focused on is where you are. This is not that useful because it says nothing about how long you'll be there. Whats more useful is where you will be.
To facilitate meetups, I want to see someone's location schedule for the day. That way I can plan my transportation and timing to align, like a Mars vehicle adjusting its trajectory to enter the atmosphere at just the right time.
Many people live by a very predictable schedule. Even for a cafe-person like me, I know my basic schedule for that day. I would be happy to enter that schedule in the morning.
Schedule for Don Park:
| Time Block | Location | Interruptable? |
| 10am-12pm | Home | Yes |
| 12pm-12:15pm | Food cart on NW 3rd | Yes |
| 12:15pm-1:00pm | Waterfront picnic lunch | Yes |
| 1pm-4pm | Urban Grind | Yes |
Once the schedule data is in, higher-order correlations can be mined. "When is a good time today to meet up with Bob Smith?" "There is a 30 minute overlap during lunch where you will be 0.5 miles from Bob at a time when he is interruptible". Another example is an automatic alert, such as a gathering of 3 or more friends at the same place. "Four friends are scheduled to be at the Green Dragon starting at 4pm"
If I wanted to meet Bob Smith, why not just call him up and schedule something? These meetups are less official than that. The use case is I have to work somewhere and I want to select the cafe that already has the greatest number of friends/coworkers scheduled to be there for these hours.
Instigating these meetups is difficult when you're the first one. The way to announce your intention is to state a time and place but what if you're only interested in that meeting and its existence depends on another agreeing to the same thing. Thats more like group scheduling and needs more thought.
I was focused on adding a schedule to a location service when I realized that calagator or upcoming are already what I'm describing. They understand schedules and locations. The table above could be put into calagator though it has no notion of a person. Upcoming could handle it. Events in upcoming can be made for friends-only. I would be doing this today but upcoming users are not expecting personal schedules like that. It would end up being spamy.
An open-source project like calagator could be extended or forked to understand the concept of user (which was explicitly avoided to date), and add the 'interruptible' or 'available for meetups' concept to the event.
There is still value to instantaneous location pulled from a GPS or the unique ID of a near-by wifi access point or cell tower. It adds or removes confidence to the schedule since it can say the person has been late/ontime for events recently past.
There's a third component to the location/event scheduling problem: participation. When you're just publishing a personal itinerary, there's no real need for anyone to RSVP, but one area where a centralized systems like Upcoming provides real value over a de-centralized, pseudo-anonymous tool like Calagator is in the ability for people to indicate that they are interested in, or plan to attend, an event.
On the other hand, Upcoming forces you to put all your eggs in one basket -- there's no way to pull in events from other sources, or edit your participations in an alternate client like iCal or Sunbird. I think a hybrid solution may be needed, either by allowing people to RSVP in Calagator for events defined elsewhere, or by aggregating participation data as well. (Probably relatively easy from Upcoming, and much, much harder from arbitrary user group and personal sites, unless they all start exporting 'ATTENDEE' data in their hCal.)
Also, while I like your scenario for finding good times and places to try to meet with someone, you are talking about a problem that's at least NP-complete. Doing very small-scale scheduling optimization may be feasible, but it will take some decidedly clever hacking to make anything that can handle more than a couple of people's schedules at once.