SimpleGeo Blog

Updates to our Marketplace

Fri, 23 Jul 2010 11:43:00 -0600

Starting August 15th, we will start to enforcing users to accept a Terms of Service for access to every layer in the SimpleGeo Marketplace. This means that any layers you are currently using for which you haven’t added through the marketplace, particularly the com.simplegeo.global.* layers, will stop working. Any layer you’ve created privately will not be affected.

For the past few months, the Foursquare, Flickr, Twitter, Brightkite, Fwix, and Bump layers have been available but not advertised. We are actively working on licensing deals with these companies to make this data available to you soon.

As we build out the marketplace and re-launch our website in the coming months, the process of creating a publicly accessible layer and enabling a TOS will be more clear.

If you have data that you want to showcase in our marketplace, send us an email at marketplace@simplegeo.com.

SimpleGeo at Geo-Loco 2010

Fri, 16 Jul 2010 12:48:00 -0600

Next week, we will be participating in Geo-Loco 2010, an event that focuses on the business and future of geo-location services. Use the code simplegeo20 to get a 20% discount on a ticket to the event.

As part of the festivities, we will be hosting a networking event on Tuesday night at our new San Francisco headquarters, located at 41 Decatur St.

There will be a guest list, so please make sure to register soon as capacity is limited.

On Thursday July 22nd, we will be having open office hours that you can sign up for to pick our brains and learn about our API and product offerings. If you are interested in scheduling a time to come by, please send an email to officehours@simplegeo.com, and we will coordinate with you on a time to meet.

How to drop geo-tagged tweets into a SimpleGeo layer

Thu, 15 Jul 2010 09:55:00 -0600

Last week, we showed you how to grab all of your checkins from Foursquare, and visualize them on a SimpleGeo layer.

Pablo Estrada forked that code and created a script that imports tweets from Twitter, using the tweepy Python Twitter client.

The script is available to download on Github. The Twitter API by default only returns 20 tweets at a time. You can add the count=200 parameter to max out the request. If you wanted to grab the last 1600 tweets, you could use tweepy’s pagination functions.

Culture is Critical

Wed, 14 Jul 2010 17:31:00 -0600

I often like to joke that the dozen or so years I’ve spent working in and helping to build startups is the longest case study in how not to run a startup. Since starting SimpleGeo Matt and I have obsessed about culture. We spend a lot of time attempting to make SimpleGeo a great company to work for filled with wonderfully talented people working on difficult problems.

Recently, while working on our mission statement, Jeffrey, Rob, and I were brainstorming words we felt represented SimpleGeo’s products, goals, and mission. Two things ended up happening:

We kept interrupting each other. Finally, Jeffrey had had enough and we decided that we’d allow each other to fully express their opinions before retorting.
I shared some random link from the internet and started a completely unrelated discussion. All of the sudden Rob starts making a rowing motion with his arms. I asked, “What the hell does that mean?” Rob said it was an old joke from another company he worked at where they referred to people getting off-track in meetings as “kayaking.” From that point on all three of us were making rowing motions whenever one of us got off-track.

These two simple rules got me thinking. What if we codified a set of principles for SimpleGeo? What if our employees had guiding principles that they could point at during the hiring process, while building products, while arguing, etc.? After further thought, I sent off a Basecamp message with my initial thoughts on what would eventually become SimpleGeo’s “Cultural Creed.”

Being an agile shop, we iterated from my initial ideas into a set of 10, well 9, principles that we believe embodied SimpleGeo. Here they are:

Approach people and ideas with courage and respect.
Be attentive to customers and their needs.
Embrace and learn from failure.
Be curious.
Celebrate the bizarre.
Codify best practices.
Be adaptable; things change.
Repay technical debt.
Embrace and drive change.
GOTO 1

There you have it. The SimpleGeo Cultural Creed. I think too often in the race to raise money, hire more engineers, and build products that startups forget that their companies are an organism that’s growing and changing over time. As such, it’s important to remember your DNA.

Cheers,

Joe Stump
CTO & Co-founder

Moving HQ

Mon, 12 Jul 2010 13:01:00 -0600

About a week ago Joe and I gathered the entire SimpleGeo team at our San Francisco offices for a week of team building, camaraderie, and hacking. It was also a time for our executive team to hammer out the basics of what SimpleGeo will be as a company moving forward. One thing quickly became clear during that week: SimpleGeo would be better off if Joe and I were in San Francisco full-time.

This was not an easy conclusion to come to, especially for myself. While Joe is more than happy to return to San Francisco, I’m finding it difficult to embrace leaving Boulder. Boulder has been my home, my springboard, and a source of great joy since I moved here for TechStars. Don’t worry, though, both Joe and I will be returning frequently and are committed to supporting the great startup community in Boulder moving forward.

That being said, Joe and I want to be perfectly clear: SimpleGeo will maintain an active presence in Boulder moving forward. Boulder continues to be a great source of engineering talent, especially for location-based services such as us. The fact is, the Colorado Front Range has been the Silicon Valley of location for years thanks to the mining and oil industries here. We’d be remiss to ignore the talent lurking about Boulder. Or, as Joe often says, “We’d go to Antarctica to find great engineers if we had to.”

What a difference a year can make. See you all in San Francisco!

Thanks, Matt Galligan, Co-Founder & CEO

Explore your Foursquare checkins on a map with SimpleGeo

