Skip to content

Polygon Z (GeoPackage)

vectorGPKGPolygonEPSG:4326tinybundled

The same Z ring as polygon_z_wkb, written through OGR into a GeoPackage. GPKG records dimensionality in a per-geometry flag byte rather than in the type code, and a driver can write the 2D form without raising -- so this half of the pair is what proves the elevations survived transcoding. Its id is 9007199254740993, one past 2^53, carrying the int64 case too.

Polygon geometry of polygon_z_gpkg, rendered from the case's data
Polygon geometry, rendered from the case's actual geometry. Scale is normalized to the viewport and is not comparable between cases.
Property Value
Case ID polygon_z_gpkg
Category vector
Format GPKG
Geometry type Polygon
CRS EPSG:4326
Location Copenhagen, Denmark (synthetic) — 12.50°E, 55.70°N → 12.52°E, 55.72°N
Test tier unit
Size class tiny
Storage class bundled
Redistributable yes
Loader geopandas
Status validated

Use this case

import pytest


@pytest.mark.geocase_case("polygon_z_gpkg")
def test_polygon_z_gpkg(geocase_case) -> None:
    data = geocase_case.load()
    assert data is not None

Use GeoCase in your tests

Install the complete set of vector, raster, and NetCDF dependencies:

pip install "geocase[all]"

View GeoCase on PyPI.

What this case checks

Verify that Z survives the GPKG write/read cycle with the same values as the WKB sibling, and that a 64-bit id beyond double precision reads back exactly rather than rounded.

Risk types covered

Expected behavior

Assertion Expected
expect_loadable yes
expect_valid_geometry yes
expected_geometry_types Polygon

Notes

Purpose

The transcoded half of the Z pair, and the half that actually tests a driver. Same ring as polygon_z_wkb, written through OGR into a GeoPackage.

Data

  • Geometry: POLYGON Z ((12.5 55.7 0, 12.52 55.7 12.5, 12.52 55.72 25, 12.5 55.72 12.5, 12.5 55.7 0))
  • id = 9007199254740993, name = polygon_z_gpkg
  • Feature count: 1
  • CRS: EPSG:4326

Why the transcoded copy is the one that matters

GPKG does not encode dimensionality the way WKB does. It lives in a flag byte in each geometry's header, separate from the geometry type. A writer that builds the layer with wkbPolygon rather than wkbPolygon25D produces a perfectly valid GeoPackage containing a perfectly valid polygon — with the elevations gone. Nothing raises. The file opens, the geometry is correct in plan, and the third dimension has simply evaporated.

That is why the generator keys the 2.5D type on a has_z flag rather than inventing a "PolygonZ" string: getting it wrong writes 2D silently, and the only thing that catches it is comparing Z values against the WKB sibling — which is exactly what test_polygon_z_survives_the_gpkg_transcoding does.

The int64 rider

id is 9007199254740993, which is 2^53 + 1: the first integer a float64 cannot represent. Round-tripped through a double it comes back as ...992.

This rides on an existing case rather than getting one of its own, because it needs nothing but an attribute value — GeoPackage stores ids as INTEGER (64-bit), so the loss happens in the reader, not the file. Any library that funnels attributes through floating point (a JSON layer, a naive pandas dtype inference, a JavaScript consumer) loses the last bit here.

The content gate asserts exact equality; approximate comparison would pass the bug it exists to catch.

Typical checks

  • geom.has_z is True, with Z identical to the WKB sibling.
  • int(gdf["id"].iloc[0]) == 9007199254740993 — exactly.

Not a cross-format family member

No canonical_source_case_id, no cross_format_canonical tag. See polygon_z_wkb's notes.

Generation

Generated by scripts/generate_vector_fixtures.py — do not hand-edit. GPKG carries a wall-clock last_change, so --check compares semantics (fields, types, geometry, SRID, size) rather than bytes.

Required capabilities

  • load
  • geometry-inspection
  • attribute-inspection

Files

Browse this case on GitHub

Source and license

  • Source: geocase-curated
  • License: MIT

Tags

dimensionality geopackage integer-precision three-dimensional vector