Any way to know what B-Tree or Geohash bucket an object is inserted into?
luke
geohashing with b-trees, but I'm working on the assumption that,
ultimately, things are stored in geographic "buckets" in MongoDB, and
the B-Tree is used to find these buckets. I've seen MongoDB refer to
regions with a long binary string (see
http://www.mongodb.org/display/DOCS/Geospatial+Indexing#GeospatialIndexing-geoNearCommand),
which I'm assuming is the path to a b-tree bucket or maybe a geohash.
Can someone please correct me if I'm wrong?
I'm wanting to store some meta-data about geographical regions and tie
them to the buckets that MongoDB uses. So what I'd like to know is
which bucket an object gets inserted into in MongoDB so I can update
my meta-data about that bucket.
Basically, what I'd like is for an insert to return this geohash
string. Is this possible?
Richard Kreuter
the wikipedia article:
http://en.wikipedia.org/wiki/Geohash
To summarize, mongodb computes a geohash from a coordinate pair in a
document and uses that quantity as key to identify the document.
Because of the way geohashes map pairs to scalars, wider and wider
segments of the B-tree correspond to larger and larger rectangles in the
coordinate space, but there aren't any meaningful "regions" stored in
the B-tree.
For your problem, can you describe the semantics a little more? What
are your geographical regions?
Regards,
Richard
> --
> You received this message because you are subscribed to the Google Groups "mo
> ngodb-user" group.
> To post to this group, send email to mongod...@googlegroups.com.
> To unsubscribe from this group, send email to mongodb-user+unsubscribe@google
> groups.com.
> For more options, visit this group at http://groups.google.com/group/mongodb-
> user?hl=en.
>
luke
If you imagine the world divided up into a grid, with each cell
subdivided further, recursively, so that you have grids of several
levels of granularity. It is my understanding that a geohash string
points to a particular location and if you shorted it slightly it
points to a grid cell of coarser granularity, and shortening it
further will do so again. In short, taking a prefix of a geohash
points to a broader area. I feel I more or less understand geohashing
but how MongoDB ties those in with B-Trees I wasn't sure. Based on
your explanation I think that I should be interested in the geohash
rather than the B-Tree.
Can I get the geohash that MongoDB ascribes to an inserted document?
I can't talk too much about the exact nature of my problem, but I can
make up an analogous one: imagine I want to have a webpage with
information about an area of the world, on which I list items that are
pulled from MongoDB associated with that area. To completely
oversimplify things, let's say a MongoDB document's geohash is
"00011101". I'd like to know that geohash after inserting the
document, and then be able to infer that it's in a bucket "0001110",
which is within "000111", and so on, and I'd like to have web pages
about each of those areas, which will cover broader and broader
geographical areas. I wouldn't be manually creating these pages for
geographical areas, they'd be generated from a geohash prefix (such as
000, 000111, 0001110, etc.) and populated from the documents in
MongoDB.
Hmm this is really hard to explain :/ I hope it makes sense!
On Feb 9, 5:20 pm, Richard Kreuter <rich...@10gen.com> wrote:
> This isn't really how geohashing works. For background I'd recommend
> the wikipedia article:
>
> http://en.wikipedia.org/wiki/Geohash
>
> To summarize, mongodb computes a geohash from a coordinate pair in a
> document and uses that quantity as key to identify the document.
> Because of the way geohashes map pairs to scalars, wider and wider
> segments of the B-tree correspond to larger and larger rectangles in the
> coordinate space, but there aren't any meaningful "regions" stored in
> the B-tree.
>
> For your problem, can you describe the semantics a little more? What
> are your geographical regions?
>
> Regards,
> Richard
>
>
>
>
>
>
>
> luke writes:
> > Firstly, I admit that I don't understand exactly how MongoDB combines
> > geohashing with b-trees, but I'm working on the assumption that,
> > ultimately, things are stored in geographic "buckets" in MongoDB, and
> > the B-Tree is used to find these buckets. I've seen MongoDB refer to
> > regions with a long binary string (see
Richard Kreuter
It sounds like your handle on what we do with geohashes is correct. We
don't expose the geohashing internals directly mostly because the the
rectangles defined by prefix/precision pairs don't really correspond to
anything meaningful in the world; they're just used for constraining
(and so, in common cases, speeding up) searches.
If you wanted to tag nested boxes in your space with attributes, I'd
suggest having a separate collection of box/attribute associations, and
to use that for describing the points in your application's display, if
that makes sense.
--
Richard