Rob Hogan

Thank for the reports - that's definitely way more queries than it should be generating and very likely to be the cause of poor performance. We rely on a combination...

Having looked into this I think the issue is just the length of the partition key. In DynamoDB you can only query within a single partition key (of a table,...

> Also, this library doesn't appear to use BatchGetItem (unless I am mistaken) for all the queries, which causes more network overhead. This lib uses [`Query`](http://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Query.html) for radius/box searches and...

Version 0.3.0 introduces a new default `hashKeyLength` of 2. By my reckoning that's large enough unless large proportion of a >10gb data set is in one small area (like a...

You will need to rebuild your data, it's used to generate the hash key on insertion too. I've also changed the longitudeFirst default to true for geoJson compatibility, in a...

I've just learnt that a small `hashKeyLength` may have RCU implications - see [the new docs](https://github.com/rh389/dynamodb-geo.js#choosing-a-hashkeylength-optimising-for-performance-and-cost).

That's surprising - calculating distances between lat/lon pairs is computationally pretty easy (with Haversine). It may be that we're going back and forth between coordinate systems too much, there's definitely...

I don't have time to work on this right now but I'd love to see it - the current API feels very clunky and non-JS compared to the document client.

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...

Hi @igorescobar. Thanks for this - looks like a good start and should be backwards compatible. Do you want to make a PR out of it?