Smart Polygons: Shaping a More Intelligent Location

By Victor Quinn  |  July 23, 2015

This entry was posted in LocationKit, Technical tagged

While there are many great reasons to adopt our LocationKit SDK for iOS and Android in your geolocation app, one of my favorites to discuss is our extensive Venue Database.

We have put together what we think is the most extensive venue database for any location API on the market which we use to intelligently refine user location using LocationKit

Polygons, not points

The greatest difference between our database and the competition is that our database contains polygons for each address whereas most others use points to represent a location. What does that mean?

In a traditional setup, each venue is represented by a single “pin” which is often attempted to be the center of mass of a particular address or building. It would be a single latitude/longitude for that place.

For example, in the following screenshot from Google Maps, the “pin” for Crios near Dupont Circle in Washington, D.C. is in the center of the map:

Screen Shot 2015-07-13 at 1.09.24 PM

So what’s wrong with this, you may ask? Well, when trying to determine the location of a user, lots.

Problems with a single point

Using a single point like this to represent a venue makes a lot of things easier. It makes the database storage easier (storing two floats for latitude and longitude is far easier that storing all of the latitude/longitudes for a polygon, particularly in a traditional relational database) and makes finding the location of the user less computationally intensive (easier to compute closest point than to compute point within polygon).

Unfortunately, it also introduces a lot of errors.

For example, using our map above, let’s say you’re in the corner of Crios taking in a delicious craft beer with some tacos. I’ve updated our map above with an arrow to show where the user is enjoying his tasty beverage.


In the traditional, naïve approach with a single latitude/longitude point representing the venue, most databases would take the latitude/longitude of the user, find the closest single latitude/longitude “pin” to that user, and report that as the venue the user is currently in. I’ve updated our map with lines from our current location to the pin for Crios and from our current location to the pin for its neighbor, Amicable:


In this example, it would likely report that the user is in Amicable, which is next door, since that point will be closer than Crios to the user’s current location.

However, this is dead wrong!

SocialRadar’s solution – polygons

Enter our proprietary database which has polygons for each address. Below is a screenshot from our internal diagnostics tool which overlays the polygons from our database on a map.


Now you can see that when we get a point in the corner of Crios, since we have the full polygon for the building, we can surely tell you’re in Crios and not next door at Amicable because we can tell that your point falls within the polygon for Crios, not its neighbor.

In fact, when we look at the data from the raw location data gathered from your phone, we can tell that you were walking East on P Street NW, turned left, entered the Crios building polygon, and then moved around within Crios. This allows us to give much higher accuracy data than just a single point representing that location.

Buildings and parcels

An astute reader may notice there are two different shades of purple marking polygons on our map: dark and light (there are other items on the map which I may explain in another post). This is another enhancement our database has over others.

We have multiple types of polygons in our database. The majority of our polygons represent the land parcels on which each address sits, but sometimes this alone is not enough to tell where a user likely is, particularly in a densely populated urban environment. So, for most major cities in the United States, we also have data in our database for the polygon outlining the physical structure of the building sitting on that land.

This allows us to tell not only which parcel of land you are in but which building on that land you are in. We intelligently use a combination of that building and that land parcel to figure out with a high degree of accuracy where that user actually is.

Other items

In addition to the hundreds of millions of polygons we have for the buildings and parcels, our proprietary venue database also has information on the following:

  • Over one hundred million addresses
  • Over ten million venues
  • Tens of thousands of events occurring daily at those places
  • About half a billion road segments
  • Over half a billion relationships between those addresses, polygons, events, and venues


We have put together what we think is best location-based database on the market and we use all of this data intelligently in LocationKit to provide information on where your users are.

We’ve done the complex work of not only gathering all of this data but also delivering it seamlessly from our servers via our LocationKit SDK to your app so your app can simply be notified that “this user is currently at Nationals Park where Taylor Swift is performing” and your app can work its magic to make a killer experience for your users.

Here at SocialRadar, we are location experts. By using our free LocationKit SDK, you get all the location expertise of our team without having to maintain your own in-house team to specialize in location. This allows you to focus on what you do best — building amazing apps. You won’t have to worry that your app is displaying the wrong location information to your users.

Sign up for LocationKit to get started today!


Victor Quinn is VP of engineering and a software architect that specializes in creating amazing Android and iOS SDKs focused on geolocation apps, location accuracy, and reducing battery drain on mobile devices.


No comments yet.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">