Integration of space into the rustsim organization.

[sebcrozet]

Hi @vadixidav!

This is a follow-up to our discussion on Discord regarding the potential integration of space into the rustsim organization.

While currently light, the feature set of this crate are very useful, and its long-term goals interesting. After reviewing this project, here are a some improvements we could work on before actually adding space to the rustsim organization. This is a macro list, which could be broken down into several smaller issues. Of course, everything is open to discussion:

• [x] Add the #![deny(missing_docs)] directive. Everything in the crate should be documented, even if it is minimal.
• [ ] Add doc-tests to every method on space. I think it is best to think about it from the beginning since it is pretty overwhelming to have to add them all at once after the crate grows.
• [x] The current naming of octree seems confusing. I think it would be clearer if Linear and Pointer were replaced by something like LinearOctree and PointerOctree.
• [ ] To avoid redundancy between the ncollide crate and the space crate, I believe we should migrate the content of the partitioning module from ncollide to space if that makes sense to you. We should list in a separate issue what are our options to unify the various traversal methods (visitors, and best-first search methods).
• [ ] After the migration mentioned in the previous task, we need to figure out what to do with that page: https://www.ncollide.org/bounding_volumes/#spacial-partitioning Maybe ncollide will just re-export the type/traits from space and we will keep this section as-is. Maybe this section will be more focused on space itself. Or maybe this should be in a separate user guide.
• [ ] In order to be featured on https://rustsim.org, the space crate will need a logo (even if it is temporary).

Doing all this will probably take a fair amount of time (perhaps a couple of months) but I think this is worth it as it will increase the quality of this crate and its documentation. I will contribute too of course.

If that's okay with you, I will link this issue into the next monthly rustsim newsletter so potentially attract contributors.

[vadixidav]

Thank you for giving me some pointers on what is necessary to add the library to rustsim. This weekend I should have some time to start hacking at some of these things. Clearly more work does need to be done here to transport the library into something really usable (like good documentation). I will start by pulling off some of the documentation and test related issues first before trying to bite off combining the partitioning module from ncollide in a way which unifies the ways the spatial tree is queried. Once I get to that part I will start opening the relevant issues.

In order to be featured on https://rustsim.org, the space crate will need a logo (even if it is temporary)

I will look into that.

If that's okay with you, I will link this issue into the next monthly rustsim newsletter so potentially attract contributors.

Please do! I haven't properly tagged my issues yet, but many of them are simply building out new spatial tree types. I can look into tagging them appropriately based on difficulty.

[vadixidav]

Status update

I am currently loaded up with fixing up photogrammetry crates in the Rust community. I will eventually finish that, get back to a hamming weight tree datastructure I am writing (and speeding up), then finally I intend to make the space crate a set of common traits and APIs for interacting with spatial trees in other crates (including hwt). I will split out any code from space into other crates for their purpose and implement the traits in space on those datastructures. Space will ultimately probably provide abstractions over distance metrics, ANN data structures, search radius, nearest neighbors, and search area. This will basically be like alga, but for spatial datastructures. I intend to use alga alone if possible to allow interaction with other crates than nalgebra, such as ndarray, and anything else that may come up in the future.

So, I really do want to get back to this, but I am down in the weeds of Rust photogrammetry for the time being until there are usable tools for those things. I think I can probably make the abstractions here in about 1-3 months, which will just depend on what order things happen in. I do intend to work on space immediately after hwt is finished to my liking, which will be a good exercise because hwt is working in Hamming space (defined by Hamming distance, which is basically just L1 with binary distances and positions).