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.

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.

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!

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.

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.

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.

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.

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

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.

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.