How Natural Language Queries Are Changing Urban Planning Research

The site assessment bottleneck in council planning teams

Local councils run spatial analyses constantly. Site assessments for new community facilities, catchment studies for schools, infrastructure corridor reviews, demographic overlay work for service planning. The geographic questions are relentless, and the data to answer them exists in every council's systems. What does not exist, in most cases, is a fast path from question to answer.

The usual process goes something like this. A planner identifies a question: where are the underserved pockets of population in the northern corridor relative to existing childcare facilities? They request the analysis from a GIS team or an external consultant. The specialist interprets the brief, builds the query or script, waits for data access approvals if layers are managed by another department, runs the analysis, and delivers an output. Depending on the organisation, that cycle runs four to ten working days. In a busy council environment, the planner has usually had to make a preliminary decision by the time the map arrives.

We have seen this pattern repeatedly in our early conversations with planning professionals. The bottleneck is not the GIS specialist's capability. It is the structural gap between the pace at which planning questions arise and the pace at which spatial answers can be produced through a specialist-mediated workflow.

What a plain-English workflow actually changes

When a planning analyst can type a question and receive a map in under a minute, the workflow changes in a specific and observable way. It is not that the question gets answered faster in isolation. It is that the analyst can ask follow-up questions immediately, without booking another queue slot.

In conventional GIS workflows, follow-up questions have a cost. Each iteration requires a new request, a new wait, and a new round-trip through the specialist queue. This means analysts tend to under-iterate. They ask one question per cycle and try to make it comprehensive enough to cover all their follow-ups in advance. That produces broad, general analyses when what was actually needed was a sequence of increasingly precise questions.

Natural language querying changes the economics of iteration. When a follow-up costs 20 seconds instead of four days, analysts ask the follow-up. The inquiry deepens. The planning insight sharpens. This is the actual productivity gain, not simply the speed of a single query, but the removal of friction from the whole iterative reasoning process.

A concrete scenario: community facility siting in Melbourne's inner north

Consider a planning team at a metropolitan council assessing potential sites for a new community health facility. The initial brief is to identify locations in the inner north that are within 800 metres walking distance of a tram stop, not currently within 1.5 kilometres of an existing facility, and located in census collection districts with above-average proportions of residents aged 65 and over.

In a natural language environment, this translates to something close to the query as stated: "Show me residential areas in the inner north within 800m of a tram stop, more than 1.5km from existing community health facilities, with high proportion of residents aged 65 plus." The system parses the spatial relationships, identifies the relevant data layers, applies the proximity constraints, and renders the candidate zones as a map.

The planner looks at the output and immediately sees that two candidate zones overlap with a flood overlay. A follow-up query: "Remove areas within the 1 in 100 year flood extent." Thirty seconds. Now the planner wants to understand pedestrian access quality for elderly residents in the remaining zones. "Show those areas with footpath condition data if available." The analysis deepens in minutes, not days.

This is not a hypothetical future capability. It describes how planning queries are being structured and answered in our early-access environment. The specific layers, constraints, and follow-up logic are exactly what the natural language parsing layer handles.

Where the time savings actually come from

The surface-level answer is that natural language removes the need for specialist mediation on routine queries. But the deeper answer is about cognitive offload and iteration depth.

Planning professionals are domain experts. They know what question to ask. What they typically lack is fluency with spatial query syntax: the PostGIS functions, the QGIS workflow steps, the ArcGIS Model Builder logic that translates their question into an executable operation. The specialist-mediated model exists precisely because that translation is technically demanding.

When the translation layer is handled by natural language processing, the planning professional's domain expertise becomes sufficient. They do not need to learn to speak GIS. The time savings come from collapsing the translation step, the queue step, and the re-briefing step that currently separates every question from its answer.

In our pilot data, planning-type queries that took an average of 5 working days through a specialist queue were completed in under two minutes when the analyst used direct natural language input. That gap exists not because the underlying analysis is simpler, but because the mediation overhead is gone.

What natural language queries do not replace

We want to be direct about the limits here, because overstating them creates expectations that no tool can meet.

Natural language querying handles well-scoped geographic questions: proximity analysis, boundary intersection, point-in-polygon operations, choropleth visualisation of census or tabular data, coverage radius analysis. These are the majority of routine planning queries and the ones that currently generate most of the specialist queue backlog.

What natural language querying does not replace is the interpretive judgment of an experienced GIS specialist working on a genuinely complex problem. Custom spatial modelling, suitability analysis with weighted multi-criteria frameworks, network analysis across large road graphs, or proprietary data integration work: these require specialist expertise and will continue to do so. Our position is not that specialists are unnecessary. It is that most planning teams are using specialists for work that does not require specialist-level expertise, because no accessible self-serve path existed.

The goal is to free planning professionals to handle the routine spatial questions themselves, so GIS specialists can spend their time on work that actually needs them.

Where planning teams are starting

In our experience working with planning professionals in early access, the highest-value entry point is demographic overlay work: quick questions about population characteristics in specific geographic areas, often in support of grant applications, consultation documents, or site selection briefs. These queries are frequent, time-sensitive, and directly tied to professional decisions. They are also exactly the kind of query that a capable NL system can handle without specialist mediation.

Transport proximity analysis is the second common starting point. Questions about access to public transport, distance from major roads, proximity to cycling infrastructure. These queries are structurally simple but have high decision relevance for planning teams.

If your team is running these queries through a specialist queue or waiting on consultant deliverables, the simplest test is to type the question you would normally send in a brief. If the question is answerable with publicly available spatial data and does not require custom modelling, the answer will come back as a map before you finish your coffee.