What SimpleGeo could have been
blog.danrhodes.com
What SimpleGeo could have been
1–10 of 18 posts
Re: What SimpleGeo could have been
#2I agree completely. I hope this article has legs.
Re: What SimpleGeo could have been
#3> I don't know of any freely available database where you can provide an arbitrary polygon of geographical coordinates and it will return the points within that polygon.
MySQL geo extensions do this, explicitly. See:
http://dev.mysql.com/doc/refman/4.1/en/relations-on-geometry...
I'll give you that you can only really do MBR queries, but it's easy enough to approximate this to arbitrary polygons (and functions to do so are google-able).
I've always felt that all the worry about Geo being hard was mostly FUD. You can easily build a highly location aware application on a grid system without even using any true geospatial index and indeed one of the largest local sites does (see my profile)! Shapefiles aren't really all that horrible either since Tiger (i.e. US Census data) has gotten a lot better in the past couple years. You can relatively easily hack together a geocoding service in a fews days provided you have enough caffeine.
Re: What SimpleGeo could have been
#4"Most location databases (such as PostgreSQL and Mongo) let you query based on all points within a certain radius, but any features requiring more advanced querying are hard to come by. For example, I don't know of any freely available database where you can provide an arbitrary polygon of geographical coordinates and it will return the points within that polygon."
PostGIS (an extension for PostgreSQL) does this really well.
The most notable thing about SimpleGeo (to me) was that they were able to build PostGIS-like features on top of Cassandra. That's certainly attractive from a scalability perspective.
I was really excited to try SimpleGeo out, but decided it was just easier--and less risky since I don't have much NoSQL experience--to use PostGIS. It also wasn't clear to me whether you could store NON-geographic data in SimpleGeo (such as user accounts). A (very) brief look at their docs seemed to suggest you couldn't, and using multiple datastores seemed messy to me...
Re: What SimpleGeo could have been
#5"it's likely that whatever Urban Airship is going to do with the service will most likely revolve around location-based ads, rather than SimpleGeo's original vision."
The original vision for the company was to make mobile games...
SimpleGeo's biggest problem was a lack of any vision. They sucked in a bunch of data from outside sources (Yahoo WoE, census data, weather APIs, factual.com, etc) and got a bunch of engineers to just work on whatever interested them.
The products they did manage to produce were intended for an audience technical enough that they could source the original data and build it themselves if they really needed to. When you play that game, you have to price requests an order of magnitude or two below what they did.
Re: What SimpleGeo could have been
#6I have to disagree with most of this except the data problem. Building out a cloud database and API specific for storing and querying geo data is not enough of a value proposition. It's just not that hard of a problem to roll your own, which is what most serious applications would do. They're the ones with money. In fact, in some cases using SimpleGeo is a limitation because it doesn't have the robustness of full databases.
The part I will agree with you on is the data problem. There's a huge amount of great geo data out there with no clean repository. I kept telling them to focus on data and sell that, not the service. Oh well. Someone (factual?) will get it instead.
Re: What SimpleGeo could have been
#7Nobody's going to make any money just by aggregating & providing access to data points. Geo isn't as hard as everyone thinks it is. PostGIS absolutely does intersects with arbitrary polygons, for example.
Where people will make the money is by providing new, interpolated data layers; it's one thing to say "get the weather at location X!" and another to say "show me the best intersection to get a cab" or "show me where the closest taco truck is likely to be given today's weather & past behaviour". I understand Simplegeo was trying to provide the access to the data to enable people to answer these questions themselves; why not just sell them the answers?
Re: What SimpleGeo could have been
#8Does anybody know which database was powering SimpleGeo, the tech/stats etc. behind it and if they wrote any of it themselves?
Re: What SimpleGeo could have been
#9> I don't know of any freely available database where you can provide an arbitrary polygon of geographical coordinates and it will return the points within that polygon. MySQL geo extensions do this, explicitly. See: http://dev.mysql.com/doc/refman/4.1/en/relations-on-geometry... I'll give you that you can only really do MBR queries, but it's easy enough to approximate this to arbitrary polygons (and functions to do…
I guess, to nitpick, he means "any currently existing, freely accessible POI databases which support arbitrary polygon selection". Eg. most services which support "geospatial queries" (Flickr, Yelp, etc) only support MBR or simple geometry queries rather than true polygon intersects. Which I also misinterpreted but is also true (to my knowledge anyway). He's not saying it's impossible to set one up for yourself using PostGIS etc — if anything, that's his point.
I agree with you that it's simple enough to set one up for yourself that the value offered by a service is minimal.
Re: What SimpleGeo could have been
#10> I don't know of any freely available database where you can provide an arbitrary polygon of geographical coordinates and it will return the points within that polygon. MySQL geo extensions do this, explicitly. See: http://dev.mysql.com/doc/refman/4.1/en/relations-on-geometry... I'll give you that you can only really do MBR queries, but it's easy enough to approximate this to arbitrary polygons (and functions to do…
I guess, to nitpick, he means "any currently existing, freely accessible POI databases which support arbitrary polygon selection". Eg. most services which support "geospatial queries" (Flickr, Yelp, etc) only support MBR or simple geometry queries rather than true polygon intersects. Which I also misinterpreted but is also true (to my knowledge anyway). He's not saying it's impossible to set one up for yourself using…
Well he lists MongoDB and PostGIS as DBs that don't allow polygon selection, but your alternate interpretation is more truthful.
Yelp does do arbitrary polygon intersections on the backend for neighborhood queries, but I guess this isn't exposed in any API.