cellAreaRads2 CLI rounds valid high-resolution cell areas to zero
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 50/100
Research direction
The rounding happens in the CLI output formatter in src/apps/filters/h3.c (around lines 2541-2558), which prints with %.10lf. Reproduce with h3 cellAreaRads2 -c 8f283082800b3b0 and compare against cellAreaM2. Done means small areas keep significant digits, but the maintainers have not yet chosen between scientific notation and an explicit precision option, so confirm that choice before editing.
Written by the indexing model from the issue text.
Description
On master at 15920096, the CLI reports zero area for a valid resolution-15 cell:
h3 isValidCell -c 8f283082800b3b0
# true
h3 cellAreaRads2 -c 8f283082800b3b0
# 0.0000000000
h3 cellAreaKm2 -c 8f283082800b3b0
# 0.0000009299
h3 cellAreaM2 -c 8f283082800b3b0
# 0.9298805669
All four commands exit successfully. Calling the native cellAreaRads2 function for that same cell and printing the returned double with %.17g yields 2.2909255855606226e-14, so the area is lost when formatting CLI output, not in the area calculation.
The CLI formatter uses %.10lf. In a small check of cells around San Francisco, this rounded areas at resolutions 12–15 to zero; at resolution 11 it printed 0.0000000001 for an area of 5.5005201384148946e-11. Scripts using the square-radian result for area sums or ratios can therefore get zero or substantially inaccurate values even though the cell is valid.
The command has no --format option; -f json and -f newline are rejected. Its help describes the result as the exact area. The documentation shows a fixed-decimal example, but I did not find a stated output-precision guarantee.
Would preserving significant digits (allowing scientific notation for small values) be acceptable here, or would an explicit precision option be preferable for output compatibility?
Reproduced with a directly compiled native CLI and native-library comparison on Linux/GCC 14.2, from unchanged source. No patch or full CMake/CTest run yet. This concerns CLI formatting, not the separate antimeridian calculation fixed in #1274.
- Dominant language
- C
- Stars
- 6.7k
- Forks
- 658
- Avg merge
- 5d 21h
- Merged PRs (30d)
- 12
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from uber/h3
-
polygonToCells CLI silently drops vertices when whitespace precedes a coordinate's closing bracketOpen
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
Maintainers usually reply within 1 day
-
cellsToMultiPolygon: int64_t counts are narrowed to int struct fields without a bounds checkPossibly taken @madib06ops claimed this 30 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
Maintainers usually reply within 1 day
-
Difficulty 3/5 Half a day Newbie friendliness 45/100
Maintainers usually reply within 1 day
-
Difficulty 3/5 Half a day Newbie friendliness 45/100
Maintainers usually reply within 1 day
Similar issues
-
Status: Opened
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
FriendsofECCE/ECCE#1018 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
immortalwrt/immortalwrt#2522 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
severity: low
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
luainkernel/lunatik#2530 ·
Maintainers usually reply within 1 day