Fri, 09 Jul 2010 12:33:00 -0600

If you are a Foursquare user, have you ever wanted to visualize all of your checkins on a map? Using your Foursquare RSS feed and a simple Python script, you can import all of your checkins to SimpleGeo’s API and do spatial queries on them.

Step 1: Login to your Foursquare account and visit the Feeds page.

Take note of your RSS feed. In my case, it was http://feeds.foursquare.com/history/026d45564de36937b02de38a01095620.rss. You can add a count parameter to the end of that URL to get more items. I used count=2000 to get all of my checkins.

Step 2: Install the Python feedparser module. If you have setuptools installed, simply type sudo easy_install feedparser in your terminal.

Step 3: Create a new layer, and name it com.foursquare.[your_foursquare_username].checkins.

Step 4: Download this Python script and update your SimpleGeo OAuth token and secret, the name of the layer you want to store your checkins, and your Foursquare RSS feed. Make sure you have the SimpleGeo Python client installed.

Step 5: Once you’ve updated those custom fields in Step 3, open the Python interactive shell and type the following: import parse and then parse.main()

The script adds records to the SimpleGeo API 90 at a time, to avoid being rate-limited. If you login to our Dashboard and click on the layer you just created, you can then see all of your checkins through the data explorer.

If you have any questions about how to use this script, feel free to send me an email at andrew [at] simplegeo.com.

Update: Bill Shupp has written an excellent version of this script in PHP.

On the hunt for a Data Scientist

Wed, 07 Jul 2010 11:55:00 -0600

We’ve got a lot of data at SimpleGeo. Sadly, our data is wandering through our server farms aimlessly in search of the meaning within itself. You know, the usual existentialist questions that data sets seem to have:

What do I mean?
Why was I written to disk?
Will I just end up as an input to some larger aggregate?
Should I wear XML or JSON today?

We’re becoming a bit worried here at SimpleGeo. Our data has taken to wearing a black beret, smoking cigarettes, and reading La Nausée in dimly lit coffee shops while it searches for the meaning of itself.

As a result we’re actively looking for a Data Scientist to help us and our data find meaning in our data’s life. Besides weaning our data off of caffeine and nicotine, we’re hoping you exhibit the following traits and desires:

Live near, or are willing to relocate to, San Francisco, CA.
Advanced degree (MS, PhD) or applicable experience in something resembling applied mathematics, computer science, machine learning, economics, or physics.
Demonstrable experience in extracting useful insights from large datasets.
Experience in working with large datasets using Hadoop is a huge plus.
Experience with Java and/or Python.
Experience with data analysis tools, such as MATLAB and/or R, a plus.
A strong desire to work with a small, but highly technical team.

If this sounds interesting to you, or sounds like someone you know, please send us your resume (PDF or TXT) or LinkedIn profile to jobs@simplegeo.com.

Hacking on earthquake data with Python

Wed, 23 Jun 2010 14:33:00 -0600

This week, a huge majority of the SimpleGeo crew is in San Francisco, hacking away on everything, including adding data to our Marketplace.

Yesterday, we added some data from recdata.gov, and today we are experimenting with the USGS Earthquake data catalog.

The dataset is updated by the USGS every few minutes, but for the purposes of this experiment, we’re just going to download the latest version of the XML file and parse it. This data is from the past 7 days.

We used Python to hack together this script that adds records to the SimpleGeo API. There are three parts to the script:

Here, we are initializing the imports and setting up our authentication. Grab your OAuth key and secret from the Account Settings page.

The USGS returns the timestamp of an earthquake in a weird format, so here is some code to generate a standard time object for Python:

And here is the actual parser, using lxml. It’s pretty straight forward; we are basically creating Record objects and injecting them into the API 90 at a time.

When it’s all said and done, there are about 1800 records in the API now.

The next step is to write some sort of script to update the XML file every few minutes so the records are up to date.

If you want to play around with this data, activate the layer in the Marketplace.

Marketplace: Recreation Information Database

Tue, 22 Jun 2010 11:59:00 -0600

The SimpleGeo Marketplace is an place for developers to share their data with the rest of the community.

A new free layer has just been added to the Marketplace from http://www.recdata.gov, and it’s called Recreation Information Database.

The layer includes U.S. campgrounds, parks, museums, historic sites, recreation sites, and other nature-related points of interest. There are roughly 9,000 records in this layer.

To start using this layer, login to your SimpleGeo account, and visit the layer’s page. Click “Review Terms and Activate Layer”, and accept the terms. Then you can visit the Data Visualizer page and pan around to see the records on the map.

This is just the beginning. The engineering team has a data wishlist internally, and during our hack week in San Francisco, we are adding to it.

We would love to know what other data you want to see featured in our Marketplace? Let us know by pinging us on Twitter.

iOS 4.0 + SimpleGeo = Win

Mon, 21 Jun 2010 16:26:00 -0600

Apple’s announcement of offering applications the ability to receive location updates while running in the background has given SimpleGeo another reason to shine. There are many attractive use-cases that this new feature opens up. We’re happy to announce that iPhone developers can seamlessly update their endusers’ record whenever the device is sent into the background. Combine this with our ability to provide a record’s history and we have a way to track a record’s location across its entire lifetime.

