From Spreadsheet to Map in One Query: Importing Your Own Location Data

If your team tracks anything by location, you almost certainly have a spreadsheet somewhere with a postcode column, an address column, or a latitude and longitude pair. Most organisations do. The question is whether that location data has ever made it onto a map, or whether it has stayed in tabular form, invisible to the geographic patterns it contains.

Getting from a CSV file to a useful map typically requires one of the following: a GIS tool that accepts tabular data import and knows how to geocode or join it to a boundary layer, a mapping platform that has a specific data upload workflow, or a developer who can write the transformation code. None of those paths is fast or forgiving for an analyst who just wants to see where their data is.

MapAI's data import and query workflow is designed around a different assumption: that the analyst already has the data, already knows the question, and should not need to become a GIS operator to connect the two. This article explains how that import-and-query flow works in practice.

What the import process actually does

When you upload a CSV or Excel file to MapAI, the system performs three operations before you write a single query.

First, it scans the column headers and data types to identify geographic identifiers. It is looking for columns that contain postcode values, suburb names, SA1 or SA2 codes, LGA names, state identifiers, address strings, or latitude/longitude coordinate pairs. It ranks the columns by confidence and presents its interpretation for confirmation. In most cases, the geographic column is unambiguous. When it is not, you specify which column to use.

Second, for address string columns, it geocodes the addresses to point coordinates using the integrated geocoding service. For postcode or boundary-code columns, it performs a join to the appropriate boundary layer. For coordinate columns, it reads the values directly as spatial points. All three paths produce a spatial dataset that is queryable.

Third, it validates the geographic coverage. It checks what proportion of records resolved to valid locations, flags any that could not be geocoded, and reports the geographic extent of the dataset. If 15% of your postcodes returned no match, you see that before you start querying, not after you notice that a region looks empty.

The whole process typically takes under a minute for files up to around 10,000 rows. Larger datasets take proportionally longer but run in the background, notifying you when they are ready.

From import to first query

Once your data is imported, you query it using the same natural language interface as the built-in datasets. The uploaded data appears as a named layer that you can reference directly in your queries.

For a retail company that has uploaded their store locations as a CSV with address, state, and revenue columns, the first query might be: "Show our stores on a map coloured by annual revenue." For a field services company with technician locations and postcode coverage areas, it might be: "Show our technician home postcodes overlaid on our active service postcodes." For a logistics team with delivery exception records, it might be: "Show delivery exception locations from last month's dataset on a street-level map."

In each case, the system maps the column values from the uploaded dataset to the appropriate visual output, places the features at their geographic coordinates or boundary locations, and applies the requested symbology. You do not write a join condition. You do not specify a coordinate reference system. You type the question.

Combining your data with platform data layers

Where the import-and-query workflow becomes genuinely powerful is when your uploaded data is combined with the spatial context layers that MapAI provides. Your data tells you what is happening. The platform data tells you what is surrounding it.

A concrete example from our early-access work: a community health service uploaded their service delivery records, including client postcodes and service type codes, as a CSV. Their initial question was straightforward: show service delivery by postcode as a choropleth. The map showed the geographic distribution of their current service activity.

The follow-up was more interesting: "Overlay the ABS SEIFA disadvantage index by SA2 on the same map." The combination immediately revealed that their service delivery was geographically concentrated in areas of low disadvantage. Their highest-need communities by socioeconomic indicators were largely not appearing in their service data. That is an equity finding that had strategic implications for the service. It was visible only because the uploaded data was overlaid on the platform's demographic context layer.

This kind of combined-data query requires no specialist knowledge to formulate. It requires knowing what question to ask, which is the domain expertise that the people in this organisation already have.

Data formats and what works well

CSV and Excel files are the most common upload formats, and both work well when the geographic identifier column is present and reasonably clean. A postcode column that contains some non-standard values (e.g., leading zeros dropped from Victorian postcodes like 3000 being stored as 3000 versus 03000) will produce partial matches. The validation step at import makes these issues visible so you can clean them before querying.

GeoJSON and Shapefile uploads are also supported for teams that already have spatial data in those formats. These produce the most reliable geographic results because the coordinate information is already embedded in the format rather than requiring geocoding or a boundary join.

What does not work well: address data with inconsistent formatting across rows (unit 5/12 Main Street versus 5/12 Main St versus Unit 5, 12 Main Street), and large datasets where the geographic column contains a mix of identifier types (some rows have postcodes, some have SA2 codes, some have suburb names). These are data quality issues that reflect the source data, and no import tool resolves them without cleaning. The validation step at least surfaces them early.

What to do with the output

Once your data is on the map, the export options depend on your plan. The Explorer tier includes PNG export for the rendered map view, which is suitable for presentations and documents. The Analyst tier adds CSV export of the joined and classified data, which lets you take the spatially enriched dataset back into Excel for further analysis. The Team tier adds GeoJSON export and API access for programmatic workflows.

For most analysts, the PNG and CSV exports cover the majority of use cases. You produce the map, export it for a presentation, and export the data if you want to do further tabular analysis on the spatially joined values.

The starting point is simpler than any of this might suggest. If you have a spreadsheet with a location column and a question about what the data looks like on a map, upload the file and ask the question. The answer is usually there within a minute.