Open Source geospatial is a discussion that regularly incites near-religious debates. Sides form espousing the benefits and costs of different approaches: open, proprietary or other. Battles are fought over features, files and product names. Geospatial technologies have made the careers of many, and in no uncertain terms, billions of dollars are at sway in these discussions. We should not underestimate the passionate intensity of these debates.

Unfortunately, in these wars of opinion, the end-user is usually collateral damage. How ironic that we so often forget about the final consumer of our products as we argue over the ingredients we use to prepare our creations.

At Sparkgeo, we have often described ourselves as “vendor-agnostic,” hinting at the zealotry we see associated with simple technology choice. We’ve used this description for years, but again it is too technology-focused. A better story would be “user-centred.”

Let’s think through a typical example:

A client might come to us and ask:

Can you make me an app that does a geospatial thing?”

Typically, they have spent a significant sum of money on a software licence or some customized open source development. Would it make sense to recommend an alternative path out-of-hand because we have a bias?

No. Perhaps with some probing, we might come to that conclusion for sound business reasons. But we would do so in collaboration with the client with their full knowledge of the costs and benefits.

Even though we would lose out on any referral fees, it would break our philosophy to recommend technology that we did not feel would be the most appropriate for the client in a given situation.

“Just because” answers are dangerous because they are technology-centred, not user-centred.

What does this mean in practical terms?

If you come to Sparkgeo, we will provide honest advice on geospatial technology:

  • We use our Maptiks technology to help us understand how different web mapping environments perform in different markets: data-driven advice.
  • We have numerous options for different serving environments, where context and scale matter.
  • We can develop algorithmic pipelines to make geospatial things happen at scale.
  • If you need help with wiring up an ArcGIS toolbar, we can do that.
  • If you need to customize a Mapbox map-style, that’s no problem.
  • If you need support for your Geoserver product, we can do that too.

But that is all secondary because it is not about technology. It is about people and problems. The first thing we do is focus on that problem, then we deliver our advice with an ability to back our words up with code.

Sharing options

Observations • Will Cadell

Strategic Geospatial

Making a map may be a daily activity for many, but thinking about why we do something and whether that activity is fit for purpose differentiates those who are thinking…

Observations • Brian Bancroft

Build a React MapboxGL Component with Hooks

Using React Hooks to build a Mapbox GL React Function Component.

Observations • Darren Wiens

Maps in Slack using quick-map

Open Source geospatial is a discussion that regularly incites near-religious debates. Sides form espousing the benefits and costs of different approaches: open, proprietary or other. Battles are fought over features,…

Need a geospatial partner?

Our team complements organizations like yours—by providing on-tap access to geospatial, analytics, and mapping expertise.

Let’s talk

Join our team?

We’re always looking for skilled technologists to help us build the future of geospatial. Got a minute to find out more about us?

Working Here

Sharing options