Building on decades of insights from the information retrieval world, and using highly-scalable, battle-tested open source packages, we’ve found it invaluable for exploring genetics in novel ways.
Hi - it's actually quite different. As of now, we don't (yet) have a forward geocoding api exposed. Rather, most of the API functionality that's live is for backward geocoding. As in, with Google's Geocoder, you give a string and you get back a place. With us, you give a place (i.e. lat/lon) and you get where that place is and what's around it.
That being said, a number of people have been pinging us about getting simple geocoding functionality, so stay tuned for that as well :).
BTW, there are also a number of other differences - below is a quick list:
- Type of data: One of things we do is combine a number of different datasets (16+ M businesses, points of interest, intersections, etc...)
- Query type: You get very powerful expressiveness in the types of queries you do. You can literally make a request for 'Japanese restaurants that are within 1 mile and that are open at 10pm.'
- Media layers: For most entities, you can get media layers such as Twitter and Flickr. For example, you can get tweets around the mission (http://api.geoapi.com/v1/e/mission-san-francisco-ca/view/twi...). We're adding more layers as we go.
- UserView: Each developer gets a private namespace into which they can add information and run geo queries on it. Basically, you can annotate the world with close to zero effort.
The query syntax is pretty cool, but as far as raw geocoding I don't really get it -- Google has a much bigger dataset than this, offers reverse geocoding just fine (With good neighborhood data in the US and Europe). And I gather you are just proxying requests to twitter and flickr (and not actually storing all this for all places yourself) -- why wouldn't I just query their APIs directly?
Not trying to be snarky, I just don't understand....
As you might guess, the ownership over the data is a tricky issue, where there are many variables that aren't under our control. Our objective is to make the information as open as possible within these constraints. One thing to note, however, is that the userview portion (i.e. the data that an app WRITES to the API) does remain under the app's control (i.e. developers don't relinquish ownership). Over time, we do think there will be an opportunity to have developers contribute their improvements to a common pool of information to benefit everyone.
There will always be a free plan with a relatively reasonable volume - at minimum, it will always be a 'fremium' kind of thing. At which point we start charging is, frankly, to ensure that we can at least cover serving costs.