Along with background location updates, we also wanted to provide a wrapper class around the location manager that incorporates our pushpin service. One of the features of our pushpin service is the ability to query for a set of regions the encompasses a latitude and longitude. For example, you could tell us your user was at 37.75899333917751, -122.42711305618286 and we’d tell you they were in the Mission District, which is in 94107, which is in San Francisco, which is in California, etc. We wrote a nice wrapper around the location manager delegates in iOS 4 which will call your delegate when a user enters or exits a region. Yes, this means you can now do background geofencing on any iOS 4 device for geographic, political, and cultural boundaries. Of course, this works just fine in iOS 3+ devices as well, but only works if the application is open and running.

Adding Background Location to your Application

First you need to setup your XCode environment to be working with the iOS 4.0 SDK. Next, clone the current HEAD of the master branch from the SGClient Github repository. There are instructions in the README file that tell you how to add the compiled static library to your project. If you don’t feel like working with the static library, you can also just import the source files into your own project.

There are a total of six steps, two of which are optional, that must be met in order to get background location up-and-running within your application. These requirements can all be implemented wherever your application defines its UIApplicationDelegate.

Step 1

Initialize the SGLocationService shared instance with your OAuth token/secret that can be viewed on your dashboard.

Step 2

Notify the shared location service that the application entered the background.

Step 3

Notify the shared location service that the application left the background.

Step 4

Create a couple of end-user records that you want to be updated while the application is running in the background.

Once you’ve registered the records that you wish to have tracked in the background, you are done! Requests will be sent out for each of the tracked records every time the location is updated. We wanted to be nice to peoples’ data plans and their batteries so we added an extra cherry on top! The SGLocationService provides a cacheing mechanism that commits all generated requests to a file so they can be sent over the wire when the application enters the foreground.

The following steps are optional and are only required if you wish to support said caching.

Step 5 (Optional)

Notify the shared location service that the application has entered the foreground.

Step 6 (Optional)

The SGLocationServiceDelegate must implement the option method locationService:shouldCacheRecord: method and return a YES boolean value.

Retrieving a Record’s History

SimpleGeo offers the ability to query the history of a enduser record. The client creates its request asynchronously which decreases time spent on the main thread. This allows the SimpleGeo client to respect the delegate notification model while allowing UI events to propagate through unharmed. There are two different ways to query for a record’s history depending on what type of objects you are using.

`id`

If you are a person who enjoys working with low-level objects, the SGLocationService comes equipped with a single method named history:. It takes in a single SGHistoryQuery object as its only parameter which provides the proper values that initialize the future history request.

`SGRecord`

The SGRecord class is created not only as a demo implementation of a class that conforms to the SGRecordAnnotation protocol, but also to add some extra features to its subclasses. One of these features is the ability to generate a history request from the object itself.

`SGLocationManager`

