Short answer

Why Your GIS Layers Do Not Line Up matters because it affects whether a map, analysis layer, or spatial product can be trusted. In practical terms, this topic is about building a defensible coordinate workflow where display, measurement, and analysis all use the right spatial reference.

The reader is usually trying to find out why data appears in the wrong place, why measurements look wrong, or which coordinate system should be used before analysis. The fastest answer is often a software step, but the durable answer is a workflow: understand the data, check the assumptions, run the operation deliberately, and document what changed.

The practical answer depends on source quality, coordinate discipline, processing assumptions, and how the output will be used by the next person in the workflow.

Field example

A common failure case is a project boundary in a local projected CRS, a public geology layer in longitude and latitude, a shapefile missing its .prj file, and a basemap in Web Mercator. Everything may appear close enough after on-the-fly reprojection, but the moment the team measures distance, clips a DEM, or calculates slope, the hidden mismatch becomes a real analytical error.

Decision frame

  • Treat visual alignment as a clue, not proof.
  • Find the source CRS before assigning anything.
  • Reproject analysis layers into a projected CRS suited to the area of interest.
  • Record the CRS chain before exporting maps, reports, or web layers.

Diagnostic pattern

Start by turning off the basemap and checking layer extents numerically. If one layer has coordinates around 7, 43 and another around 320000, 4760000, the project is mixing angular and projected coordinate values. That can be valid, but only if each layer's CRS metadata is correct.

Diagram brief

  1. Raw source layers with declared or missing CRS.
  2. CRS audit that separates display CRS from processing CRS.
  3. Reprojected working layers used for measurement and terrain analysis.
  4. Published map or dataset with source CRS, processing CRS, and output CRS documented.

Key takeaway

Classify the failure before fixing it: missing CRS, wrong CRS, unsuitable analysis CRS, datum transformation issue, or coordinate-order problem.

Why this matters

A coordinate reference system is not a styling preference. It defines how coordinates in a file relate to real places on the earth.

Geographic systems such as WGS84 use angular units, while projected systems use planar units such as meters or feet.

On-the-fly reprojection can make layers display together, but it does not automatically make every layer suitable for distance, area, buffer, or terrain calculations.

The operational risk is usually not the map view. The risk is that a team trusts an analysis output created from mismatched or poorly documented coordinate assumptions.

For geology, terrain, and Earth data teams, the cost of a weak workflow is rarely visible at first. The map may load. The colors may look right. The export may succeed. The problem appears later, when a measurement is wrong, a layer cannot be reused, a stakeholder asks for the source logic, or another analyst has to rebuild the result from scratch.

That is why Bathyl content is written around operational trust. The question is not only "how do I do this in the software?" The better question is "what must be true for this output to be reliable?"

Practical workflow

  1. Identify the declared CRS of every source layer before changing anything.
  2. Separate missing metadata from wrong metadata. Assigning a CRS is only appropriate when the coordinates are already in that CRS.
  3. Reproject analytical layers into a projected CRS that matches the project extent and measurement task.
  4. Check horizontal units, vertical units, datum transformations, and the area of use of the selected CRS.
  5. Run a visual control check against a trusted reference layer and a measurement check against a known distance or area.
  6. Document source CRS, processing CRS, output CRS, and any transformation assumptions in the project notes.

Quality checks before you trust the output

Use a short review before the result goes into a client map, report, dashboard, or internal decision:

  • Check whether the source data, CRS, units, scale, and date are explicit.
  • Compare the output against at least one trusted reference layer or known control value.
  • Inspect edge cases rather than only the clean center of the project area.
  • Save intermediate outputs when they help explain how the final result was produced.
  • Write down assumptions in plain language so a future analyst can audit the work.

Common mistakes

  • Using Web Mercator for analytical measurements because it looks familiar from basemaps.
  • Assigning a CRS to force a layer to move instead of reprojecting from a known source CRS.
  • Calculating buffers or areas from longitude and latitude coordinates without checking units.
  • Ignoring vertical units when elevation data is part of the workflow.

Bathyl perspective

Bathyl treats CRS work as a trust layer. A beautiful map is weak if the coordinate chain is undocumented, so the deliverable should make the projection logic visible enough for another analyst to audit.

For this specific topic, the useful standard is simple: the article, map, dataset, or interface should help a technical reader understand what was done and help a decision-maker understand how much confidence to place in the result.

Related Bathyl reading

Source notes

This article is grounded in public technical documentation and standards, then adapted into a practical workflow for geological and geospatial teams.