Skip to content

Story: Preserve representation equality with numeric ordinate equivalence #64

Closed

Description

@Alexandre-T

Preserve representation equality with numeric ordinate equivalence

As a consumer of spatial point values,
I want equalsTo() to compare point representations without distinguishing equivalent integer and floating-point ordinates,
so that numeric storage choices do not change equality while spatial context and coordinate layout remain significant.

Context

This Story addresses the approved equality correction from finding R3 in
Story #26.
PointBehaviorTrait::equalsTo() currently compares ordinates strictly, so
points represented by (1, 2) and (1.0, 2.0) compare unequal.

On 2026-10-30, Alexandre approved representation equality with numeric
equivalence between integers and floats. Different SRIDs, Geometry/Geography
families and declared dimensions remain unequal, even when additional Z/M
ordinates are null or zero. This is an approved correction to observable API
behavior before 1.0.0.

This Story does not settle the remaining R3 questions about geometric
predicates' XY/3D semantics. Correcting representation equality alone must not
be reported as resolving all of R3.

Acceptance Criteria

  • Within otherwise matching point representations, corresponding integer and floating-point ordinates with the same numeric value compare equal, including 1 and 1.0, in both comparison directions.
  • Numeric equivalence applies to every represented ordinate: X, Y, Z and M where present.
  • Different numeric ordinate values remain unequal; equality introduces no approximate tolerance.
  • A null ordinate remains distinct from numeric zero; matching partial-null representations retain their existing equality behavior.
  • Points with different SRIDs compare unequal, even with identical coordinates.
  • Geometry and Geography points compare unequal, even with identical coordinates and SRIDs.
  • Different declared coordinate layouts compare unequal, including XYZ versus XYM, and XY versus higher-dimensional layouts whose additional ordinates are null or zero.
  • EMPTY point comparisons preserve the existing representation-context distinctions; a non-EMPTY point never equals an EMPTY point.
  • The approved behavior is consistent across mutable and immutable point APIs without changing the existing concrete-class compatibility rule.
  • Equality comparisons preserve the original ordinate values and their stored integer, float or null types.

Constraints

  • equalsTo() remains representation equality, not topological or spatial equality; no coordinate transformation or dimension normalization is introduced.
  • Changes to public signatures, concrete-class compatibility, or independent geometric XY/3D contracts are outside this Story.
  • Existing callers of equalsTo() may observe the approved numeric equivalence. Their effects must be assessed without silently defining unresolved closure or simplicity contracts.

Definition of Done

The project's common Definition of Done applies.

  • composer test-local passes.
  • composer quality passes.
  • Explicit regression tests cover XY, XYZ, XYM and XYZM, both families and mutable/immutable variants, including numeric equivalence and the preserved distinctions above.
  • Regression tests demonstrate the original integer/float failure and verify that comparisons leave both operands unchanged.
  • Call sites used by closure and simplicity are reviewed, and any behavior change caused by numeric equivalence has focused regression coverage.
  • Public documentation and the Story Story: Review normative conformance for spatial-types 1.0.0 #26 conformance matrix describe the approved equality contract and distinguish this correction from the remaining R3 predicate questions.

Metadata

Metadata

Assignees

No one assigned

    Labels

    impact:apiAffects the public APIimpact:breakingIntroduces a backward-incompatible changespatial:geometryRelated to geometry models or typesstandard:complianceImproves or restores standards compliance

    Type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions