8000 getIndexDigit and getReservedBits by isaacbrodsky · Pull Request #1024 · uber/h3 · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

getIndexDigit and getReservedBits #1024

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

isaacbrodsky
Copy link
Collaborator

#1022

This adds functions for retrieving index digits and the reserved bits from indexes. The reserved bits may be of interest for directedEdge / vertex mode where knowing which one it is are helpful.

Note that I chose to allow getIndexDigit to read unused digits; we could instead choose to disallow reading those digits from this function as they (probably) shouldn't be used as three-wide bit fields in that case.

Does not have CLI tests just yet.

@coveralls
Copy link
coveralls commented Jun 30, 2025

Coverage Status

coverage: 98.913% (+0.002%) from 98.911%
when pulling c92717d on isaacbrodsky:get-index-digit
into 73cf911 on uber:master.

Comment on lines +326 to +346
<TabItem value="python">

```py
h3.get_index_digit(h, digit)
```

</TabItem>
<TabItem value="go">

```go
cell.IndexDigit(digit)
```

</TabItem>
<TabItem value="duckdb">

```sql
h3_get_index_digit(h, digit)
```

</TabItem>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we sure we want to add these to the docs before they're actually implemented in the bindings?

int H3_EXPORT(getReservedBits)(H3Index h) { return H3_GET_RESERVED_BITS(h); }

/**
* Returns the index digits at `digit`, which starts with 1 for resolution
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would use "resolution" here to specify the function input, and "digit" as the fu 8000 nction output. I think that's more in line with how we use resolution elsewhere.

From the docs:

This is followed by a sequence of r digits 0-6, where each ith digit di specifies one of the 7 cells
centered on the cell indicated by the coarser resolution digits d1 through di-1. A local hexagon
coordinate system is assigned to each of the resolution 0 base cells and is used to orient all
hierarchical indexing child cells of that base cell. The assignment of digits 0-6 at each resolution
uses a Central Place Indexing arrangement (see [Sahr, 2014](http://webpages.sou.edu/~sahrk/sqspc/pubs/autocarto14.pdf))

But maybe that's just me. What do others think?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally, a variable named res or resolution indicates to the user that it is an integer taking values 0--15. (In this case, its a little more restrictive at 1--15.) And digit indicates something taking values 0--6 (or 7 to indicate an invalid digit). I'd keep that same convention here.

Elsewhere in the codebase, we use res as the second argument to the H3_GET_INDEX_DIGIT macro, like here:

if (res == 0 || H3_GET_INDEX_DIGIT(cell, res) != CENTER_DIGIT) {

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As does the macro definition:

#define H3_GET_INDEX_DIGIT(h3, res) \

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants
0