How is geomatching different from geofencing?

What is the difference between geomatching and geofencing? Benoît Garbinato describes the similarities and the differences between the two concepts in this post. Benoît also discusses a couple of examples of how you can use geomatching in real life scenarios.

How is geomatching different from geofencing?

The use of geofencing is becoming increasingly common in location-based services. In a nutshell, a geofence is a virtual zone associated to a real-world geospatial area that can trigger some processing when a device enters or exits that area. Typical applications of geofencing include triggering an alert when a certain piece of equipment leaves a building, pushing a contextual advertisement when entering a certain shopping area, or notifing parents when their child leaves a given area.

Now, although a first valuable step towards providing adequate support to build location-based and proximity-aware application, geofencing has several shortcomings.

First, a geofence cannot move. While this restriction makes perfect sense to detect the proximity of a building or of a landmark, it falls short to detect the proximity between people, vehicles or whatever moving entity you might think of.

Second, a geofence is only concerned with the geospatial dimension and as a consequence merely offers a binary form of discrimination: either a device is inside the geofence or outside. However, in many cases, additional criteria are needed to decide whether a certain action should be triggered or not. In the case of contextual advertisement for instance, one might want to further discriminate who will receive a given offer based on her or his profile.

To address those shortcomings, we at Matchmore are introducing the notion of geomatching, which can be seen as a smart version of geofencing. In Matchmore, geomatching is implemented as an extension of the publish–subscribe messaging pattern.

In its orignal form, this messaging pattern allows a software agent to publish some content on a topic, while another agent subscribes to that topic and provides an optional content filter to only receive content that matches its interest. This model is said to be anonymous and asynchronous because publishers and subscribers do not need to know each other, nor do they need to synchronize for the communication to happen. In this sense, publish-subscribe is intrinsically an push communication model.

Coming back to geomachting, we extend the publish-subscribe messaging pattern with the ability to filter information not only based on content but also on context: each publication (subscription) is valid for a given duration and within a certain geospatial area, which can move with the publication (subscription) if the corresponding device moves. When a matching publication and subscription have their areas touch each other, a match occurs and the subscriber receives the information.

In its current version, our implementation of geomatching supports three types of devices: smartphones (iOS or Android), beacons and pins, the latter being virtual devices that simply represent fixed geospatial coordinates. In the future, we will add more types of physical devices, making geomatching a messaging pattern of choice for applications wanting to exploit the full potentional of the Internet of Things (IoT). We will come back to this subject in a future blog entry.

We will also soon support moving virtual devices, which will make it very easy to create augmented reality games mixing real physical players and virtual creatures for instance. This new feature will also greatly facilitate the testing of location-based and proximity-aware applications. If you are interested in our service, you can try Matchmore for free here.

To illustrate, how geomatching can be used to effortlessly build promixity-aware applications with a rich semantics, consider the two scenarios illustrated hereafter.


In Scenario 1, geomatching is used in a dating application. Here the developer simply creates publications based on user profiles ①+② and subscriptions based on their dating preferences ③.

In Scenario 2, a person visiting Rome is using an application provided by the tourism office. This application relies on geomatching to find information about monuments and parks close-by. To achieve this, the developer simply attaches publications to geospatial coordinates (a pin) ④ and to physical beacons ⑤, and corresponding subscriptions to smartphones running his application ⑥. He also attaches publications to phones ⑦ and a corresponding subscription to the beacon ⑧, allowing the tourist office to know how many visitors came by.

As illustrated above, geomatching takes care of all the complexity related to attaching context information to any connected object, to tracking such objects in real-time relatively to each other, and to finding and retrieving this information when it is needed by the context-aware mobile application. This complexity being out of the way, developers can focus on what makes their applications unique and quickly and easily test new ideas.

At Matchmore, we advocate that once you grasped the power of geomatching, the tracking and matching of people, products and services, as done in Tinder, Uber or Pokémon Go applications, can be coded in your application in 30 minutes, literally. This then leaves you the time to focus on other important aspects of your applications.

You want to try it for yourself? Then read our blog entry on how to create your first proximity-based application with geomatching and give it a try!