Feature request: A5 cell support as object/search type

[XanderD99]

Problem

Tile38 supports Geohash, QuadKey, and XYZ tiles as cell-based object and search types, but no modern DGGS. A5 is a pentagonal DGGS (comparable to S2/H3) with equal-area cells at every resolution, low distortion, and cell IDs encoded as a 64-bit integer — a good fit alongside the existing tile/hash types. Related: #780 asks about H3 support; A5 has the practical advantage of a native Go implementation (no CGO), unlike H3's C bindings. GitHubA5geo

Proposal

Support A5 cells wherever Geohash/QuadKey work today:
SET fleet truck1 A5 3778472949142978560 # set object as an A5 cell
WITHIN fleet A5 3778472949142978560 # search by cell area
INTERSECTS fleet A5 3778472949142978560
NEARBY ... / FENCE ... # fences over cell areas
Internally a cell resolves to its pentagon boundary (polygon), so it can reuse the existing geometry path — same way QuadKey/tile areas are handled.

Implementation note

Native Go port exists: github.com/akhenakh/a5-go (no CGO). Reference implementations in TS/Python/Rust at a5geo.org for cross-validation.

[felixpalmer]

A5 author here, happy to answer any questions. Would be great to see A5 included in tile38

[tidwall]

As long as the A5 pentagon can be represented as simple feature polygon then yes, it should be a compatible Tile38 type.

[tidwall]

While goofing around with A5 in the Tile38 I noticed that this input crashes the process:

INTERSECTS fleet IDS A5 1

Not sure what happening, but it appears to be broken with the imported library.

Is a cell id suppose to alway be 16 hex characters such as "0x6100000000000000" or "6100000000000000"?
Or can it be truncated to "61"?

Also there's no way to query an A5 cell without providing the input type. I think this is due to the output and area fields are the same, both "A5", so the parser can't tell the difference.

For example, these are currently different queries.

INTERSECTS fleet A5 1 BOUNDS 10 10 20 20
INTERSECTS fleet IDS A5 1
INTERSECTS fleet A5 1

The first on queries the BOUNDS 10 10 20 20 returning everything that intersects as an A5 cell with precision 1.
The second queries the A5 cell id 1 returning everything that intersects as only the object ID.
The third fails with ERR wrong number of arguments for 'intersects' command

I suggest we change the output type to "A5S" (instead of "A5"), which matches some of the other output types, such as POINTS, IDS, HASHES, and OBJECTS. This should remove the ambiguity.

[XanderD99]

That is indeed a better approach then what I currently implemented.

The errors most likely originate in the fact that I assume (guess) the format so using it incorrectly will not yield the desired results. I thought I covered those cases but very clearly I did not.

I am currently reusing the same piece of code for the return format and the cell filter which is incorrectly assuming the desired format. Since I firstly check for valid number integer values it assumes you A5 to be a return format instead of being a cell.

I'll adapt it asap.

[felixpalmer]

The cell id is always a 64bit integer, you can’t remove the trailing zeroes. The hex representation is mainly meant for formats which can’t represent 64 bit integers (like JSON). If possible it is best to use an integer where possible as passing around hex strings takes more memory