Work with large and complex datasets

Control the amount of work, not just the map zoom

Large GIS datasets stress several different browser resources: parsing, memory, map rendering, interaction hit-testing and geoprocessing. Zooming out does not automatically make a layer cheap to process, and hiding a layer does not remove it from an All-scope Processing request.

The safest strategy is to reduce the active working set deliberately while preserving an untouched source or project copy.

Import large local data deliberately

Keep the original source file and follow any large-layer import choices the app presents. When exact editing of every source vertex is unnecessary, an optimised editable representation or reference-style workflow can be more practical than forcing the browser to interact with every coordinate at full detail.

After import, check the reported source/optimised vertex counts or import metadata when available. An optimised representation is a performance decision and should not be confused with the authoritative original.

Reduce unnecessary rendering and interaction

• Hide contextual layers you do not currently need to see.
• Keep very large layer trees collapsed when inspecting another dataset.
• Use a quiet basemap when dense vector layers are the focus.
• Filter to a meaningful subset before table-heavy work.
• Avoid opening or repeatedly formatting enormous geometry-code payloads unless direct coordinate inspection is necessary.

These choices improve interaction, but remember that presentation state does not by itself change Processing membership.

Use Filtered or Selected Processing scopes

For a large source layer, a precise filter is often the best way to define repeatable work. Build the filter once, verify its record count, then choose Filtered for the Processing input.

Use Selected when the subset is spatial/manual rather than attribute-defined. Use All only when the operation really should process the complete eligible layer.

Processing preview is adaptive

Preview is designed to help without turning every parameter change into an expensive full-layer operation. Lightweight tools and smaller scopes can support live refresh after Preview is activated. Large or expensive operations become stale when parameters change and require Refresh preview.

The map preview can cap the number of temporary features it renders for responsiveness while still computing the complete result. Read the preview notice rather than assuming the map displays every calculated output feature.

Choose algorithms with data size in mind

Operations have different computational characteristics. A per-feature centroid or attribute selection is not equivalent to dissolving thousands of overlapping polygons or performing a many-to-many spatial join.

• Per-feature operations scale mainly with the features/vertices in the chosen scope.
• Aggregate operations such as Dissolve or Convex hull need to consider the complete scoped set together.
• Two-layer overlays/spatial joins depend on both input sizes and their spatial relationships.
• Geometry maintenance can become expensive when individual features contain very large coordinate arrays.

Use the preflight counts to understand the request before running it.

Simplify only when loss of detail is acceptable

Simplification can reduce render and processing cost, but it deliberately changes boundary coordinates. Use Preview Mode, start with a conservative tolerance and inspect important edges at the map scale where the data will be used.

The Simplify preview reports vertex reduction so you can measure the change. A high reduction percentage is not automatically good; it may indicate lost operational detail.

Large spatial joins

Reduce both sides of a spatial join when the question permits it. For example, filter the source to one region and the comparison layer to relevant feature classes before asking for expanded one-output-per-match results.

If you need only counts or a numeric aggregate per source feature, Spatial summary or Count points in polygon can produce a smaller and more useful result than expanding every individual match.

Save checkpoints before expensive structural work

Download an .epz checkpoint before a large modify-source operation, schema migration or sequence of Processing steps that would be difficult to recreate. Undo is useful, but a project file is a more durable checkpoint.

Keep the original source outside the project as well when simplification, repair or conversion could change precision or structure.

Know when the browser is the limiting resource

EditPolygon intentionally performs local GIS work in the browser. That preserves a strong local-data boundary but means available memory and CPU are those of the current device. A desktop workstation and a phone can therefore have very different practical limits even though they use the same project model.

If the browser cannot hold or process the required authoritative dataset safely, pre-process the source in an appropriate high-capacity GIS/database workflow and bring the focused working dataset into EditPolygon.