Why Is My GIS Layer Empty?

When a GIS layer appears empty, first determine whether the problem is the data, the geometry, the extent or the display. Those are different failure modes, and changing the CRS or symbology before you know which one you have can make the original problem harder to diagnose.

The most useful first question is simple: does the layer actually contain features with usable geometry?

Start with feature count and geometry

Inspect the number of records before looking at the map. If the layer contains zero rows, the problem happened upstream: an import may have failed, a query may have returned no matches, a filter may have removed everything, or a processing step may legitimately have produced an empty result.

If rows exist, inspect the geometry column. A table can contain hundreds of attribute records while every geometry is null or empty. Conversely, geometry may exist while the attributes you expected are missing.

A quick diagnostic table helps:

What you observe · What it suggests · What to check next

0 rows — Upstream filter/query/import issue — Source count, query conditions, operation inputs
Rows exist, geometry is null — Geometry creation or import issue — Geometry field, parser, source format
Geometry exists, map is blank — Extent, CRS, styling or visibility issue — Bounds and current view
Some rows have geometry — Partial data-quality problem — Which records are null and why

Preserve the original dataset before repairing anything. An empty derived layer may be correct evidence that no features satisfied the operation.

Check whether the features are somewhere else

If geometry exists, inspect the layer's bounds or extent, because a layer that is geographically far from the current map can look identical to an empty one.

The extent often reveals the cause. Longitude/latitude coordinates normally fall within familiar angular ranges. Projected coordinates may be hundreds of thousands or millions of units. A single extreme value can also stretch the layer extent so far that valid features become visually microscopic.

If the bounds are implausible, investigate the coordinate interpretation before pressing “zoom to layer” repeatedly. Common causes include reversed latitude and longitude, a CRS assigned rather than transformed, or corrupted coordinate values.

What Happens When a GIS File Has No CRS? explains the difference between recovering a missing CRS and reprojecting known coordinates.

If the extent is plausible, inspect visibility

A layer can contain valid features in the correct place and still be invisible, so check whether:

the layer is enabled;
it is below another opaque layer;
its symbols have transparent fill and stroke;
line width or point size is effectively zero;
a scale-dependent rule hides it at the current zoom;
a style expression evaluates to null or transparent values;
a filter or selection state excludes all visible records.

A useful test is to apply a temporary, simple style that cannot depend on attributes: one obvious colour, one fixed size, no data-driven opacity. If the features appear, the geometry and extent were probably fine and the problem belongs to the style or visibility rules.

Do not leave the temporary style as the “fix” until you understand which original rule removed the features.

Separate filtering from missing data

A filter can make a healthy dataset look empty without changing the underlying records, especially when:

a text comparison is case-sensitive;
a numeric field was imported as text;
null values behave differently from empty strings;
a date filter assumes a different format or timezone;
a join changed the field names referenced by the filter.

Inspect a few raw values and count records before and after the filter. If removing the filter restores the layer, validate the filter logic rather than re-importing the data.

The same principle applies to derived operations. If an intersection or spatial join returns zero features, verify that the two inputs genuinely overlap and use compatible coordinate interpretations before assuming the operation failed.

Check whether the layer loaded successfully

If the data source is remote or database-backed, the problem may occur before rendering.

Look for failed network requests, authentication errors, missing tables, unavailable files, parser errors or server-side query failures. A user interface may still show the layer name even when no usable data reached the renderer.

For large datasets, distinguish a true load failure from slow processing. If feature counts remain unknown or requests fail, treat it as a loading problem; if features arrive but rendering stalls, the issue may instead be performance or styling complexity.

Verify the recovery

After you identify the cause, confirm more than “something is visible now”.

Check that:

the expected feature count is present;
representative records have non-null geometry;
the geographic extent is plausible;
the layer appears in independently known locations;
any filters return the expected subset;
the original and repaired layers differ only in the intended way.

That final comparison matters. A speculative CRS assignment or geometry repair can make a layer visible while moving it to the wrong place.

Empty, invisible and failed are different states

An empty dataset contains no usable features, an invisible layer contains features that are not currently being drawn, and a failed layer never delivered usable data to the map. Those states can look identical on screen, but they require different fixes.

The fastest route to a defensible answer is therefore to diagnose in order: records → geometry → extent → filter/style → loading. Visibility should be the result of understanding the data, not the test used to guess what the data mean.