Skip to content
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

Question: Why there is parameters verification that point dimension must be at least 2? #111

Closed
ytskuh opened this issue Feb 11, 2023 · 4 comments

Comments

@ytskuh
Copy link

ytskuh commented Feb 11, 2023

I would like to create a R*-tree for points that could have a single dimension, but it says "thread 'main' panicked at 'Point dimension too small - must be at least 2'"

@urschrei
Copy link
Member

Could you explain more about what you're trying to achieve? Preferably with a minimal reproducible example. I mostly work with geometries in R2, so I have to admit that I simply don't understand the phrase "points that could have a single dimension".

@michaelkirk
Copy link
Member

I'm not sure it makes sense to use an RTree for less than 2 dimensions.

If I wanted to efficiently insert and query over a 1 dimensional range, I think I'd use a btree:

https://doc.rust-lang.org/stable/std/collections/struct.BTreeMap.html#method.range

Or do you mean that your points will be a mix of 1 and 2(+) dimensions?

@ytskuh
Copy link
Author

ytskuh commented Feb 13, 2023

I am working with a program that works with problems could be set in different dimensions - I just want to solve all situation with the same piece of code. It's right that btree or other solution is better for one dimensional problem. And I have found the crate that is more suitable for me (kd_tree)

@ytskuh ytskuh closed this as completed Feb 13, 2023
@grovesNL
Copy link
Contributor

@urschrei I have a use case where I currently use a BTreeMap<u32, u32> to represent intervals (key as the start, value as the end). It's really read heavy because I do a lot of range queries over it to see which intervals overlap. I think a one-dimensional RTree could be a better alternative for this use case and I'm currently attempting to do performance testing, but ran into this point dimension limitation. I'm going to work through it on a fork so I can test it out anyway, but just wanted to mention my use case here.

@michaelkirk BTreeMap is good but there are optimizations you can apply with a 1D bounding box/envelope that wouldn't apply to a generic BTree. My intuition is that a 1D r*-tree could perform better, but I haven't confirmed this yet.

@grovesNL grovesNL mentioned this issue Jun 27, 2024
2 tasks
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

No branches or pull requests

4 participants