GeoPtProperty and filter in query

[Jean-Francois Noel]

I guess I'm missing something but when I apply a filter with < and >
on a property GeoPt it is just applying to the latitude part of the
property. I looked at the geodatastore sample and a large part of the
code is just to handle boundingBox in python instead of in query.

What am I missing? or if I'm not missing anything, then when will it
be changed?

I was under the impression a scheme of coding like geoHash was applied
for the index.

[ryan]

you're right. GeoPt properties are compared first by latitude, then by
longitude:

http://code.google.com/appengine/docs/datastore/typesandpropertyclasses.html

richer operations for 2D points would be great, and techniques like
geohashing would definitely be appropriate. a few other threads have
already discussed this, e.g.
http://groups.google.com/group/google-appengine/browse_thread/thread/5d9afeac73f53eed/b0862dd41af0319b
.

[Barry Hunter]

Just to follow up on this, geohashes do indeed work. I have a modified
'geodatestore' app that can do 'nearby' queries using geohash.

http://geodatastore2.appspot.com/

Example output:
http://geodatastore2.appspot.com/gen/request?operation=get;output=kml&center=-106.962,40.9881

Code:
http://svn.nearby.org.uk/google_appengine/trunk/geodatastore/
(The first checking should be as the offical sample, contains my
experiments, which are later removed)

... Its very primitive at the moment it uses a fixed radius - intend
to finish it off at somepoint to do arbitry radiuses, probably using a
binary search on the precision. Got very distracted with lots of silly
little errors (python noob) that kinda lost interest.

--
Barry

- www.nearby.org.uk - www.geograph.org.uk -

[Jean-Francois Noel]

Sorry Barry for my late reply, but how do you cope with the limit case of geohash? From the code I'm reading you are filtering for a large part of the geohash and then do the bounding box like in version 1.0.

--
Jean-François Noël
http://www.seeyourhotel.com

[Barry Hunter]

On Mon, May 12, 2008 at 3:40 PM, Jean-Francois Noel <jfn...@gmail.com> wrote:
> Sorry Barry for my late reply, but how do you cope with the limit case of
> geohash? From the code I'm reading you are filtering for a large part of the
> geohash and then do the bounding box like in version 1.0.

Yes.

The geohash is just used to get a rough bounding box first - to save
having to grab the whole world. With a reasonably small radius it
should be allow you get a specific enough box, that the 1000 results
it does return stand a better chance of being selected. Of course it
depends on the density of your data if you can get a suffiently small
bbox, that the results you want will always be in the box.

If need more accuracy you could implement a proper quadtree which then
isnt limited to charactor limits of geohash, or even better would be a
r-tree index that can do proper bboxes. I dont know the specifics of
r-tree implementation, but under the datastore it might need unions,
which would then start getting even slower...

[CarstenN]

I might be a bit late, but I discovered this topic only recently. The
geohash idea sure sounds interesting.

One of the problems I see, is that you'll need up to 4 queries (or
rather different "prefixes") to cover the whole target area while
still keeping the result set small. Take one of the worst cases: two
locations that are very close to each other, yet on different sides of
the equator. They'll have totally different hashes and wont even share
the first character.

The difficulty isn't really limited to the equator either, because
similiar situations can appear all throughout the hash before you
reach sufficient depth.

Any clues?

On May 12, 5:09 pm, "Barry Hunter" <barrybhun...@googlemail.com>
wrote:

> On Mon, May 12, 2008 at 3:40 PM, Jean-Francois Noel <jfn...@gmail.com> wrote:
> > Sorry Barry for my late reply, but how do you cope with the limit case of
> >geohash? From the code I'm reading you are filtering for a large part of the

> >geohashand then do the bounding box like in version 1.0.
>
> Yes.
>
> Thegeohashis just used to get a rough bounding box first - to save

> having to grab the whole world. With a reasonably small radius it
> should be allow you get a specific enough box, that the 1000 results
> it does return stand a better chance of being selected. Of course it
> depends on the density of your data if you can get a suffiently small
> bbox, that the results you want will always be in the box.
>
> If need more accuracy you could implement a proper quadtree which then

> isnt limited to charactor limits ofgeohash, or even better would be a

> r-tree index that can do proper bboxes. I dont know the specifics of
> r-tree implementation, but under the datastore it might need unions,
> which would then start getting even slower...
>
>
>
>
>
> > --
> > Jean-François Noël
> >http://www.seeyourhotel.com
>

> > On Sat, May 3, 2008 at 5:30 PM, Barry Hunter <barrybhun...@googlemail.com>

> > wrote:
>
> >> Just to follow up on this, geohashes do indeed work. I have a modified
> >> 'geodatestore' app that can do 'nearby' queries usinggeohash.
>
> >>http://geodatastore2.appspot.com/
>
> >> Example output:
>

> >>http://geodatastore2.appspot.com/gen/request?operation=get;output=kml...

>
> >> Code:
> >>http://svn.nearby.org.uk/google_appengine/trunk/geodatastore/
> >> (The first checking should be as the offical sample, contains my
> >> experiments, which are later removed)
>
> >> ... Its very primitive at the moment it uses a fixed radius - intend
> >> to finish it off at somepoint to do arbitry radiuses, probably using a
> >> binary search on the precision. Got very distracted with lots of silly
> >> little errors (python noob) that kinda lost interest.
>

> >> On Sat, May 3, 2008 at 10:02 PM, ryan <ryanb+appeng...@google.com> wrote:
>
> >> > you're right. GeoPt properties are compared first by latitude, then by
> >> > longitude:
>

> >> >http://code.google.com/appengine/docs/datastore/typesandpropertyclass...

>
> >> > richer operations for 2D points would be great, and techniques like
> >> > geohashing would definitely be appropriate. a few other threads have
> >> > already discussed this, e.g.
>

> >> >http://groups.google.com/group/google-appengine/browse_thread/thread/...
> >> > .
>
> >> --
> >> Barry
>
> >> -www.nearby.org.uk-www.geograph.org.uk-
>
> --
> Barry
>
> -www.nearby.org.uk-www.geograph.org.uk-