A Projection cannot tell an omitted parameter from an explicit zero. Both are 0.0 in the same field by the time initialize() runs. Proj4Parser can tell them apart, because it still has the map: params.get(key) == null. Six operators needed that distinction and did not have it, so each one answered a question the caller never asked - two of them with a wrong coordinate, four of them where PROJ refuses. Two of the six returned wrong numbers. leac set no parallel of its own, so both came from AlbersProjection's constructor - 45.5 and 29.5 degrees, the conterminous-US pair. A bare +proj=leac therefore ran the cone (+90, 45.5) where upstream runs (+90, 0), because aea.cpp:222 reads rlat_1 with no presence test and an absent +lat_1 is 0 there. At (12, 56) on +ellps=WGS84, forward, proj 9.8.1 answers (553194.816514914, 7476320.691195731); we answered (720787.420562720, 5760346.894499558), which is PROJ's +lat_1=45.5 answer. 1,724 km. Fixed in the constructor, zeroing both fields, because this is a wrong default and not a missing presence test: absence and an explicit +lat_1=0 are one input upstream and must stay one input here. wag1 is urmfps with n assigned by the operator rather than read from the definition - urmfps.cpp:71-81 calls no pj_param and writes 0.8660254037844386467637231707 itself. Wagner1Projection extends UrmaevFlatPolarSinusoidalProjection to reuse the kernel and so inherited its setN, which an instanceof dispatch then called. At (10, 55) on +ellps=GRS80, +proj=wag1 +n=0.5 returned (891018.067867611, 6135305.446220606) where PROJ returns (688376.287161978, 6620055.430083310) with or without the +n: 202,641.78 m too far east, 484,749.98 m too far south, 525,401.03 m in a straight line, from a key PROJ never reads. The +n dispatch is now guarded by operator name, the way the utm branch already is. Bare +proj=wag1 was right all along, which is why the test compares the two spellings rather than checking one of them. Four answered where PROJ refuses. urmfps urmfps.cpp:56-59 tests +n for presence. Our class holds sqrt(3)/2 in that field - wag1's hard-coded value - so a bare +proj=urmfps answered as +proj=wag1 instead of refusing. Now MISSING_PARAM. geos geos.cpp:206 reads "dh" with no presence test and :226-230 refuses h/a <= 0, so an omitted +h and an explicit +h=0 are the same input upstream and are refused together - which is exactly what builtins.gie:2183 asserts. We held 35785831 m, the nominal geostationary height, so a bare +proj=geos answered from a satellite the caller never named. The field default is now 0 and initialize() rejects h/a <= 0 or > 1e10. Because upstream cannot tell absence from zero either, this is a value test in initialize() and not a presence test in the parser, and the cause is INVALID_PARAM_VALUE to match upstream's own errno. The constructor no longer calls initialize(), as LambertConformalConicProjection's already does not, or it would throw before the parser could assign +h. gn_sinu gn_sinu.cpp:180-188 tests +n and then +m for presence before reading either. The m half could not have been caught by a value test, which is where it used to be: m = 0 is legal upstream, so +n=1 on its own passed the m < 0 test and answered where PROJ says "Missing parameter m." Upstream's order is kept, because it is observable - a bare +proj=gn_sinu reports the missing n, not the missing m. imw_p imw_p.cpp:36-41 tests both parallels for presence. The two value tests catch an absent pair, because both halves are then 0, but not exactly one absent: +proj=imw_p +ellps=GRS80 +lat_1=30 left lat_2 at 0, passed both tests with del = sig = 15 degrees, and answered. PROJ says "Missing parameter: lat_2 should be specified". An explicit +lat_1=0 is legal and even selects its own code path, PHI_1_IS_ZERO at imw_p.cpp:207, so this cannot be a test on the value 0. Every refusal is tested from both sides. The over-refusal controls are as much the point as the refusals: +proj=wag1 +n=0 and +n=-1 are legal upstream because wag1 never reads the key, +proj=gn_sinu +m=0 is legal, +proj=imw_p +lat_1=0 +lat_2=10 is legal, and +proj=leac +lat_1=0 must agree with bare +proj=leac bit for bit. A guard that refused any of those would trade upstream's defect for one of our own invention. One pre-existing mismatch is named and deliberately left alone. imw_p's two presence throws carry INVALID_PARAM_VALUE because upstream sets PROJ_ERR_INVALID_OP_ILLEGAL_ARG_VALUE for them (imw_p.cpp:38, :41), while the sconics presence check a few lines above raises MISSING_PARAM where upstream also sets ILLEGAL_ARG_VALUE (sconics.cpp:49, :52). Upstream draws no distinction between the two families here - the 9.8.1 CLI reports Error 1027 for a missing parallel on imw_p and on all seven sconics members. Nothing observable turns on it: no coordinate changes, the only ErrorCause the conformance bridge branches on is MISSING_GRID, the golden gate reads none, and no test pins a cause for either family. Correcting sconics is a separate change. conformance: the oracle side needed the same six rules, or the bridge would score our new refusals as disagreements. ProjOperatorSetup gains geos, urmfps, gn_sinu and imw_p transcriptions, each with its upstream line numbers, and 42 new oracle rows assert them. wag1 is deliberately not routed there: it shares urmfps_setup but is a separate PROJ_HEAD that reads no keyword, so bare +proj=wag1 and +proj=wag1 +n=-1 are both ACCEPT rows. golden: two new rules, PROJ-GEOS-REQUIRES-A-POSITIVE-H-RATIO and PARSE-URMFPS-REQUIRES-N, five rows each. Three rows change sides, all three `SYN proj/geos` - probes 0, 1 and 2 matched the baseline exactly and now raise - so UNCHANGED 12005 -> 12002, CHANGED 41425 -> 41428 and INTENDED 39138 -> 39141. Which three is measured, not assumed: replaying the five probes with the old class default written out by hand reproduces the pre-change rows exactly, and probes 0, 1 and 2 come back byte-identical to golden.tsv while 3 and 4 differ in the last two bits of the inverse latitude. UNEXPLAINED does not move. Two existing rules lose rows to the new ones and are re-pinned for reasons written out at each rule: PROJ-INVERSE-CORRECTED-ROUND-TRIP-NOW-EXACT-FWD-ALSO 45 -> 40 (the five urmfps rows are now OK -> EXC and that rule requires OK -> OK) and NUM-KARNEY-LATITUDE-CORE 19310 -> 19308 (two geos rows, same reason). 10 claimed by new rules, minus 5, minus 2 lost by old ones, is the +3. Also corrected, all measured in this worktree rather than computed: - RegistryRoundTripAuditTest's REQUIRED gains geos and urmfps, since neither can now be built from +proj=<name> +ellps=GRS80 alone; eighteen -> twenty. Refused probes 303 -> 304 and round-trip assertions 7,993 -> 7,992. - The same class said "30 of the 122 fail" while PINNED has held 29 entries. The table was right and the prose was stale; it now says 29. - .github/workflows/golden.yaml quoted 39,134 INTENDED / 2,291 UNEXPLAINED, stale since the +proj=tmerc +zone re-pin, and "rules.yaml carries 44 rules" where an anchored grep says 48. Both corrected, with a note that this copy is prose and that the assertion lives in golden-expect.txt. - NewOperatorContractTest cited imw_p.cpp:208-212 for PHI_1_IS_ZERO; it is :207. Gates, all four in the pinned container: ci PASS 2628 tests, 0 failures (master at 1ca611c: 2620, so +8, which is exactly the 8 test methods added) conformance PASS 7446/7900 genuine passes, regressed 0 - unchanged golden FAIL(expected) 2287 UNEXPLAINED, 48/48 rules pinned, and zero hits for each of FIGURES_MOVED, COUNT_MISMATCH, DEAD_RULE, EXPIRED_RULE and PENDING_RULE_FIRED determinism PASS 22 tests, 0 failures Closes locationtech#114 Closes locationtech#115 Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

Will there be support for cct. #114

Description

Activity

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions