ArcGIS Pro: build a defensible zone-demand layer

Define the analysis before opening a tool

This exercise creates a demand-by-zone feature class from the same fictional customer and polygon data used in the QGIS guide. The result should be reproducible, preserve unresolved records and reconcile exactly to the accepted customer ledger. A map that looks correct is insufficient if a spatial join duplicated consumption.

Use an ArcGIS Pro installation with the required geoprocessing capabilities. The workflow uses ordinary tables and feature classes; it does not require creating a Utility Network. Utility Network adds managed network modelling capabilities for appropriate enterprise workflows, but installing a network schema is not necessary for this basic spatial assignment task.

Set up a project and preserve the source records

Create a project with a working file geodatabase. Add the customer CSV as a table and inspect data types, unique IDs, blanks and numeric demand. Record the raw count of eight and total of 6,700 L/day before making changes.

Use a frequency or summary check on customer_id to identify CP04. Its two rows are intentionally identical in this exercise. Keep one in the accepted table, documenting the decision. The resulting seven unique records total 5,500 L/day. Keep CP07, which lacks coordinates, in a separate exception table with its 500 L/day.

Do not use an automatically generated ObjectID as the only long-term customer key. It can change when data is exported or rebuilt. Preserve customer_id and zone_id through every transformation, and use those stable fields in the final comparison.

Create points with the correct coordinate meaning

1. Open the XY Table To Point tool for the cleaned, valid-coordinate customer table. Choose longitude as X and latitude as Y.
2. Set the input coordinate system to WGS 84 because the supplied values are longitude and latitude. Save the output in the working geodatabase.
3. Convert or load the GeoJSON polygons into a zone feature class, retaining zone_id. Confirm its source CRS before any transformation.
4. Use Project to create working copies in GDA2020 / MGA zone 56, EPSG:7856, for metric operations in this Sydney-area exercise. Select a suitable geographic transformation where required.
5. Inspect known points, polygon edges and coordinate ranges. Preserve the original geographic features for checking the exact shared-boundary case.

The input coordinate system describes the numbers in the table. The output map’s coordinate system does not repair an incorrectly interpreted input. Define Projection changes a coordinate definition; Project changes coordinate values. Use the operation that matches the actual problem.

Use Spatial Join as a diagnostic first

For the diagnostic join, set customer points as Target Features and zones as Join Features. Use the Intersect relationship, a one-to-many join and a setting that retains unmatched targets. Save this output separately from the final allocation.

Inspect the target and join identifiers and count output rows by customer_id. A point touching both zones can generate more than one match. CP05 lies exactly on the common edge in the original input, so it requires a boundary decision. CP06 lies outside both polygons. CP07 was never represented by valid point geometry and remains in the exception register.

A one-to-one join can combine matches using field-map rules, but aggregation does not establish which supply zone is physically correct. Taking the first zone hides ambiguity. Resolve the relationship before using a join output as the authoritative allocation.

Build the reviewed customer-to-zone table

Create fields such as assigned_zone, assignment_method and review_note in a reviewed copy or a separate keyed table. Assign CP01 and CP02 to WEST, CP03 and CP04 to EAST, and assign CP05 to EAST solely for this teaching exercise. Leave CP06 and CP07 unresolved. In actual work, use connection records or an agreed engineering review to decide edge cases.

Return to one row per unique customer. Confirm that each accepted record is either assigned once or included once in the unresolved set. Do not use the duplicated one-to-many diagnostic table as the source for the final demand sum.

If the accepted total changes after a purely spatial operation, investigate duplicates or omissions. An assignment can move volume between zones, but it should not create or destroy the accepted system volume.

Summarise and join the results for mapping

1. Run Summary Statistics on the reviewed allocation table, using assigned_zone as the case field and SUM of average_l_day as the statistic. Keep unresolved demand visible in a separate category or table.
2. Join the summary to the zone feature class using zone_id, checking that the summary has no duplicate zone keys.
3. Add or calculate clearly named display fields with units, such as average_ml_day = sum_l_day / 1,000,000.
4. Inspect the two zone totals and the system ledger. Symbolise the mapped measure without presenting unresolved demand as zero.
5. Create a layout with a legend, units, assumptions, source date and an explicit statement that the exercise is synthetic.

If instead you use a polygon-target Spatial Join with point demand as the join field, set the intended Sum merge rule and understand how boundary matches are counted. That shortcut is appropriate only where geometric membership exactly matches the reviewed allocation policy.

Make a boundary-change comparison reproducible

Keep old and new zone feature classes and one common accepted customer table. Create a comparison keyed by customer_id that records old assignment, new assignment, demand and reason. Summarise both gross movement and net change: 1 ML/day moving each way produces zero net change but can still involve many affected connections.

Review polygons for gaps, overlaps and unexpected slivers. A clean feature geometry does not establish a valid supply-zone topology. Overlay changes with valves, feeders and service information before assuming that cartographic membership matches operational supply.

Use ModelBuilder or a recorded geoprocessing history to repeat stable steps, but keep exception resolution visible. Automatic execution should stop or flag the result when counts, key uniqueness or demand reconciliation fail. Do not make manual engineering decisions invisible inside an undocumented intermediate file.

Carry the dataset into engineering review

A GIS zone-demand map establishes an allocation basis, not proof of pressure compliance or outage resilience. Export stable IDs, demand units, accepted assignments and unresolved records in the format required by the downstream model. Check totals again after import.

The deliverable should contain the project, geodatabase, raw source records, processing history, exception register and summary ledger. If enterprise editing or Utility Network services are involved, retain the approved version and editing workflow. Continue with WS Pro model allocation and network assessment.

Sources & further reading

• Spatial Join ↗Esri · ArcGIS Pro living documentation
  External source · Checked 25 September 2026
• XY Table To Point ↗Esri · ArcGIS Pro 3.3 documentation
  External source · Checked 25 September 2026
• Water Utility Network Foundation ↗Esri · ArcGIS Solutions 11.4
  External source · Checked 24 September 2026

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