You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
BReg refuses valid crs84-point coordinates near zero at precision 6 or more #2645
A crs84-point field with precision 6 or more refuses some valid coordinates close to zero, that is, points within roughly 1e-5 degrees (about 1 m) of the equator or the prime meridian. Programme areas on the equator (for example Kenya, Uganda, DRC, Gabon, Ecuador, Indonesia) can hit it.
Cause
coordinate_number in crates/registry-breg/src/contract.rs formats the JSON number with Value::to_string() and passes the text to parse_coordinate, which refuses any exponent (e or E). serde_json writes small magnitudes in exponent form, so 0.000000001 reaches the parser as 1e-9 and is refused even though it has 9 fraction digits and is inside the bounds.
The client-side validator in crates/registry-breg-client/src/actions.rs behaves the same way; the polygon test added in #2644 asserts that [0.000000001, 0.000000001] is refused at precision 9, which pins this behaviour.
Expected
A coordinate is accepted when its value is within bounds and it has no more fraction digits than precision, however serde_json prints it.
Suggested fix
Read the value with as_f64 and count fraction digits from a non-exponent decimal rendering (the polygon path added in #2644 already avoids the exponent problem), and keep refusing exponent notation only where it comes from the submitted text, if that is still wanted. Relax the assertion in actions.rs and add near-zero cases for Point and polygon positions on both the server and client validators.
Activity
docs(breg): note the client geometry break and what a geometry contra…