Geo-spatial search or geo-search is no longer a buzz word or a nice to have in your service or app. If you take a look on the AppStore / PlayStore, more than half of the apps will ask your permission for location.

And here’s why.

Location matters

According to Google’s 2011 “The Mobile Movement Study”, 77% of smartphone users use their smartphone for search.

When it comes to location, things are getting even more interesting. 95% of smartphone users have looked for local information. After finding the information:

• 77% contacted the business after — 61% called and 59% visited the location
• 44% made a purchase, 26% being online and 36% in the store

Within a day, 88% would take an action (visit the place, buy, call, etc.)

Location matters! And not only for buying food or dining but for the way we interact with friends and even strangers. Apps for dating, transportation, social networks and media all leverage location for better content.

Do all those apps really need our location for their services? Maybe not, and I am not suggesting we all start draining the battery and fetching the location without purpose, especially with GDPR in Europe. Rather, I am suggesting to devs developing apps to think twice about whether they could improve their search by taking location into consideration.

Hopefully, by this point I convinced you that location matters. Let’s see in the next parts how to build geo-search interfaces leveraging user’s location for better mobile experiences.

My use case

Before joining Algolia, I tried my luck and built several startups. One of those startup’s goals was to imagine a new way of interacting with people: putting more emotions into the photos or videos we are taking, and, like Hansel And Gretel, leaving a trace of our moments all over the world.

The use case was simple: take a picture or video. Instead of sending it to your friends, leave it in the same physical place you took it. The message could be public and hence seen by anyone around the place, or private, visible to selected friends.

As an example, let’s say you are in a bar and took some very cool selfies (or at least that’s what you thought after those five beers). You open the app and post them, so now, everyone around that bar can see your awesome selfies. When your friend, George, who skipped this Friday’s beers comes around next time, he can see how happy you were.

Choosing the dev stack

As the tech person in the startup, I was responsible for building an MVP (Minimum Viable Product), which was an iOS app. My use case was simple: being able to search for messages around a geo-location; given latitude / longitude and a radius, show the messages around the place in question.

So, I started a Google search for the following terms: geo-search database, geolocation databases, geospatial database. There weren’t many options popping up, but I did find a couple of solutions: MySQL would work, and PostGIS was a more powerful solution.

Since I had some experience with Firebase, I learned that I could use GeoFire on top of it, which allows to store and query a set of keys based on their geographic location. In case you know nothing about Firebase, it is basically a backend as a service. They have a lot of cool stuff integrated, like authentication, realtime database, storage and so on. In a nutshell, for every message sent, I would save an ID and its location with GeoFire.

With this in mind, and the fact that I was building an MVP, using Firebase + GeoFire was much faster than building an entire back end with PostGIS.

Firebase and GeoFire

At its heart, GeoFire stores locations with string keys. Its main benefit, however, is the possibility of querying keys within a given geographic area. GeoFire stores data in its own format and its own location within your Firebase database.

So, in my case, for every message I would store in Firebase, GeoFire would store another object containing the ID of the message and its coordinates.

For our app, every time the user was opening the app or moving around, we would fetch his location and start a search. Given the latitude, longitude and a radius, we would listen to each of the messages that was in that area. Because Firebase is implemented as an Observable, each message would come one by one, every time matching the query. So, in the end, we would have a list of messages IDs with their specific location.

Firebase + Geofire limitations

Even though Firebase is super fast and reliable, we encountered some limitations with GeoFire.

Displaying rich messages on a map or list

GeoFire will only store the ID of a message and its coordinates; you cannot store any other metadata. When displaying your data on a map you will then have to:

• Get all the messages and coordinates in a single request
• Make other requests to Firebase to get the other metadata, like title, image url…

This approach might be OK when you have 5-10 messages around you, but when you have hundreds, it will kill your network.

Filtering

One of the biggest pain points was filtering. On the map, you can see public messages and messages from your friends. Since GeoFire does not support any kind of filtering, we had to filter the results on the client side. If a user only wants to see messages from her friends, we would have to download all the messages around and filter out the ones that are public. Since the ratio was 1 to 100, we were downloading 99 messages for nothing.

Only latitude and longitude queries

One of our use cases was to show only messages around a certain area. Let’s say you only want to see the messages at your school and nothing more —queries in a polygon were out of question.

To sum it up, Firebase + GeoFire can be a very useful and quick solution to your geo-spatial search problem. You might have some limitations, but overall, it works.

Algolia and geo-search

Less than three months ago I started working at Algolia, on the mobile team. My ramp-up project was developing an Airbnb-like search experience using Algolia’s geo features (here’s the code) which would display available rooms around you, on a map:

I start reading the documentation and dove into the features — to be completely taken by surprise. Where was this when I needed it eight months ago?

Here’s what I found out, compared to the limitations I encountered with GeoFire.

Displaying rich messages on a map or list

After indexing your object and in order to search based on a location, all you need is to add a field _geoloc with given latitude and longitude. That’s it!

So, when querying for objects around a location, you will get the entire object. This means that, when displaying it on the map, you can leverage all the attributes of the object. For my use case, I could have, for example, displayed the image and name of the person who left a message.

Of course, keep in mind your customer. Downloading large datasets will impact the speed and network consumption. To offer the best experience, you could:

• limit the amount of results you are displaying at each iteration
• use attributesToRetrieve to get only the attributes you are interested in. This is very helpful when your object contains attributes that are not useful in your search context

In my case, I would limit the attributes to only the location, the user’s image URL and his name. Anything else, like the content of the message, comments, and so on, would be lazy-loaded if needed.

Filtering

Filtering was my biggest pain point with GeoFire. Not being able to search for specific type of messages was almost a deal-breaker. With Algolia’s system, the location is only one of the ways you can filter. You can add additional filters like whether the message is public or private, if it is a video or image, and so on.

So, instead of downloading 100 messages for only one relevant message, I was able to only fetch what was truly relevant.

Limit the result set

This feature applies to Algolia’s search in general: you can set up the limit and download batches of that limit: check out infinite scrolling.

Not only latitude and longitude queries

In some cases you need more than just results around a position. Maybe you want to display results in a certain area. Instead of using the latitude and longitude you can define a rectangle or a polygon. This way your results are bound to that region.

Other features worth mentioning

Multiple locations for the same object

You can add a list of locations for the same object. If it makes sense for your use case, instead of replicating the same object, add the locations where the object is available.

Automatic radius

Automatic radius is very useful when displaying results in areas that have too many results or too few.

By default, Algolia will expand the search radius around the specified latitude and longitude until approximately 1000 hits are found. If the area is dense, the radius will be smaller. If it’s not dense, the radius will be bigger. The benefit of this feature is that it increases the chance of finding more results in low density areas. If a fixed radius is set, there could be fewer/no results returned.

Results around user’s IP address

Sometimes the GPS is not an option. Maybe the user blocked the access or it is just not working. You can always fall back to displaying results based on their IP address. Algolia will associate a location based on the user’s IP address and search around that location. Here’s how.

Conclusion

Whether you are working on the next big thing or want to improve your product, keep an open mind about the user’s location.

The goal of this article was to:

• make you aware of the importance of geo-search
• since Firebase and GeoFire was the top suggestion I got when looking for a solution, I wanted to give you an overview of features and tradeoffs
• present Algolia’s approach when tackling geo-search

By the way, in case you didn’t know, Algolia and Firebase play nicely together. In case you have geo-aware data in Firebase, you can sync it to Algolia to get these more advanced geo-search features.

Have you played with geo search? Have cool tips or feedback on this article? We want to hear it: @robertmogos, @algolia.