s2geometry VS tg

I experimented with geospatial Hilbert Curves as a Postgres extension [0] for PostGIS using the S2 [1] spherical geometry library. S2 uses a scale free cell coverage pattern that is numbered using six interlocking space filling Hilbert Curves [2].

By having both high level (cell) and low level (cell id) geometries it was a very powerful library which allowed projection from the hilbert space into a Postgres spatial index (spgist) including various trees, like noted in this article. It appears to be still quite active in development.

[0] https://github.com/michelp/pgs2

[1] https://s2geometry.io/

[2] https://s2geometry.io/devguide/s2cell_hierarchy

If you check the h3geo comparison page, you should see plenty of alternatives to geohash, such as s2 or even h3 itself.

See some discussion I started at https://github.com/google/s2geometry/issues/190

> It was quite hard for me to find open-source implementations of linear quadtrees.

You probably know this, but the S2 library has one: https://github.com/google/s2geometry

https://s2geometry.io shows how this works

If your points are distributed globally, however, I'd suggest using something like s2geometry (calculates over a sphere instead of an ellipsoid which is much faster + already has something called S2ClosestPointQuery).

Some alternative solutions are S2 from Google and H3 from Uber. These don't have the same issues as geohash because they work on a 3-d model of the geoid and not a 2-d cylindrical projection like Geohash.

Thanks for sharing! I've looked into usearch before, it's really sleek, especially all their language bindings. Though I want sqlite-vec to have total control over what stays in-memory vs on-disk during searches, and most vector search libraries like usearch/hnswlib/faiss/annoy either always store in-memory or don't offer hooks for other storage systems.

Additionally, sqlite-vec takes advantage of some SQLite specific APIs, like BLOB I/O [0], which I hope would speed things up a ton. It's a ton more work, coming up with new storage solutions that are backed by SQLite shadow tables, but I think it'll be work it!

And I also like how sqlite-vec is just a single sqlite-vec.c file. It makes linking + cross-compiling super easy, and since I got burned relying on heavy C++ dependencies with sqlite-vss, a no-dependency rule feels good. Mostly inspired by SQLite single-file sqlite3.c amalgamation, and Josh Baker's single file C projects like tg[1].

[0] https://www.sqlite.org/c3ref/blob_open.html

[1] https://github.com/tidwall/tg

I can't stop precision loss in all cases, but I do my darnedest to avoid loss when it causes false positives, especially for stuff like intersect detection code. For example the collinear [1] function looks really big for a seemingly simple operation, but there are extra checks built in to check for precision loss and in the cases of compiler associate math issues (like a user borking a build with -ffast-math).

I'm sure it's not all perfect but I feel pretty good about it overall. It certainly helps that much of the logic derived from the Tile38 [2] project, which has 8 years of use in production. I ported many of tests too, which makes me warm and fuzzy every time they pass.

[1] https://github.com/tidwall/tg/blob/v0.1.0/tg.c#L389