A location is not a mere number or label. On a large scale, location information challenges application developers to work with the mathematics of movement around the not-quite-spherical surface of the Earth; on a small scale, it requires complex calculations of optimal routes based on frequent updates of rapidly changing conditions.
But the investment of that effort offers huge potential rewards for the developer who masters the mechanics and has creative ideas about what to do with the results. After all, how often does a developer get to be part of the process of figuring out the usefulness of a whole new type of data?
The tools that developers have used in any given period have revealed the data types they thought of as fundamental; the legacies of those tools betray developers lack of familiarity with data types outside their familiar space. For example, the first programmers computed almost solely with numbers. The clumsy FORMAT statement of the FORTRAN of that epoch is evidence that working with text wasnt a frequent need or a polished skill.
The next generation of programmers took for granted the convenience of "glass teletype" text output and keyboard input. But developers are still writing code that works around the clumsy conventions of that timewhen even lowercase text was a luxury, and multiple sizes and styles of font were simply unheard of outside a typesetters shop.
Today, the new data type is location, and there are many things about the location data type that make it genuinely different from other data types that programmers have come to know and understand.
A location may take the form of an ordered pair of coordinatessuch as values of a latitude and a longitudebut there are aspects of location data that make it unlike other familiar numeric or alphabetic character types. Calculating distance between two locations is not a simple matter of subtracting scalar values nor even computing vector differences: Its more like envisioning the path that a beam of light would follow through a medium with wildly varying speeds of transmission.
The "distance" between two pointsmeasured on anything but an academic straight-line basisis not a geometric question but a project management determination: Of what are usually multiple possible routes, which one presents the best expected travel time and the least dreadful worst-case scenario?
People perform surprisingly sophisticated route planning tasks all the time, and they quickly recognize a naive algorithm when they encounter one. An application that recommends a route between two points based purely on the apparent distance by road or other path, ignoringfor examplethe difference between highway and back-road speeds or the relative traffic density of different times of day, will not engage and retain the user. The state of the art in this area is rising quickly.
Location-based applications are therefore fertile ground for exploring the potential of using a Web service interface to incorporate, for instance, current information on weather, construction disruptions or other dynamic forces from data feeds that would be expensive to duplicate.
Indeed, if the voluntary sharing of information and the collaborative development of content are the hallmarks of Web 2.0, then perhaps the next step of automating that sharing would justify the label of Web 3.0. As soon as one talks of sharing location data, though, especially anything with a real-time component representing the behavior or plans of any identifiable user, the issue of privacy quickly raises concerns.
At the third annual Where 2.0 conference this coming May in San Jose, Calif., participants will doubtless explore issues that have arisen at the two prior events, such as the ownership of a users location history, the proper balance between law enforcement needs and personal privacy expectations, and the division of roles and costs between private service providers and public infrastructures.
Developers who ignore the issues and opportunities of location awareness will wind up on the outside looking in.
Technology Editor Peter Coffee can be reached at firstname.lastname@example.org.
Peter Coffee is Director of Platform Research at salesforce.com, where he serves as a liaison with the developer community to define the opportunity and clarify developers' technical requirements on the company's evolving Apex Platform. Peter previously spent 18 years with eWEEK (formerly PC Week), the national news magazine of enterprise technology practice, where he reviewed software development tools and methods and wrote regular columns on emerging technologies and professional community issues.Before he began writing full-time in 1989, Peter spent eleven years in technical and management positions at Exxon and The Aerospace Corporation, including management of the latter company's first desktop computing planning team and applied research in applications of artificial intelligence techniques. He holds an engineering degree from MIT and an MBA from Pepperdine University, he has held teaching appointments in computer science, business analytics and information systems management at Pepperdine, UCLA, and Chapman College.