Why We Built MapAI: The GIS Bottleneck We Kept Running Into

The clearest version of why we built MapAI is a moment that happened before we started building it. I was running a GIS analysis for a logistics project, producing catchment maps for a series of potential depot locations. Straightforward work: buffer around each site, pull in some demographic and infrastructure layers, produce the map outputs for the commercial team.

While I was running the analysis, the commercial director sent me a follow-up question: "Can we also see which of those catchments overlap with the residential growth corridors in the northwest?" It was a completely natural and intelligent question. It would have added fifteen minutes to my work and changed the output significantly.

She asked the question at 3pm on a Wednesday. I was in a meeting until 5, picked up the message, ran the additional layer that evening, and sent the updated maps the following morning. By then she had presented to the board using the original outputs and her follow-up question had not been answered in time to matter.

That is not a dramatic story. It is the mundane version of a structural problem that repeats itself constantly in any organisation where geographic questions and spatial analysis tools are separated by specialist mediation.

The pattern we kept seeing

Mei Lin and I had been working independently on different sides of the same problem for years before we met. Her background was in natural language processing systems and developer tooling. Mine was in spatial data pipelines and geographic analytics. We were introduced through a mutual contact in Melbourne's tech community in late 2024, and the overlap in what we had each observed was immediate.

Both of us had worked extensively with teams that were sitting on location data they were not using effectively. Not because they did not understand the value of geographic insight. They did. Not because the data was inaccessible or of poor quality. It usually was not. The barrier, consistently, was the interface between the question and the spatial analysis tool.

Location questions come from people who think in plain English about their operations. GIS tools speak a different language, one that requires training, practice, and daily use to maintain fluency. That linguistic and technical gap between the people with the questions and the tools capable of answering them was producing a lot of very capable analysts who simply could not connect their geographic intuition to any geographic output.

Why natural language specifically

The obvious question when we started thinking about this seriously was: why not just train more analysts in GIS? Or build better GIS documentation and lower the learning curve for existing tools?

We spent time on that question, and our honest answer is that the GIS learning curve problem is not primarily a documentation or training problem. GIS is a discipline with genuine technical depth. The concepts that make spatial analysis work correctly, coordinate reference systems, topology, network routing, spatial indexing, are not concepts that yield to better tutorials. They are concepts that require sustained practice with real data in real workflows to develop genuine competence.

The population of people who will develop that competence will always be smaller than the population of people who have geographic questions about their work. That gap is structural, not solvable by better documentation.

Natural language as the interface is not a shortcut past the technical complexity of spatial analysis. The technical complexity is still there. It is just handled by the system rather than required from the user. The user provides the geographic intent. The system handles the spatial execution. That is the division of labour we designed for.

What we built in the first six months

We started with the hypothesis that the most common spatial queries in business and planning contexts are a relatively small set of operations: proximity analysis, catchment generation, boundary intersection, choropleth visualisation, and coverage gap identification. We were right about that. We interviewed a range of analysts, planners, and operations managers in Melbourne and Brisbane during early 2025, and the same query patterns came up consistently.

The first thing we built was an NLP parsing layer that could reliably extract the spatial intent from plain-English queries. Getting that right for geographic language was harder than it sounds. Geographic intent is often expressed with ambiguity (what counts as "inner suburbs"?), with implicit constraints (a query about "retail precincts" implies a commercial land use filter), and with domain-specific vocabulary that varies across industries and regions (Australian planning uses different boundary terminology than UK planning, which is different again from US usage).

Mei Lin spent the first three months of 2025 on the parsing layer while James Whitfield, who joined us in February, worked on the product experience: how do you present map outputs, what controls does a non-specialist user need, how does the query interface communicate what it has understood and give users a way to correct it?

By mid-2025 we had something that worked well enough to show to the analysts and planners we had interviewed. The feedback was consistent: the queries they had assumed would be too complex for a plain-English interface mostly resolved correctly. The ones that failed were genuinely ambiguous, and the failure modes were informative rather than confusing.

The Melbourne context

We are based at 120 Collins Street in Melbourne, and that context is not incidental to how we built MapAI. Melbourne is a city with an active GIS professional community, a significant urban planning sector, and a strong logistics and supply chain industry. All three of those sectors deal with geographic questions daily, and all three have the specialist-mediation problem we were building to solve.

The AU data layers we integrated first, ABS census boundaries, PSMA address data, public transport network geometry, reflect the early-access users we were building with. We have since added NZ coverage and have requests for additional jurisdictions. But starting with AU data meant we could build with real users in real workflows rather than testing against hypothetical use cases.

What we are not trying to be

MapAI is not a GIS replacement. It is a self-service interface for the majority of spatial queries that currently require specialist mediation but do not actually require specialist expertise to formulate or interpret. The GIS discipline has depth that a natural language interface cannot reproduce: custom spatial modelling, topology management, data infrastructure architecture, multi-criteria weighted suitability analysis. Those problems belong to specialists, and they always will.

What we are trying to be is the path from question to geographic evidence for the analyst who has never used QGIS and never needs to, but does need to know where their customers are, where their coverage gaps are, and what the spatial distribution of their data looks like. That person has always existed in large numbers. They have just had no direct path to the geographic answers to their questions. Building that path is what MapAI is for.