At a recent Yahoo! Internal Hack Day, Mac developer powerhouse Karl Adam demonstrated an App he dubbed “Campus.” For any Yahoo! employee that installs it, one can locate a conference room by name or location in the campus’ multi-storied halls.

The App’s visual representation of the buildings are handled by beautifully-rendered illustrations (by Kalani Kordus) rather than over top of a Google map. This affords an ability to see each level of each building and highlight only elements of importance (conference rooms, not janitors’ closets).

The App, however, is missing some very important information. It doesn’t know -where- these important elements are. And because it doesn’t know that, it can’t know where I am in relationship to the rooms.

To know where such things exist, a location data store (describing lat/long locations of every object’s borders) must exist. The problem is, how do you get the very data that has, to date, been hard to come by? How can Apps get access to location data which isn’t in Google Maps already but is relevant to a group of people? In other words, how do we move from just understanding objective data (such as “Golden Gate Park” or “701 1st AVE, Sunnyvale, CA 94089”) to something more subjective (such as “de Young museum lawn” or “Yahoo! 1st floor bathroom”)?

I think the answer is somewhat simple: build a mobile App and a website to leverage those same people who’d be interested in the data in the first place. As they have a vested interest in the service, these users could accomplish tasks fed to this App by the developer looking to harvest and use the data.

To do this, the App would need to do several things:

1. Sign In/Register. Not because users love making new accounts, but rather because the system will need to support private projects and online storage.

2. Location capture. Lat/long coordinates WITH WiFi base station MAC address. Also any info from gyroscope and compass, if possible. (Could be useful if you’re wanting to plot where the door to a room is, or indicate direction.)

3. Metadata capture. User-added tags, notes, photos, videos, audio, etc. (Optional, but could feed the developer useful materials.)

4. Project selection. Choose a community project (whether public or private) based on current location and/or user account; or, choose a personal project.

5. Settings. Assuming most users will be submitting several locations towards the same goal, the App must facilitate rapid entry where it’s default is to use the last-used project, tags, etc. (Maybe the App should set a distance threshold, so that if a user captures a location 6 miles away from the previous location, the App assumes a new project?)

6. Submission queue. Connectivity could fail at any point; hold onto any captures that haven’t yet been submitted.

Additionally, this App will need a Web front-end (where developers can post projects, determine whether anyone or just a select few can participate, review results, modify entries, get access to the data via data dumps (i.e. CSV, XML, etc.) or data feeds (i.e. An API), and highlight their most prolific/helpful contributors. Assumedly users should be able to access the site, too, to modify their submissions, see the results of their participation, and sign up for projects not yet tackled.

The value of such an App would seem to be immense to anyone building location-aware Apps whose locations aren’t covered (or applicable) on Google Maps and other traditional mapping/location services. Developers could offer successful contributors money ala Mechanical Turk, a free copy of their App, or just recognition of who helped out.

There’s already been numerous successful user-submitted tagging enterprises to-date. Why not one for location, where the user doesn’t even need to learn lat/long coordinates, machine tags, or anything technical? Instead, all they need is the desire to help, an iPhone/Android phone, and the ability to press a button when at a location a developer requests.

Sounds possible. The question is: who wants to help build it?