Data
GIS
Location-aware software built by engineers who understand projections, spatial indexes, and the map — not just how to drop a pin.
Overview
GIS — Geographic Information Systems — is the discipline of capturing, storing, analysing and visualising data that is tied to a place. The moment location becomes a real dimension of your problem — where your assets are, which delivery goes on which van, which sites fall inside a catchment, how a field of crops is changing week to week — you are doing geospatial work, whether or not anyone has called it GIS. It sits on a small set of building blocks that repay understanding: spatial data types (points, lines and polygons for vector data; grids of pixels for raster), coordinate reference systems and the projections that flatten a round earth onto a flat screen, spatial indexing so a database can answer “what is near here” without scanning everything, and the spatial analysis — nearest, within, intersects, buffer, route — that turns raw coordinates into answers.
Yarqat’s angle is deliberately not to sell you a GIS product. We build custom, location-aware applications and the spatial data pipelines that feed them, most often on PostGIS — the geospatial extension to PostgreSQL — paired with open-source web mapping in the browser. That means your spatial data lives in the same database as the rest of your domain, queried with ordinary SQL plus spatial functions, and surfaced through libraries like Leaflet, Mapbox GL or OpenLayers rather than a licensed desktop suite that only a specialist can open. For a great many teams this is the right shape: the mapping is a feature of their product, not a separate department, and it should be owned by the same engineers who own everything else.
The honest framing matters here more than in most technologies, because “put a map on it” hides an enormous range of difficulty. Showing a single pin on an embedded map is trivial and needs almost none of this. Routing a fleet in real time across a road network, reconciling two datasets in different projections without silently shifting everything by a hundred metres, or serving vector tiles for a national dataset that stays fast under load — these are genuinely hard, and the failure modes are quiet. We are candid about where your problem actually sits on that spectrum, because the cost of over-building a mapping stack and the cost of under-building one are both real, and they are not symmetric.
Best for — Custom applications and data pipelines where location is a genuine part of the problem — tracking, routing, site and catchment analysis, mapping of property, land or utilities, and monitoring over time — built on PostGIS and open-source web mapping rather than a licensed GIS product.
Why teams choose GIS
Spatial data in your own database
With PostGIS your locations live alongside the rest of your domain in one PostgreSQL database, queried with ordinary SQL plus spatial functions and held under the same transactions and constraints. There is no separate GIS silo to keep in sync, and your engineers can work with geography without leaving the stack they already know.
Open stack, no per-seat licence
The core we build on — PostGIS, Leaflet or MapLibre, OpenLayers, QGIS for the analysts — is open source with no per-seat fees and no vendor holding your data. You own the pipeline end to end, you can run it anywhere, and you are not paying a licence that scales with every user who looks at a map.
Mapping as a product feature, not a department
Because the geospatial work sits inside your application, the map is something your product team owns and iterates on, not a specialist system bolted on the side. Location features ship on the same cadence as everything else, and the people who built them are the people who keep them running.
Why businesses choose GIS
- Your problem is genuinely spatial — proximity, containment, routing, coverage or change over time — and you want it answered in the database with real spatial queries, not approximated in application code that will be slow and subtly wrong.
- You want the mapping to be part of your product, owned by your team on an open stack, rather than a licensed GIS system that only a specialist can operate and that bills you per seat.
- You need the projection and data-quality work done properly by people who have made and fixed those mistakes before, because a CRS error or a bad join is the kind of bug that ships silently and is discovered by a user, not a test.
- You want someone blunt about scope — who will tell you when a map pin is enough, when PostGIS is the right home, and when your workflow honestly warrants ArcGIS — rather than a vendor whose answer is always more of their own product.
What we build with GIS
The capabilities this technology is genuinely strong at — and what we most often build with it.
PostGIS spatial database
The workhorse. PostGIS adds geometry and geography types, GiST spatial indexes, and hundreds of functions — ST_Distance, ST_Within, ST_Intersects, ST_Buffer, ST_DWithin and more — to PostgreSQL. Your spatial data sits with your relational data, and questions like “every asset within 5km of this depot” or “which sales region contains this point” become one indexed SQL query rather than a batch job.
Coordinate reference systems and projections
Getting the CRS right is where geospatial projects live or die. We store in the appropriate reference system (typically WGS84 / EPSG:4326 for storage, projected systems like British National Grid / EPSG:27700 for accurate distance and area), reproject deliberately with ST_Transform, and make the projection explicit everywhere — because an unlabelled coordinate is a bug waiting to happen.
Interactive web maps
We build the browser experience on the open mapping libraries — Leaflet and MapLibre GL for most products, OpenLayers or Mapbox GL where the analytical or vector-tile demands are heavier. Layers, popups, drawing tools, clustering for dense point sets, and click-to-query interactions, all rendered client-side with no plugin and no per-seat licence.
Vector tiles and GeoJSON delivery
How the data reaches the map matters as much as the map. Small datasets ship as GeoJSON; large ones are served as vector tiles (via pg_tileserv, Tegola or Martin) so only the geometry in view is sent, at the right level of detail. This is the difference between a map that stays responsive over a national dataset and one that stalls the browser.
Spatial queries and analysis
The analytical core: nearest-neighbour and within-distance lookups, point-in-polygon joins, intersections and overlays between layers, buffering and catchment generation, and — with pgRouting or a routing engine — shortest-path and delivery optimisation over a road network. This is the work that turns coordinates into decisions.
OGC standards and integration
Where you need to publish or consume standard services, we work with the OGC stack — WMS for rendered map images, WFS for feature data — typically via GeoServer, alongside GeoJSON and vector tiles for modern web clients. It means your data interoperates with QGIS, ArcGIS and third-party systems instead of being trapped in a bespoke format.
Use cases
Asset and fleet tracking
Real-time and historical location of vehicles, equipment or field staff — live positions on a map, movement histories, geofences that fire when an asset enters or leaves an area, and dashboards that answer “where is everything right now” and “where has it been”.
Logistics, routing and delivery optimisation
Planning and optimising routes over a real road network — sequencing drops, respecting time windows and capacities, and recomputing as conditions change — with pgRouting or a dedicated routing engine feeding a map and a driver-facing view.
Site, catchment and location analysis
Deciding where to put a store, depot or service — analysing catchments, drive-time isochrones, demographics within a boundary, and proximity to competitors or demand — so location decisions are made on spatial evidence rather than a hunch on a paper map.
Property, land, utilities and environmental monitoring
Mapping parcels, assets and networks (pipes, cables, poles) for property and utilities, and monitoring change over time for environmental and agricultural work — combining vector layers with raster imagery to track land use, crop health or coverage across seasons.
When GIS is the right choice
- Location is a first-class dimension of your product — you are tracking assets or vehicles, routing deliveries, analysing sites and catchments, mapping property, land or utilities, or monitoring an area over time. When the questions your users ask are inherently spatial (“what is nearest”, “what is inside this boundary”, “what has changed here”), a real geospatial stack earns its keep.
- You have spatial data that needs to be queried, not just displayed — joining points to polygons, finding everything within a distance or a drawn area, or intersecting layers. This is exactly what PostGIS and a spatial index are for, and doing it in application code instead is where teams quietly build something slow and wrong.
- You need spatial analysis over time or over large volumes — geofencing, movement histories, coverage and density, or environmental and agricultural change detection from raster imagery. These want a database and pipeline designed for it, not a spreadsheet with latitude and longitude columns.
- Wrong for: “show one pin on a map”. If your entire requirement is an embedded map with a marker or two — a contact page, a single store locator — a full GIS stack is overkill. An embedded map component and a geocoded address will do, and we will tell you so rather than sell you a spatial database you do not need.
- Wrong for: problems that only look spatial. A list of addresses that never gets queried by proximity, or data where the “where” is really just a category (region as a label, not a shape), does not need geospatial infrastructure. Postcode or region as an ordinary column is often the honest answer.
GIS: pros and cons
Strengths
- PostGIS is a mature, standards-compliant spatial database with hundreds of functions for distance, containment, intersection, buffering and more — you get serious geospatial capability inside PostgreSQL without adopting a separate GIS platform.
- The open-source web mapping ecosystem is excellent and free: Leaflet and MapLibre for lightweight interactive maps, Mapbox GL and OpenLayers for heavier vector-tile and analytical work, all rendering in any browser with no plugin.
- Open standards (OGC’s WMS and WFS, plus GeoJSON and vector tiles) mean your data and services interoperate — you can consume public datasets, publish your own, and swap components without being locked to one vendor’s formats.
- Spatial indexing (GiST in PostGIS) makes “what is near here” and “what is inside this shape” fast even over large datasets, so proximity and containment queries stay quick where naive application code would grind to a halt.
Trade-offs
- Spatial data is genuinely complex, and coordinate reference systems are the classic trap. Mixing projections — storing data in one CRS and querying in another, or assuming everything is WGS84 when it is not — silently shifts positions by metres to kilometres, and nothing throws an error. It has to be got right deliberately.
- Performance needs real work at scale. Large geometries, high row counts and complex overlays demand careful spatial indexing, geometry simplification, and often vector tiling — a national dataset served naively will be slow, and tuning it is engineering, not a setting.
- Good base data can be expensive or licence-restricted. High-quality address, road-network, boundary and imagery datasets often carry commercial licences (Ordnance Survey, HERE, some Mapbox tiers), and free data varies in coverage and accuracy — the data, not the software, is frequently the real cost.
- The proprietary alternative carries its own price. Esri’s ArcGIS is powerful and sometimes the right call, but it brings significant licence cost and lock-in versus the open stack. We are honest when a workflow genuinely wants ArcGIS — and honest when it is being bought out of habit.
Architecture
We put PostGIS at the centre and let it do the spatial work. Geometries are stored in a deliberate, documented coordinate reference system, with GiST indexes on the spatial columns and ordinary indexes on the attributes you filter by, because most real queries combine the two — “open work orders within this district” is a spatial predicate and a normal one together. The database answers the spatial questions; the application layer orchestrates and never tries to reimplement point-in-polygon or nearest-neighbour in code that will be slower and wrong at the edges.
Between the database and the browser sits a delivery layer chosen to fit the data volume. Small or slow-changing layers are served as GeoJSON straight from an API; large or dense ones go through a vector-tile server (pg_tileserv, Martin or Tegola) so the client only ever fetches the geometry in view, generalised appropriately for the zoom level. On the client, an open mapping library renders the layers and handles interaction, and heavy analysis stays server-side. Where standards-based interoperability is required, GeoServer publishes WMS and WFS alongside the tiles. The result is a stack where each piece has one job and the spatial complexity is concentrated where it belongs.
Performance
Geospatial performance is mostly won or lost on three things: indexing, geometry size, and how much data you send to the browser. We build spatial indexes from the start and check they are actually used with EXPLAIN ANALYZE, because a missing GiST index turns a proximity query into a full-table scan over geometry — the single most common cause of a slow map. We simplify and generalise geometries for display so a coastline drawn at national zoom is not shipping every survey-grade vertex, and we use ST_DWithin rather than computing and filtering distances by hand, because it can use the index where a raw distance calculation cannot.
On the delivery side, the discipline is to never send more than the view needs. Vector tiles cap the data per request and per zoom level; clustering collapses dense point sets so the browser is not asked to draw fifty thousand markers; and expensive analytical layers are precomputed or materialised rather than recalculated on every pan. We measure against realistic data volumes — a map that is instant over a thousand demo rows and unusable over a million real ones is a trap we design out early, not discover in production.
Security
Location data is frequently sensitive — the positions of people, vehicles, assets and customers — and we treat it that way. Access is enforced in the database with least-privilege roles and, where the model calls for it, row-level security so a tenant or a user can only ever query the geometries they are entitled to see. Spatial APIs are authorised on the server; we do not rely on the map front-end to “not request” data it should not have, because anything the browser can ask for, a determined user can ask for directly.
The rest is the ordinary discipline done properly: parameterised queries throughout (spatial parameters included), TLS in transit and encryption at rest, secrets and third-party map or routing API keys kept out of client code and out of the repository, and proxying of paid tile and geocoding services so keys are not exposed and usage stays controlled. Where location history is retained, we are deliberate about retention and minimisation — keeping precise movement data longer than the purpose requires is a liability, and we design that decision in rather than defaulting to “keep everything”.
Scalability
For most systems, a well-indexed PostGIS on capable hardware scales further than expected, and the honest scaling levers are the same as for any Postgres: read replicas for query-heavy reporting and map traffic, partitioning of very large tables (movement histories partitioned by time are a common and effective pattern), and moving heavy analytical scans off the transactional primary. Spatial workloads add one more: precomputation. Catchments, tiles and aggregate layers that are expensive to derive are built ahead of time and served cheaply, rather than recomputed per request.
The parts that genuinely stress a geospatial system are high-frequency ingest and large raster or imagery workloads. Thousands of GPS pings a second want a write path designed for it — batching, appropriate indexing, and a retention and roll-up strategy so the table does not grow without bound. Large raster and satellite imagery is a different scaling problem again, often better handled with cloud-optimised formats and object storage than by pushing everything through the database. We are straight about which of these you actually have: most tracking and mapping products never leave the comfortable single-primary-plus-replicas range, and we would rather tell you that than architect for a scale you will not reach.
GIS integrations & ecosystem
The technologies we most often pair with it — each links to how we work with it.
How we work
We start by pinning down where your problem sits on the spatial spectrum, because that decision governs everything downstream. Is this a map pin, or is it real spatial analysis? What coordinate reference systems does your data arrive in, and what accuracy do the answers actually need? What base data do you require, and what does it cost or licence? Getting these settled first is cheap; discovering halfway through that every coordinate is in the wrong projection, or that the address dataset you assumed was free is not, is not. We would rather have the awkward scoping conversation up front than bill you for the consequences of skipping it.
From there we build the spatial model deliberately — the right CRS, the right geometry types, the indexes chosen against the queries you will actually run — and layer the delivery and map on top. The engineers who design the spatial schema are the ones who tune the queries and keep the map fast, which is what we mean by operating what we build. And we stay honest about the open-versus-proprietary choice throughout: we default to the PostGIS and open-mapping stack because it fits most products best, but where a workflow genuinely wants ArcGIS or a paid data provider, we will say so plainly rather than force an open tool to do a job it is poor at.
The service behind it
Delivered throughData EngineeringWhat we build with GIS
The disciplines this technology most often shows up in — from a first build to taking over and stabilising an existing one.
How we deliver
- 01
Discover
We map the system, the constraints and the business it serves — including the parts nobody documented.
Architecture brief
- 02
Architect
Decisions get made, written down and defended before a line of production code exists.
Decision records
- 03
Build
Short cycles against working software. You see progress in the product, not in a status deck.
Shipping increments
- 04
Operate
Monitoring, incident response and iteration. The system is alive, so the engagement is too.
Runbooks & SLOs
Industries we use GIS in
Domain knowledge changes what gets built. A few of the sectors we know before the first meeting.
Also in Data
Why teams choose us for GIS
Senior engineers who know the traps
Geospatial has a specific set of expensive, silent mistakes — projection errors, unindexed spatial queries, unbounded movement tables — and they are made by people meeting them for the first time. The engineers on your project have made and fixed these before, so they are designed out rather than discovered by a user standing in the wrong place on a map.
We operate what we build
We run the location-aware systems we design, so we build for the on-call reality: indexed queries that stay fast at real volume, tile delivery that does not stall the browser, retention that keeps movement data from growing without bound. You get a map that stays quick and correct under real traffic, not just over a demo dataset.
Honest about scope and stack
We will tell you when your requirement is a map pin and a spatial database would be waste, when PostGIS is the right home, and when a workflow genuinely warrants ArcGIS or a paid data provider. Our answer is not always more geospatial software — it is the right amount for the problem you actually have.
Open stack, your ownership
We default to PostGIS and open mapping so you own the pipeline end to end, with no per-seat licence and no vendor holding your spatial data. Where a commercial component genuinely earns its place, we say so — but the baseline is a stack you control and can run anywhere.
Typical timeline
- 01
Discovery and spatial scoping
One to two weeks establishing where the problem sits — map pin versus real analysis — the coordinate reference systems in play, the base data required and its licensing, and the accuracy the answers genuinely need, so the foundations are settled before anything is built.
- 02
Spatial model and pipeline
Designing the PostGIS schema with the right geometry types and CRS, building the ingest and transformation pipeline, reprojecting and cleaning source data, and putting the spatial indexes in place against the queries the product will actually run.
- 03
Maps, queries and delivery
Building the interactive maps on the open libraries, wiring the spatial queries and analysis, and choosing the delivery mechanism — GeoJSON or vector tiles — sized to the data volume so the map stays fast under real load.
- 04
Tuning, hardening and handover
Profiling spatial queries against realistic volumes, tuning indexes and tile generation, securing the spatial APIs and any paid keys, and documenting the projections, data sources and model so your team can own and extend it.
How pricing works
- Fixed-scope engagements for well-defined geospatial work — a spatial data model and PostGIS build, a mapping feature added to an existing product, or a one-off analysis or data pipeline — quoted once we understand the data, the projections, and the accuracy required.
- Monthly senior engagement for ongoing product work where location is a core feature that evolves with the application, and you want continuity of the people who understand your spatial model and your map.
- Focused audits and rescues for geospatial systems that are slow, drifting or wrong — misprojected data, unindexed spatial queries, a map that stalls at real volume, or a licensing bill that needs a hard look — priced by the assessment.
Hire GIS engineers
Need GIS capacity on your own team? We embed named senior engineers into your existing team — reporting to your leads, working in your rituals — so you add capacity without a hiring cycle.
Hire GIS engineersCommon questions
Do we need a full GIS stack, or is an embedded map enough?
It depends entirely on whether your problem is genuinely spatial. If all you need is to show a location or two — a store on a contact page, a marker for an event — an embedded map component and a geocoded address will do, and standing up PostGIS would be waste. You need a real geospatial stack when the questions are spatial: what is nearest, what is inside this boundary, how do I route across this network, what has changed in this area over time. We will tell you honestly which side of that line you are on before you spend anything.
Why PostGIS rather than Esri ArcGIS?
For most products where mapping is a feature rather than the whole business, PostGIS is the better fit: your spatial data lives in the same PostgreSQL database as everything else, queried in SQL by the engineers who own the rest of the stack, with no per-seat licence. ArcGIS is genuinely powerful and sometimes the right call — for heavy desktop analysis, specialised cartography, or an organisation already built around it — but it carries significant licence cost and lock-in. We default to the open stack because it suits most work best, and we are straight with you when a workflow honestly warrants ArcGIS instead of pretending otherwise.
What is a coordinate reference system, and why does it keep coming up?
A coordinate reference system defines how a position on the round earth is expressed as numbers — latitude and longitude in WGS84 (EPSG:4326) for storage, or a projected grid like British National Grid (EPSG:27700) for accurate distances and areas. It keeps coming up because getting it wrong is the classic geospatial disaster: store data in one system and query it as another, or assume everything is WGS84 when it is not, and every position silently shifts by metres to kilometres with no error raised. We make the CRS explicit everywhere and reproject deliberately, because an unlabelled coordinate is a bug that ships quietly.
Can this handle real-time tracking of a large fleet?
Yes, with a write path designed for it. High-frequency GPS ingest — thousands of pings a second — is one of the few things that genuinely stresses a geospatial system, so we design for it: batching writes, indexing the movement table appropriately, partitioning history by time so it does not grow without bound, and setting a retention and roll-up strategy up front. Live positions, geofences and movement histories on a map are well within reach on PostGIS with this in place. The mistake to avoid is naively inserting every ping into one ever-growing, under-indexed table, which works in a demo and falls over in production.
Why is good map data sometimes expensive, and can we avoid it?
The software in a geospatial stack is largely free, but the base data often is not — high-quality address, road-network, boundary and imagery datasets frequently carry commercial licences (Ordnance Survey, HERE, certain Mapbox tiers), because someone had to survey and maintain them. Free and open data (OpenStreetMap, public boundary datasets) is excellent for many uses but varies in coverage and accuracy, and its licence terms need reading. We assess early which datasets your accuracy requirements actually demand, whether open data will do, and what any paid data will cost — so the data budget is a decision you make deliberately, not a surprise partway through.
Building on GIS?
A technical conversation with the engineers who would do the work. If we are not the right fit, we will say so on the call.