Inspiration
TerraGIS: Project Story
Team Dupahar · Faculty Lead: Prof. Jatinder Manhas, University of Jammu · Entrepreneur Leads: Adil Mahajan, Tavishi Amla
GitHub: github.com/Dupahar · TerraGIS: terragis.co.in · Meru: trymeru.live
Inspiration
GIS sits at an odd crossroads. On paper, geospatial AI is one of the most well-funded corners of the industry, projected to grow into a ₹39 lakh crore market by 2034. In practice, it's also one of the places good ideas go to die. Gartner puts the failure rate of AI projects reaching production at 85 to 87%, and MIT's NANDA Initiative found that 95% of organizations deploying generative AI see zero measurable ROI. In geospatial workflows specifically, the odds get worse: coordinate systems misalign, topological rules break, and imagery pipelines choke on data volumes they were never built to handle.
What made this personal for us was the shape of the failure. It isn't a technology gap, it's a class gap. Teams that can afford ArcGIS get a powerful, production-grade tool locked behind a six-figure annual license and a proprietary format. Teams that can't afford it fall back to QGIS, free, but fragile enough that plugin conflicts and dependency collisions turn a one-machine prototype into an unreproducible mess the moment it needs to scale. Surveyors, small engineering firms, rural development projects, and student researchers, the people actually doing fieldwork, are stuck choosing between a platform that's too expensive to use and one that's too fragile to trust.
That's the gap TerraGIS set out to close: professional-grade spatial analysis and AI automation, without asking the user to be a GIS specialist or a six-figure budget holder to get there.
What It Does
TerraGIS is a unified civic-intelligence platform that turns raw geospatial data, drone imagery or standard GIS datasets, into actionable maps with minimal manual effort. A user loads imagery or vector/raster layers into the desktop client, and the platform's AI segmentation pipeline automatically identifies and extracts land features (buildings, roads, vegetation, boundaries), converting model outputs directly into usable polygons and layers.
For satellite-sourced imagery, TerraGIS pairs naturally with Meru, our infrastructure layer for Earth observation data. Instead of writing separate integrations for every satellite constellation, Meru unifies access behind a single API, so a TerraGIS user can pull current imagery for an area of interest and feed it straight into the segmentation pipeline without worrying about which provider the data actually came from.
The goal wasn't to build a simpler version of existing GIS tools, it was to rebuild the workflow around speed. Tasks that typically take a trained GIS analyst a couple of hours, digitizing features, running buffer or spatial analysis operations, exporting clean vector layers, collapse down to about 30 minutes:
$$ \frac{2\text{ hrs} - 0.5\text{ hrs}}{2\text{ hrs}} \times 100\% = 75\% \text{ reduction in task time} $$
No coding required, and it runs on standard hardware, not a GPU cluster or an enterprise cloud contract.
How We Built It
The architecture centers on a native desktop client, the interface surveyors and engineers actually work in, with layer management, basemap/satellite toggling, vector and raster import/export, and a spatial-analysis toolbox (buffer operations, layout export, and more) built directly into the main menu.
Behind that client sits a gRPC orchestrator that connects the desktop app to the AI backend. This is the piece that lets us keep the client lightweight while routing segmentation jobs to the AI pipeline on demand, rather than bundling model weights and inference directly into every install. The AI layer itself handles feature segmentation and automated mask-to-polygon conversion, so a raw segmentation mask from the model comes out the other end as a clean, editable vector layer rather than something the user has to hand-trace.
Imagery ingestion leans on Meru for the acquisition side: rather than building and maintaining bespoke connectors to each satellite provider, TerraGIS calls into Meru's unified API to source Earth observation imagery, then hands that imagery to its own segmentation and orchestration layer for processing. Building both pieces ourselves let us design the handoff between "get the imagery" and "extract something useful from it" as a single, low-friction pipeline instead of two disconnected tools.
On the product side, we structured TerraGIS into three tiers: Community (free, for students and hobbyists), Professional (₹40,000/year, AI segmentation capped at 100 calls/month for SME and consultant use), and Enterprise (₹1.6 to ₹4 lakh/year, unlimited AI operations, cloud deployment, and custom model training), so the tool that's too expensive for a small firm today doesn't have to stay that way as they grow into it.
Challenges We Faced
Making AI segmentation production-grade, not demo-grade. The 85 to 87% AI-project failure rate the industry reports isn't abstract when you're the one building the pipeline. A segmentation model that looks great on a clean sample tile and then falls apart on real, noisy imagery with inconsistent lighting and resolution is a very easy trap to fall into. Getting from "impressive demo" to something a surveyor could actually rely on in the field meant treating segmentation quality as a metric to optimize continuously, not a one-time check, tracking overlap between predicted and ground-truth masks using IoU,
$$ \text{IoU} = \frac{|A \cap B|}{|A \cup B|} $$
rather than eyeballing outputs.
Coordinate systems and topology. GIS punishes sloppiness in ways most software doesn't. A misaligned coordinate reference system or a broken topological rule doesn't just look wrong, it silently corrupts every downstream calculation. Building an AI pipeline that outputs geometry clean enough to trust for real spatial analysis, not just visually plausible polygons, took real iteration.
Wiring two systems together cleanly. Sourcing imagery through Meru and processing it through TerraGIS meant designing an interface between the two that could handle inconsistent tile sizes, projections, and metadata across satellite providers without pushing that mess onto the end user.
Desktop packaging and distribution. Because we wanted TerraGIS to run on standard machines rather than requiring a cloud subscription just to open the app, we went the native desktop route, which meant navigating MSIX/PWA packaging and store certification, a multi-stage process (submission, pre-processing, certification, publishing) with its own review timelines to plan around.
Staying cross-disciplinary. GIS isn't one field, it sits at the intersection of computer science, civil engineering, surveying, remote sensing, statistics, geography, and architecture. Keeping the product coherent meant constantly translating between how a developer thinks about a segmentation pipeline and how a field surveyor thinks about a property boundary.
What We Learned
The biggest lesson wasn't technical, it was about where AI projects actually fail. It's rarely the model. It's the last mile: packaging, reliability under real-world data, and a workflow simple enough that someone without a GIS background will actually adopt it. A tool that's 95% accurate but requires a specialist to operate loses to a tool that's 85% accurate and works the way its user already thinks.
Building Meru alongside TerraGIS also taught us the value of separating concerns cleanly: a unified data-access layer and an analysis layer are each easier to get right, and easier to trust, when they aren't tangled into one monolith.
We also came away with a much sharper sense of the market itself: where ArcGIS, QGIS, and India-specific players like MapmyIndia's IndiGIS and Genesys sit on the price-versus-power spectrum, and how much room exists for a platform that doesn't force organizations to pick a side of that trade-off.
Log in or sign up for Devpost to join the conversation.