Well, the big location-based service I'd be (slightly) interested in is reminders; reminders before a meeting, class, etc. should allow a certain amount of time to get there, and a certain amount of time to prepare (gather notes, etc.) The preparation time is taken care of when you set up the appointment in whatever PIM you use, but the travel time depends where you are, which (for events outside your daily routine) may not be known beforehand.

Example: I used Google Calendar for all my classes, meetings, etc. my first year; as I had free incoming SMS on my plan at the time, I'd leave it on vibrate (as it usually was) and have a notification SMSed out 15 minutes before class/whatever. This didn't work out so well, since my office had poor reception for that network, so I often didn't get the notification till I was on my way to class...

But beyond that, the 15 minute delay was right if I was in my office, as classes were 10 minutes' walk away. But I completely missed one early morning meeting when I was driving in from home (an hour's drive), as I hadn't remembered it until i got the SMS about 45 minutes away. Then I almost missed another such meeting when I had set it up to warn an hour and a half early; I got that one while on the way in, and was at my desk an hour before the meeting -- and would have rolled right on through if someone else in the office hadn't tagged me at thirty seconds till.

If event definitions include a location, and my location is known, it's possible to pick up a notification at the right time, neither too late to be useful, nor too early to remember. All that's needed is a travel-time metric between two locations. I'm interested in that; it's the one missing piece to make PIM useful for me. While this isn't really the place, I'll toss out a few ideas anyway:

There need to be zones, each with several separately defined distance metrics; each zone may have direct links to other zones, but must have a "perimeter set", a list of locations from which it may be entered and exited. (For a small node, like my apartment, there'd be only one; for campus, there'd be a handful.) Each perimeter point or direct link has a distance metric from that point to anywhere in the zone, and there is a separate distance metric from point-to-point in the zone.

The root zone is inherently different* from the other zones, with a predefined distance metric from Google Maps directions (driving or walking, as appropriate, and possibly with a universal multiplier to convert walking to cycling); all perimeter points of other zones are within it, as are all locations not claimed by another zone, so it doesn't have a perimeter set or direct links. Warning time may be determined by comparing routes from the destination through all the destination zone's perimeter points, through the root zone to each of the current zone's perimeter points, and to the current location, and picking the lowest; since this only involves n*m routes with n and m perimeter points in destination and current zones, it should work snappily enough on any system.

For travel between on-campus locations, walking time is good, and point-to-point distance at 3 mph is close enough. For one end-point on-campus, and the other elsewhere, a fixed time for getting parked and a walking time from the lot to the point on-campus is a good option (for car travel), or just a fixed bike-locking time and a somewhat faster-than-walking distance function for biking...

And of course, these definitions need to be readily shareable, so everyone doesn't have to make their own zone definition for their hometown, and especially for places they visit. That's just proper design, of course; no assigning sequential ID numbers to zones and linking by ID .

You can do all this without submitting your location info to anyone (except Google Maps, if you use it as one of the distance metrics, and it can be replaced with any routing solution, or just an average as-the-crow-flies speed). (Oh, and since it knows what route is the quickest, it could deliver that info with the reminder...) LBS still looking useless? Probably to the operators (since if they do sell it, someone will clone it for free), but not to me.


*This looks arbitrary and ugly; ideally, there wouldn't need to be a "special" zone, and zones could be nested arbitrarily. (On closer inspection, of course, there always is a special zone at the root of the tree, but Google maps shouldn't be it; really the nesting is the point here.) Maybe even better, ditch the tree, and make the perimeter set just direct links that happen to go to corresponding points in the surrounding zone. The only problem is that as the zones get nested deeper (or as more adjacent zones get linked with direct links), brute-forcing the route becomes more expensive, and you get out of my algorithmic depth. The advantages, though, are stuff like supporting public transit systems, where it can automatically determine the best bus stop for you to head to, different times for a meeting in the building next door and the other end of my building, etc.; definitely advantageous.




(And yes, I know I should stop being scatter-brained, and then this would be unnecessary, so no need to mention it. )