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

Polygon insertion #24

Open
Nexuist opened this issue Jun 20, 2018 · 1 comment
Open

Polygon insertion #24

Nexuist opened this issue Jun 20, 2018 · 1 comment

Comments

@Nexuist
Copy link

Nexuist commented Jun 20, 2018

Hiya,

I’ve been toying around with this lib for a few days and it’s been fantastic to use! My one main concern is that I can only put down points. I can obviously have a data structure where the primary key reflects the center of my polygon and all the points making up the sides are included in a companion array, but then the problem is that if my polygon is adequately big enough (I’m using a hash key length of 7, so if my polygon expands >1km) the center point won’t get caught in any radius queries and so the polygon won’t get returned in my results.

The way I was thinking of going about it is to drop “reference points” wherever a polygon point is present (if it’s in a different geohashed area than the primary key of the original polygon item) that contains a reference to the hash / range key of the original item. Then, once the results come back, you could do an additional BatchGetItems for all the reference points to obtain the original polygons. I’m sure there’s a better way to do it, but that’s my $0.02. Let me know what you think!

@robhogan
Copy link
Owner

That could work. It's a shame DynamoDB doesn't support indexing on set type values, otherwise we could store the set of touched hashkeys on the polygonal record itself and query that. Your proposal essentially amounts to using many-to-one lookup records (reference points), which is what Amazon recommends in this scenario (eg querying blog posts by a specific tag), albeit they recommend using a separate table for it.

Unfortunately though this is outside my use case and it's more work/complexity than I've got time for at the moment. I'd be interested in the results if you want to have a go in a fork though.

Of course, a very simplistic approach if your use-case fits would be to make your radius queries bigger by the maximum "radius" of your polygons - that way the centre point would always get caught, and you'd just have false positives you could filter out client-side. It's not a perfect solution by any means but could work if your polygons have a reasonable upper limit on their size.

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

2 participants