SimpleGeo’s pushpin service provides a way to retrieve a list of polygons for a given latitude and longitude. These polygons define regions that encompass the latitude and longitude. Regions can be anything from a neighborhood or city to a state or zip code. Wrapping the `CLLocationManager` around this functionality provides a way for the client to receive callback notifications about regions that the phone has just left or entered. This is commonly referred to as [geofencing](http://en.wikipedia.org/wiki/Geofence).

SGLocationManager is a simple wrapper around CLLocationManager. Meaning, wherever you have CLLocationManager being allocated and initialized you can simply swap it out for the SGLocationManager. If you wish to receive callback notifications concerning region updates, there are just two extra methods that need to be implemented by the CLLocationManagerDelegate.

The following is an example implementation of these two methods that simply presents a message for the new region set.

So that’s it! You can now track where all of your users are and when and you can now have your application be notified when they leave a given city, state, zip code, neighborhood, etc. Please use your newfound powers with care.

Living Up To Our Name

Wed, 09 Jun 2010 12:38:00 -0600

When I first accepted the job at SimpleGeo as VP of Product, the first thing I did was sit down with Joe and Matt and talk about our brand. I told them, “the way I see it, we have two choices: one, we change our name; or two, we work our asses off to live up to it.” See, I’ve known Matt and Joe for some time, and while I wasn’t involved in the creation of SimpleGeo, I’ve always been in the background as a friend. I know what they set out to accomplish with the company and I know we can do it. I wouldn’t be here if I wasn’t 100% sure about that. However, I feel that we could do a lot better job embodying our name, Simple.

To be simple is to be accessible. To be uncomplicated and free of unnecessary complexity. Being simple means being easy to understand and being accessible to an infinitely large group. By calling ourselves “simple” we have a lot to live up to considering that what we do isn’t really simple at all – but that doesn’t mean it can’t be simple for you to use. And even more-so than it is today, it will be.

Moving forward, “simple” is our core focus – for all aspects of our company. Sure, we have and will continue to have incredible technology. Our technology is the reason that we’ve become a leader in the location space. However, I think where we’ll really win is by focusing on simplicity. To put it in perspective, my goal is for us to become the Zappos of location.

Yes, really!

There are tons of places to buy shoes online. A handful of businesses do a great job, but they’ve got nothing on Zappos. The reason they’re in a league of their own is because of their focus on service. They understand that by focusing on service, they alleviate the customer’s main pain point of shopping online and win that customer.

The pain points of our target consumer stem from complexity, so our commitment is to simplicity. Coupled with unparalleled technology, SimpleGeo will win by living up to our name.

Here’s how we’ll do it:

Over the course of the coming months you’ll be seeing a lot of changes around here. The first thing I’ll tell you is that you won’t see any changes that will affect the services you’re currently using, so don’t worry about that. What you will see is an overhaul of all of our tools (as well a few new ones) with a serious focus on user experience. Keep your eye out for much, much better data visualization as we work with our friends at Stamen Design. Next, we’re rebuilding all of our support channels, opening up a chat room to make us more accessible, and building our own API documentation portal because there isn’t a solution that best fits the needs of our developers.

You’ll also be seeing a new website that is cleaner and clearer with dedicated portals for businesses and developers who are either considering or are currently using SimpleGeo. The new site will also have a focus on education which will happen in two parts:

Developers: just because we’ve committed to making things as simple as possible for you, doesn’t mean you shouldn’t be able to fully understand what’s going on under the hood. You can count on us for this.

Businesses: location is an exciting and important new space, and the faster you adopt it the better poised you are to stay in front of the pack. However, it’s a lot to wrap your head around. You can count on us for this.

We have a few other things that we’ll be announcing soon, but we don’t want to give everything away just yet! We can, however, show you that the changes have already begun and reveal our rebranding:

One of the main focuses in this rebranding was longevity in the design. If you’re familiar with the previous logo, you’ll notice there’s not really a huge change – just a change in type. The core of the identity remains the compass, and that was almost completely untouched, with the exception of fixing the thickness to match the new typeface. What I was trying to accomplish with the rebranding is very much what we’re trying to accomplish as a company – focus on simplicity. The core of what was done was great, it just needed to come across more accessibly.

After exploring a couple dozen typefaces, I found what I was looking for in Hoefler & Frere-Jones’s Gotham. It’s an incredibly versatile face spanned across nearly a half-dozen styles and weights – and it’s deceptively simple. What I love most about the typeface is it allows the focus of the identity to be on the compass, but each letterform maintains a unobtrusive modern beauty that would be worthy of being the logo sans icon. Sorry, I’m being a type nerd. If you’re one too, check out HFJ’s history on Gotham here.

One last thing I’ll show you is one in a suite of logos for all of our products. Matt wanted to just reveal the new branding, but because I have a hard time not sharing work that I’m excited about, here’s the logo for our powerful Pushpin service. Don’t tell him I showed you!

That’s all I’ve got for now from the product side of SimpleGeo. I hope you’re as excited as we are for what’s to come! If you have any questions, concerns or would simply like to chat about food, movies or metal – feel free to get in touch with me at jeffrey@simplegeo.com.

A look at our iPhone Augmented Reality SDK

Wed, 02 Jun 2010 09:49:00 -0600

Ever since the early days of CrashCorp, we have been working on an interactive augmented reality environment for the iPhone.

Last week, we released it to the public. You can fork it on Github.

The code is written on top of the OpenGL pipeline. The AR environment projects latitude and longitude coordinates into a 3D space. By calculating the distance and bearing from each point of interest, one can create a simple matrix transformation to apply to the model view matrix.

Once the points of interest have been translated about the origin, rotation matrices can be created by the signals received by the compass’s heading and accelerometer values. Using these rotations transformations, the camera can point in any direction and the 3D world will be able to respond properly and place the objects on the right vector.

If you are familiar with the book Daemon by Daniel Suarez, you can think of our AR environment as D-Space.

In addition to our AR SDK, we have two more components for iPhone development:

SGClient - An async Objective-C client that interfaces with our API. It contains encoders and decoders that allow developers to work with higher level objects. Also, once 4.0 iPhone OS is released publicly, we will push our background location code to the public repository.

SGMapKit - A subclass of the MKMapView that makes it easy to load annotations into the the map from SimpleGeo.

We have some other tools in the pipeline for Android, so keep your eyes on the blog and our Github account. If you have any questions or need any help with our API, please open a help ticket.

Anatomy of a good prank

Tue, 01 Jun 2010 15:22:00 -0600

It was recently announced that Jeffrey Kalmikoff is joining our team to head up product at SimpleGeo. Matt and I had been wooing Jeffrey as soon as we heard he’d left Digg. Of course, we weren’t the only ones wooing Jeffrey, which was causing Matt a great deal of stress over the thought of him choosing to work with someone else.

It all came down to a single day, which Jeffrey had told us he’d get a final word to us by. I was sitting home hacking on XOAUTH the Thursday before that fateful Friday when Jeffrey IM’d me. He gave me the good news that he’d decided to join SimpleGeo. Having the good news in hand, Jeffrey and I decided to do the only logical thing: royally mess with Matt.

So we devised a plan and Operation Kutcher was in motion.

After much debate, we decided it would be extremely hilarious if we had Rob Hayes from First Round Capital, who is both a board member and our lead investor, to call Matt and tell him that FRC had poached Jeffrey to be an entrepreneur in residence. For those not intimately aware of the inner workings of the relationship between founders and investors, this is equivalent of high treason. In fact, given that Rob is on our board it very likely would go against his fiduciary responsibilities and could possibly be grounds for litigation.

The notion that Rob, or any other investor, would do such a thing knowing that we were aggressively pursuing Jeffrey was so preposterous that we didn’t think Matt would believe it. So what to do? I contacted MG Seigler from TechCrunch and asked him if he’d participate in the prank by calling Matt directly after Rob and asking for a quote on a rumor he’d heard about FRC poaching high profile hires from their own portfolio companies. MG loves a good prank as much as the next guy so he was in.

The trap was set. Rob would call at 4PM, MG would call promptly at 4:05PM, and I’d call Matt with Rob looped in at 4:10PM. The entire time Andrew Mager would be filming Matt’s reaction.

I love it when a plan comes together.

At about 4:01PM Matt started calling and texting me nonstop. Once I’d heard back from MG, I got Rob on the line and dialed Matt up with Rob on mute. Needless to say, Matt was extremely unhappy. By his own admission he was near tears. He felt betrayed and, worst of all, had lost a key hire to his own board member! I nearly wet myself.

The reveal happened when Matt told me Jeffrey’s title would be “Designer in Residence” at First Round Capital. I then asked him, “Wait, you mean his title is ‘derrrr’?!” At this point everyone in the room and on the phone started dying laughing. After a few seconds of shock and confusion Matt realized he’d been punked.

Below are the two videos we took to document the prank. Enjoy!

Introducing Pushpin queries

Fri, 21 May 2010 14:55:00 -0600

The SimpleGeo API has three new endpoints that you can use today in our Python, PHP, Java, Objective-C, and Ruby clients.

[From Flickr - by mil8]

contains/

Does a “pushpin” query through a series of polygon layers and identifies the “cone” of administrative and other boundaries in which the point lies. (In geographic terms, a polygon is simply a collection of points that are connected by a closed path.)

Returns a list of features containing id, name, abbr, type and bounds fields.

id: A string that uniquely identifies the feature in the SimpleGeo gazetteer. This ID can be used to query the exact shape of the polygon itself via the boundary API call.
name: A well-known name English-language name for the entity. This may change in the future.
abbr: If present, an official abbreviation for the entity, e.g. an ISO code, postal code, or similar.
bounds: A list containing the (west, south, east, north) bounds of the polygon, in that order.
type: A string describing the type of feature identified. May or may not be one of:
- Country: A national boundary.
- Province: A state or province.
- County: A county, parish, or similar sub-provincial administrative entity. US only at present.
- City: An incorporated city, town, village, hamlet, etc. US only at present.
- Urban Area: An approximate metropolitan region, from the 1:10M NaturalEarth cultural dataset. May be useful for places outside the US where no incorporated place boundary is (yet) available.
- Neighborhood: A usually approximate boundary for a (usually informal) sub-division of a city. US only at present.
- Postal Code: A postal delivery region. In the US, a ZIP code. US only at present.
- Legislative District: In the US, a congressional district for the currently sitting US Congress.
- Census Tract: As defined by the US Census Bureau in the most recently published census (2000).

Other values are possible, so this list will be updated from time to time.

overlaps/

Queries a series of polygon layers and identifies the “cone” of administrative and other boundaries that overlap with the given bounding box. The arguments are expected in units of latitude and longitude. The results are returned in the same form as the contains query.

The following parameters are supported for the overlaps query:

limit - How many features to return. Note that this is not a strict count of how many features will be returned, but rather the maximum amount that will be returned. The maximum number of features returned is 1000. The results are not paginated, so if you need more than 1000 results, consider breaking down your bounding box into multiple queries.
type - If only one feature type (as defined under the contains query documentation) is desired, the results can be constrained to that feature type.

boundary/

Returns a feature object from the SimpleGeo gazetteer, as above, along with the geometry of the feature in GeoJSON format.

The id parameter to this method should given in the same form as returned by the contains method above.

Examples

With the contains endpoint, you can give us the latitude and longitude of a point, and we will give you all of the neighborhoods, counties, census tracts, and zip codes associated with that point.

With the overlaps endpoint, you can do the same type of query as above, but with a bounding box instead of just one point:

Additionally, you can find the coordinates for each of these polygons with the boundary endpoint.

There is good documentation on how to use these new endpoints in our Python and PHP tutorials. You can also read about the data that is returned on our endpoints page.

SimpleGeo and Google's Latitude API

Wed, 19 May 2010 17:11:00 -0600

Photo thanks to TechCrunch

We all know geolocation is the current hotness on the web. Google has been a leader in location for a long time, starting with the launch of Google Maps in 2005. Since then, there have been lots of Google products that center around geo: Local, Latitude, Earth, etc. Today Google announced an API for Latitude. For those that haven’t heard of it, Latitude is a way for Google to track your movements in the real world and, subsequently, share those movements with the people and services of your choosing.

Google’s announcement is great news for the geo space, but we also think that some folks are misunderstanding exactly what it does. Some of the initial feedback we’ve been hearing is that this new API will surely lead to the demise of SimpleGeo, Foursquare, Gowalla, etc. The truth is, the Latitude is something very different altogether.

It’s Fire Eagle Redux. For those of you that are unfamiliar with Yahoo!’s FireEagle service, it was a way for a user to securely store their location and share that information with other users and applications. It gave privacy controls over which services could see that data and at what granularity (e.g. Digg can see exactly where I am, but Facebook can only know what city I’m in). FireEagle has, largely, fallen into disrepair. All of the original team has left, including Seth Fitzsimmons who’s now with SimpleGeo. It was, as the saying goes, the Edsel of location services. Basically it was too awesome too early.

Fundamentally, this is what the new Google Latitude API is. It’s not a distributed geospatial platform that allows app developers to build robust location-aware apps. It’s not a location-aware game that you can check in to local businesses, find friends, and get coupons. It’s only concerned with presence.

Josh Kopelman at First Round Capital, who was our lead investor in our first round of financing, has a fantastic post on the importance of presence and what the Google Latitude can provide. One of our co-founders, Joe Stump, wrote a guest post for TechCrunch on the impending war over presence.

So how is SimpleGeo different?

While we see Apple’s Core Location service and Google Latitude API as a great way of acquiring a user’s location, the SimpleGeo API is what you do with that location.

If you want to know the nearby coffee shops of a user, whether you’re using the device’s GPS or the Google Latitude API, you can make that kind of query with SimpleGeo.
If you want to discover what political and cultural boundaries a point resides in, you can do that using our pushpin endpoint. See the API Docs for more information on this powerful service.
Want to see what the crowd-sourced population density of a given area is based on data that Skyhook as been collecting over the years? You can get that done with SimpleGeo.

SimpleGeo is much more than presence. It’s a fully functional, cloud-based geolocation infrastructure.

Does SimpleGeo play nicely with Google Latitude API?

Absolutely. The Google Latitude API, being the presence engine that it is, is a great source of location data to feed into SimpleGeo. If you have an application that wishes to store Google Latitude data, combine it with other data, and leverage that data to create a new experience, SimpleGeo is a great way to glue that all together. In other words, Google Latitude provides only one piece to the overall location puzzle.

Both APIs are RESTful, so you can quickly and easily transfer data between the two services.
If you have customers that are not using Google Latitude, SimpleGeo can handle their background location and presence.
If you’d like to find out more information about a point you’ve gotten from Google Latitude, SimpleGeo can help out with that as well. Just get in touch with us via this page.

As usual, read the fine print.

As a developer, to use Latitude API, every user you want location information from has to authenticate with Google. This means that every user in your system needs to either have a Google account or create one and, once they have done so, they need to go through an OAuth flow to authorize you to their Latitude account.

Some other fine print that might lead a developer or company to use SimpleGeo over Google Latitude API for their background location needs include Section 1.2 of the Google Latitude API Terms of Service.

1.2 Your License to Google. By using the Service, You give Google, its affiliates, and partners a perpetual, irrevocable, worldwide, royalty-free license to copy, distribute, modify, translate, publish, publicly perform, publicly display, and otherwise use for any purpose any data, information, or content which You send to the Service.

There’s really no mincing of words here. You do not own the data that your application provides to the Google Latitude API. On top of this, Google retains the right to do whatever they wish to do with that data.

Google further clarifies their stance on this subject in Section 2 of their Terms of Service.

For purposes of the Terms of Service, “Intellectual Property Rights” shall mean any and all rights existing from time to time under patent law, copyright law, semiconductor chip protection law, moral rights law, trade secret law, trademark law, unfair competition law, publicity rights law, privacy rights law, and any and all other proprietary rights, and any and all applications, renewals, extensions and restorations thereof, now or hereafter in force and effect worldwide. As between You and Google, You acknowledge that Google or its licensors own all right, title and interest, including without limitation all Intellectual Property Rights, in and to the Service and the Content and that You shall not acquire any right, title, or interest in or to the Service or the Content, except as expressly set forth in the Terms of Service.

We love Google Latitude and fully expect many of our developers will be mashing up data from this service with services from SimpleGeo. We are glad to see Google is taking the issue of presence very seriously and look forward to what our developers can build with it in our ecosystem.

It's Been A Big Year

Tue, 18 May 2010 09:17:00 -0600

Matt and Joe: The humble beginnings of SimpleGeo at SXSW.

It’s been a year since Joe and Matt got started on CrashCorp, the precursor to SimpleGeo. What started out as an augmented reality gaming company is now an influential player in the geolocation space. Even in the last six months, we’ve made incredible progress. Between raising our seed round, hiring 15 employees, going into private beta and subsequently launching the product, we’ve been on quite a roll. So it’s with that, that we’re very excited to be announcing some big news. Let’s get right to it:

Funding

We’ve always heard “don’t go fundraising when you need it, raise when you can”. Though we had no idea that we’d be fundraising again after only five months, we’re really pleased with the outcome. It’s with great pleasure that we announce that we’ve just raised $8.14 million in a Series A round. This round was mostly populated by some of our previous investors Redpoint Ventures, First Round Capital, Lowercase Capital and angel Ravi Narasimhan. However, we’ve also added Boulder-based Foundry Group to the fold.

We’ll be bringing Redpoint’s Scott Raney to the board of directors to join First Round’s Rob Hayes, Joe and Matt.

It’s certainly been an exciting to put this round together. We’re stoked to be working with all the usual suspects again. We’re equally excited to have the team at Foundry Group on board as well. Matt has counted Foundry Group among his trusted advisors since his days in TechStars and we all have incredible respect for them.

The purpose of this round is to put a stake in the ground, to say that we’re here to build something big, something revolutionary. We’ll be using this capital to further construct our excellent team (we’ll get to that shortly) and to continue to build upon the incredible platform we’ve been able to put together.

Now about that team…

Hires

Joe was recently asked at MeshU what lessons he’d learned while starting SimpleGeo. Joe said, and Matt agrees, that he’d have brought in top business talent sooner. Today, we’re announcing three key hires on the business side along with two more amazing engineers.

Rob Bailey will be joining us as VP of Business Development. Rob most recently founded Lotus Vodka, but before that was a key person on Yahoo! Mobile’s business development team. While at Yahoo! he closed Yahoo!’s largest strategic deal, measured by users, in the companies history. We’re excited to have Rob join the team to help us refine our pricing, improve the product, and enhance our partnerships.

Jeffrey Kalmikoff will be joining the team as VP of Product. He’ll be heading up all of our design and non-API products. Prior to joining SimpleGeo Jeffrey was Creative Director for Digg and Chief Creative Officer for Threadless. Jeffrey’s resume speaks for itself, so it goes without saying that we’re extremely happy he’s decided to join the team.

Nicole Williams will be joining us as to help manage HR, finance, operations, and facilities. Now that the team sits at 17 in two offices, it’s critical to have someone like Nicole on board to keep us focused and organized. Nicole joins us from Digg as well. Those of us at SimpleGeo who worked with Nicole at Digg are overjoyed she’s decided to join the team.

Of course this doesn’t mean Joe has given up hiring engineers altogether. SimpleGeo continues to hire some amazing engineering talent. We’re happy to announce that we’ve hired two more engineers.

Ian Eure and Joe have been working together continuously for over eight years. We’re happy to report that tradition continues at SimpleGeo. Ian left his position as a Sr. Infrastructure Engineer at Digg a while back and, thankfully, agreed to subsequently join our burgeoning and talented engineering team. Ian will be working on our forward facing website, automation, deployment, and infrastructure needs.

Paul Lathrop has been building, maintaining, and configuring large clusters for many years now. Most recently Paul was a Sr. Systems Engineer at Digg. Paul’s experience in processing large amounts of data and coding automation software for clusters will be greatly appreciated at SimpleGeo.

Next Steps

We’re going to be changing and improving our product, positioning, marketing, etc. over the next few months. While the current API will stay up, we’ll be making some significant improvements to it over the coming weeks and months, including some fantastic new features. There’s quite an exciting road ahead and we’ll keep you up to date every step of the way.

Easy as riding a bike: SimpleGeo API and iPhone 4.0 background location

Fri, 30 Apr 2010 12:43:00 -0600

This month, Apple announced a background location feature for the next generation of their iPhone platform, and developers are already starting to use it with SimpleGeo’s API.

Andre Navarro (@ecito) from Houston is one of the first to build something. While it’s quite simple, it’s still really cool to see the possibilities of what background location can do. Navarro tested out his app called “privacyisforwhips” on a bike ride through Houston:

He used a Javascript polyline encoder to follow his tracks on a Google map, adding records to his SimpleGeo layer. He also built a website that tracks his every move.

Navarro open-sourced the code, and you can play with it on on Github.

Have you built anything with background location? If so, we’d like to hear about it.

Announcing some changes

Thu, 22 Apr 2010 14:06:00 -0600

We’re about one month post-launch now and we’ve learned a LOT. Both internally and from our amazing users. Some comments like these really get us fired up:

amitm: Loving the simplicity of @simplegeoinc. Took all of 10 minutes to get location integrated into our upcoming game

cbmeeks: Man, you guys friggin’ rock

jtkendall: got the API for my app working thanks to CodeIgniter, MySQL, and the nearby endpoint of the @SimpleGeoInc API.

ecito: iPhone 4.0 using background location + bicycle + SimpleGeo API = http://twitpic.com/1fosve

The passion that our users have shown towards SimpleGeo continues to mirror the passion that we have in creating the product. We know a lot of people are excited about geolocation and our goal is to be there every step of the way. So with that, we’d like to announce a few changes coming soon:

We’ve lifted limitations on layers

Initially we had released our pricing model, where the free product would only get one active layer at a time. It quickly became evident that this was not something that would be that useful. Beyond that, even at the top end, with 100 layers, there could still be a potential of wanting more.

Shortly we’ll be updating the model so that you can create as many layers as you want through the admin interface. Theoretically, there’s a limit to how many you can create while we’re still using MySQL for this. Once we switch to storing layers in Cassandra, you’ll be able to create layers programmatically through the API without any limitations whatsoever.

We’re also actively working on a solution for deleting layers. We hope to have initial support for disabling layers in about a week.

Drastic changes coming to pricing model

Similar to the layers issue, we had made general assumptions about our product and the concept of an “average customer”. Truth be told, there really isn’t an “average customer” with our product. Some people need lots of reads, some lots of writes, some only want the data in our Marketplace. As such, we realized winith days of launch that a change was necessary.

With that, we’re going to overhaul the pricing model drastically. Gone are the generalized plans, and in their place we’re introducing a variable pricing model.

Basically there will be sliding scales for various parts of the product that will impact the pricing:

# of records stored: Think of this like Amazon S3. Basically this is the persistent storage for all of the points that you’re creating.
# of queries: This is the read. You toss us whatever kind of info you’re looking for, and the layers that you’re looking to get it from (this accounts for your own data, as well as Marketplace data). Note that querying is easier for us to do than writing new content, so as such, this will be priced more cheaply.
# of points tracked: This is pretty much the same thing as records stored, only optimized for background location. It will be a cheaper way of handling lots of point updates. A “point tracked” would be a user, and where they’re moving throughout the world, for example. So think of this simply as “number of active users you’re enabling background location for”.

There will also be a series of add-ons that will be available, like instant backups to Amazon S3, callback URLs, and lots of other great things we’re cooking up. The free model will also still exist, though will probably change to be a bit better as well.

The big distinction here, however, is that “maxing” out your plans will come out to be a quite a bit cheaper than listed today. We were making certain assumptions with our pricing scale that were incorrect, and we’re comfortable in bringing the costs down. So you’ll dial your plan into exactly what you need and only pay for exactly what you need.

These changes will come in the next few months as we experiment with the model.

The “Hackathon” plan

This is something that we’re very excited to be pushing out. Basically we got a lot of questions around whether or not a customer could stress test our system to make sure we could handle everything they were throwing at us. Beyond that, it was hard for someone to determine just what they could do with the free plan alone (especially if they were evaluating it to handle massive volume). We had to find a solution.

Thankfully, one of our closest advisors (and board members) came up with something brilliant: the Hackathon plan.

The concept is simple: You pay us $9.99 for one month. During that one month you get to test our system as much as you want (note: we’re going to cap calls with our max plan’s call limits). Want to push 20 million points into a layer and see how we handle it? Go ahead! Curious about how background location performs for 100,000 simultaneous users? Give us your best shot. The point is that we want to prove to you that we’ll be able to handle what you throw at us.

After one month, you’ll know where you fit our pricing model, and exactly how to tune your plan so you only spend what you need to.

More updates soon to come

So that’s quite a bit for now, but our next few months are chock full of big things. Looking forward to telling you all!

-Matt

Hiring a Designer and Front-End Engineer

Thu, 08 Apr 2010 18:39:00 -0600

We’re hiring for two new positions: A designer/creative director and a front-end engineer. Here’s the details:

Designer / Creative Director

Must live in or be willing to relocate to Boulder, CO
Must have at least 5+ years design experience
Can work as a one-man team
List of references, or portfolio
Experience with designing developer tools or a storefront a plus

Application Engineer

Must live in or be willing to relocate to Boulder, CO
Must have 1+ years of experience with Django/Python
Must have 3+ years of experience with JavaScript/HTML/CSS
Experience with Cassandra a plus
Experience with jQuery a plus
Experience with API development a plus

Email us if you’re interested! jobs [at] simplegeo [dot] com

Shoot us your portfolio or resume. Bonus points for code samples.

iPhone OS 4, Background Location and SimpleGeo

Thu, 08 Apr 2010 15:18:22 -0600

Thanks to GDGT for the photos of the keynote.

At SimpleGeo, we’ve been very excited for what Apple was going to announce today. There has been all kinds of speculation as to what features were going to go into iPhone OS 4, but now the rumors are over and there are some very big changes coming to the iPhone world. While most of the features were expected, Apple threw us a few nice curveballs.

The Expected Stuff

Unified inbox for mail
Multitasking - this one is big. Multitasking means app switching, music playing in the background, etc.
iBooks on the iPhone - this is in addition to a lot of other iPad features like custom backgrounds on the home screen, etc.

Totally Unexpected: Background Location

All of the Apple nerds at SimpleGeo Boulder were crowded around a single screen and when this announcement hit, we all jumped for joy. As part of the multitasking features Apple added, they introduced new background APIs that a developer could use to extend their app while it’s closed. These included: background audio, background VoIP and background location.

So what does it mean?

This means that any app that’s using geolocation as a feature, context, or anything else, will now be able to know where you’re moving even when the app’s closed.

Wow, that sounds scary!

Ok, it’s really not that bad. Imagine a To-Do app that would be able to tell you if you got within range of a grocery store, to remind you to buy some milk. How about a social network that told you when your friends were close without you ever having to open the app? There are a lot of possibilities and we’re really excited. Beyond that, Apple is adding more granular control over what apps can access your location and when.

As you can see by the granular control, if you really don’t want a particular app knowing where you’re at, at all times, you can turn it off. Great stuff.

How does this work with SimpleGeo?

I’m glad you asked that! This announcement really plays to our special sauce: being able to handle lots of very fast pings, and the queries that are coupled with them. Being able to do this is not easy. The current technologies available to developers to add location-aware features simply do not scale when you are pushing lots of writes into a database.

We built our technology in such a way that we’d be able to handle incredible simultaneous read and write volume. You can throw tons of data at us and our APIs will continue to stay snappy, allowing you to push as many pings as you want.

Location can make most any app better, simply by knowing the context of where someone is standing. Background location really opens up the possibilities.

GET.history

A few weeks ago we added a way to keep track of a record’s history in our Storage Engine. On the surface, this might not sound amazing, but coupled with Apple’s announcement of background location, this turns into one of our killer features.

Any time a developer updates a record in our database, we store the history of that record. So, if you have a record for a user, let’s say “johndoe1”, then any time the background location API sees johndoe1 move, that location can be updated in the app’s private SimpleGeo layer in the Storage Engine. We then store the history of that user over time, so you could effectively “play back” their location history.

You could use this to say “Hey, you’ve already been to this restaurant before, you should try the one next door!” There are just simply so many use cases.

Adding A New Model

We’re revisiting our pricing model, and one of the new pricing schemes that we will launch in the coming weeks will be a “per user” model where we keep track of X number of users, always allowing their location to be updated, and keeping a history. This is in contrast to our flat “X number of calls per month” structure.

While I can’t speak to when that will happen, I can say that we’re already having conversations about it.

In Closing

To say that we’re excited about Apple’s announcement is a big understatement. We think that location is going to be big (we’re kind of betting the farm on it), and that the updates to iPhone OS 4 will introduce a sea change in the way that we interact with location-aware apps.