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
closeup photography of clear glass window closed

Observations • Darren Wiens

How to use SVG Filters on Web Maps

Here at Sparkgeo, while we often prefer to provide answers over visualizations, we still make a lot of web maps. And when we do, we take pride in…

blue coupe in front of pink house

Observations • Darren Wiens

Python-based Computer Vision in the Browser

Prototyping and Python are big parts of what I do at Sparkgeo, so when PyScript was announced at PyCon US 2022, I was all ears. PyScript, along with…

Observations • Gordon Logie

Wildfires and Flood Damage

A data-backed research project examining linkages between the wildfires and subsequent flood damages that occurred in BC, 2021.

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