Skip to content

fix(core): keep the cartesian z scale continuous at zoom 12 - #10853

Open
mfrnd wants to merge 1 commit into
visgl:masterfrom
mfrnd:fix/7064-cartesian-z-zoom-12-step
Open

mfrnd wants to merge 1 commit into
visgl:masterfrom
mfrnd:fix/7064-cartesian-z-zoom-12-step

Conversation

@mfrnd

@mfrnd mfrnd commented Oct 11, 2026 •

Copy link
Copy Markdown
Contributor

For #7064. Follow-up to #10790, from ibgreen's note.

Background

Since #10790, 'cartesian' positions below zoom 12 use the viewport center as geospatial origin, so their second-order z correction is nonzero away from the equator. In WEB_MERCATOR mode, project_offset_ multiplies it by the absolute common y instead of the offset from the center: below zoom 12, 1,000 m at the viewport center is drawn as 1,000.40 m at latitude 80 and 999.95 m at latitude -80, from zoom 12 as 1,000.00 m.

Change List

  • calculateViewportUniforms: cartesian z correction in WEB_MERCATOR_AUTO_OFFSET mode only
    • Omitted below zoom 12 rather than made center-relative: unitsPerMeter2 is per meter, but cartesian y offsets are in common units, so even from zoom 12 it changes z by less than a millionth across the view
  • Unit tests: projected z on the GPU at zoom 11.99 and 12, latitudes 80 to -80

Ran lint, build, the core shaderlib and viewport, extensions and TerrainLayer headless tests, and the terrain render tests on WebGL.


Note

Medium Risk
Touches core projection uniforms used by all cartesian/preprojected layers; behavior change below zoom 12 is intentional but could affect subtle elevation rendering.

Overview
Fixes a discontinuity at zoom 12 for COORDINATE_SYSTEM.CARTESIAN geometry (e.g. terrain meshes) where z is in meters but x/y are already in common space.

In calculateViewportUniforms, the cartesian branch no longer always sets commonUnitsPerWorldUnit2 from unitsPerMeter2. The second-order z correction is applied only when projectionMode is WEB_MERCATOR_AUTO_OFFSET. In plain WEB_MERCATOR (zoom < 12), it is zeroed so the shader does not scale that term by absolute common y—which had caused latitude-dependent elevation error and a step when the viewport switches modes at zoom 12.

Adds a GPU regression test that projects a 1000 m z at the viewport center across zoom 11.99 vs 12 and latitudes 80° to −80°, asserting recovered elevation stays ~1000 m.

Reviewed by Cursor Bugbot for commit e2be793. Bugbot is set up for automated code reviews on this repo. Configure here.

Since the viewport center is the geospatial origin of 'cartesian'
positions below zoom 12, their second-order z correction
(commonUnitsPerWorldUnit2) is no longer zero away from the equator.
project_offset_ multiplies it by the y offset from the origin, but
WEB_MERCATOR mode does not offset positions, so below zoom 12 it used
the absolute common y: 1,000 m at the viewport center was drawn as
1,000.40 m at latitude 80 and 999.95 m at latitude -80, and as
1,000.00 m from zoom 12.

Apply the correction in WEB_MERCATOR_AUTO_OFFSET mode only. A GPU test
projects 1,000 m at the viewport center at zoom 11.99 and 12, at
latitudes 80, 46.2, 0, -46.2 and -80.
@greptile-apps

greptile-apps Bot commented Oct 11, 2026 •

Copy link
Copy Markdown

RetriggerConfidence Score: 5/5

[Medium impact] The PR appears safe to merge.

Summary

The PR removes the incorrect cartesian z correction below zoom 12 while keeping the existing correction above it.

  • Cartesian heights stay continuous as zoom crosses 12.

Reviews (1) · Last reviewed commit: "fix(core): keep the cartesian z scale co..." · Reviewed by Greptile

@coveralls

Copy link
Copy Markdown

Coverage Status

coverage: 83.704% (+0.001%) from 83.703% — mfrnd:fix/7064-cartesian-z-zoom-12-step into visgl:master

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants