Location Based Geospatial Technology... Buy or Build the Quandary

The Problem.

I am under pressure to deliver location based data to my business. I want to build because that’s what I understand but if we do I risk taking the hit if or when we fail. There is no answer to the question but this document may help you understand what you may be getting involved in before you make the decision. To buy or build? Here is a handy little pocket calculator that will help you through this maze:


The Solution.

Developing GIS Applications

MAPCITE Enterprise has been developed over 5 years by a team of developers with significant prior experience of geospatial development (50 years plus in developing new and bleeding edge location based technology). The key differentiator for MAPCITE is that it provides a simple user interface, designed for the non-technical user, yet enables the user to undertake analysis and visualisations that would be complex for a GI professional, using traditional GIS tools. This is an extremely important differentiator to any existing or new player developing technology in this area i.e. the technology has to be able to handle vast quantities of data, perform exceedingly complex calculations and be as easy to use as Excel and Word. In summary, MAPCITE has succeeded because it has created a generalised solution, abstracted away from any one specific use case and has hidden that complexity from the user.

Challenges in designing and building Geospatial Systems…The yes or no questions.

If you need to build a bespoke solution to meet your needs there are a number of important things to consider:

First Time Nerves

How many times have we built a prototype as a proof of concept (PoC), just to prove we can do it and help us decide how to build the “production version”?

When we have built such a PoC business priorities mean we continually have to keep tweaking the prototype to show the business new features and in reality building the “go to market product” is always a big step away. Even then, when you were ready to start building it “for real”, the business thought it was already built, because they had seen it.

Pins on a Map – That’s easy

Many early use cases for Location simply involved putting pins on a map. As such, there are lots of code samples to show you how to do it and it looks simple. In essence it is. However, in this very first building block of geospatial we need to consider what attributes could and should be associated with the pin. This is where things start to get dirty and the waters muddy:

  • Where do I put the data, especially if it is of sensitive nature?
  • How can I see attributes about the data and how does this relate to other pins and its associated data, is it contextually relevant?
  • What happens if you have lots of pins, let’s say for example 1 million pins with a billion transactions within the UK and the users want to see everything?
  • How do I cope with overlapping pins especially if the numbers are big?

Visualising the Data on the Map (Scale and Performance with Heatmaps and Choropleths)

Once you have pins on a map, there are often other ways you may need to present the data to help a user make sense of it. Heatmaps and Choropleths are well known techniques to present the data. These techniques are often optimised for specific datasets. However, you may find that what works well for one dataset may not work well for another. There are a number of things to consider when building these visualisations:

  • How can you scale your technique to handle 10 pins to 100 million pins?
  • How can you colour a heatmap or choropleth when the values in one dataset may go from 0.01 to 1.0 and another dataset from 1.0 to 1,000,000?
  • How can you calculate the sum of the pin values within a choropleth visualisation in real time across 1 million rows of data, for concurrent users within a timeframe they are prepared to wait for the results?

“Health Warning” Approaches taken to create these sorts of visualisations with low volumes of data do not scale well with large numbers of data points.


Increasingly, organisations want to be able to leverage multiple spatial datasets and look at the interactions between them. For instance, as a simple example, a user might want to ask “How many pins in dataset 1 are within 50 metres of pins in dataset 2?”

This could be customer locations in a shopping mall, compared to a store location. Whilst for a fixed calculation and access to the relevant technology this is a linear transaction. However, the answer to the questions usually results in another question – “How many exist within 100 metres? What about Fridays compared to Wednesdays?” Building this level of flexibility into an analytics tool is not trivial and is difficult to justify if the business can only articulate one query at the outset. However, the more data that is available in the system, will invite many more queries that will require significant levels of support to address.


Geofencing is becoming increasingly important for many businesses as they look at identifying the intersections between a dataset and a defined area in real time. This is a complex issue for many reasons:

  • Geofences are often not static and we need to be able to change them easily without making software changes
  • Geofences are held in differing formats in the browser and database and so shape editing, storage and manipulation become a technical challenge
  • Large numbers of shapes and pins also create significant scalability issues if undertaken in real time, requiring specific optimisation.

The above just deals with traditional static geofencing i.e. around a building. However, what about mobile dynamic geofencing on the mobile device itself, designed so that the user’s data continually updates as they move around.

Data Driven Mobile

Writing mobile applications has become a commodity service available from many sources. However, most applications are bespoke and so if a business requirement changes or the underlying data structure changes, a new version of application is required.

Mapcite has built its mobile application as a data driven, server side configured application. This means:

  • You can change the datasets
  • You can have one or multiple datasets
  • You can add/remove datasets
  • You can change the format of the datasets

None of these requires a change to the application.