QGIS: allocate customers to zones without losing the ledger

The planning question and deliverables

Which customers belong to each supply zone, what demand do they represent, and which assignments still need evidence? This exercise produces a customer-to-zone table, an exception register and a zone demand summary. It uses two fictional polygons and eight customer rows near Sydney coordinates. None are actual customer or utility data.

Use QGIS 3.40 or a compatible later release. Menu labels can vary slightly, but the data model and checks remain the same. The task is a spatial assignment exercise. It does not prove hydraulic connectivity or replace service-connection records.

Inspect the table before creating geometry

Open customers_raw.csv as a table and inspect customer_id, longitude, latitude and average_l_day. Treat the ID as text and demand as a numeric field. There are eight rows but only seven unique IDs. CP04 occurs twice with identical coordinates and demand. In this exercise the duplicate is known to be accidental, so retain one copy and record why.

CP07 has demand but no coordinates. Keep it in the nonspatial exception register. Do not replace missing coordinates with zero, and do not let the geometry import silently remove its 500 L/day from the demand ledger. The raw total is 6,700 L/day; the accepted unique total after removing the duplicate is 5,500 L/day.

For a real dataset, two records at one address may be legitimate separate accounts, meters or tenancies. Duplicate coordinates are therefore not enough to justify deletion. Use the stable business identifier and the meaning of each record.

Load and project the spatial layers

1. In Data Source Manager → Delimited Text, choose the cleaned CSV. Select point coordinates, longitude as X and latitude as Y. Set the source geometry CRS to EPSG:4326.
2. Load zones.geojson as a vector layer. Its longitude and latitude coordinates also use EPSG:4326. Inspect the two adjacent polygons.
3. Save the valid customer points and the zones into a GeoPackage with meaningful layer names. Preserve customer_id and zone_id as business keys.
4. For metric operations in this Sydney-area exercise, reproject working copies to GDA2020 / MGA zone 56, EPSG:7856, choosing an appropriate available transformation.
5. Check the overlay visually and inspect layer CRS definitions. Keep the original geographic layers for a boundary check using the supplied coordinates.

Assigning a CRS tells the software what existing coordinates mean; reprojection transforms coordinates into another system. Assigning a metre-based CRS to numbers such as 151.2 and −33.9 does not convert them into eastings and northings. A plausible basemap display can also conceal mixed or incorrectly defined source systems.

Use a join that exposes ambiguity

Open Processing Toolbox and find Join attributes by location. Use customer points as the input and zones as the join layer. Retain zone_id and choose a one-to-many output while investigating matches. Keep unmatched customers. This intermediate result is for QA, not yet the final allocation table.

A strict within relation excludes a point lying exactly on the polygon boundary. Intersects includes touching boundaries and can match the same point to both adjacent polygons. CP05 has longitude 151.200 and lies on the shared edge by construction. Run or inspect both relationships and explain the difference.

Overlay precision and reprojection can affect the treatment of a point extremely close to an edge. Use the original coordinates to confirm the intended teaching case. In real work, establish a positional tolerance and investigate the actual connection rather than allowing a tiny coordinate change to decide the supplied zone.

Resolve exceptions explicitly

Create a final allocation table with one row per unique customer, an assigned_zone field and an assignment_reason field. Record manual decisions separately from the raw spatial result. A nearest-zone fallback can be useful for investigation, but it should not silently turn an outside point into a confirmed connection.

Aggregate only after resolving the relationships

Summarise the final allocation table by assigned_zone using an aggregate or group-statistics workflow. Sum average_l_day and count unique customer IDs. Join the summary back to zone polygons by zone_id so that the map reflects the reviewed assignment, including the boundary decision.

Join attributes by location (summary) can aggregate point values directly to polygons. It is useful when geometric membership is the intended rule, but it will not automatically honour a separate manual assignment. If you aggregate an intersects result before resolving CP05, its demand can be counted in both zones. For this exercise, the final attribute-based register is the controlling dataset.

WEST has two customers, EAST has three, and two remain unassigned.

Convert only after reconciliation: 5,500 L/day is 0.0055 ML/day, or approximately 0.06366 L/s as a uniform average. Do not label the same number as peak demand. Document any subsequent pattern or peaking conversion separately.

Turn the workflow into a reusable planning check

For a zone-boundary revision, run the same identity and membership checks on old and new polygons using the same accepted customer table. Compare assignments by customer_id. Produce a change list showing old zone, new zone, demand, rule and unresolved reason. This is more useful than comparing only two coloured maps.

Distinguish changed boundaries from changed source demand. If both are updated simultaneously, preserve enough intermediate outputs to separate their effects. Reconcile each zone and the full system before importing the accepted results into a hydraulic model.

For pipe proximity, work in an appropriate projected CRS and investigate barriers, roads, elevation and actual service connections. A GIS nearest feature operation establishes geometric distance, not an operational connection or a safe allocation rule.

Save an auditable GIS package

• The raw table, accepted unique table and reason for each correction.
• The original and projected layers with CRS and transformation information.
• A one-row-per-customer allocation register and an exception table.
• Zone totals that reconcile to accepted demand, including nonspatial records.
• A map with a clear legend, units, data date and source description.

Use the WS Pro allocation guide to carry this evidence into the model, or the ArcGIS workflow to perform the same exercise in another GIS.

Sources & further reading

• Vector general: spatial joins and summaries ↗QGIS Project · QGIS 3.40 documentation
  External source · Checked 25 September 2026
• Opening data: delimited text and coordinate definitions ↗QGIS Project · QGIS 3.44 documentation; compatible workflow concepts for 3.40
  External source · Checked 25 September 2026

Source findings are distinguished from editorial interpretation. Apply current local criteria and project evidence when making engineering decisions.