I agree with barry, there is no easy answer so for now, you'll need to cook up something on your own.
we wanted/needed the ability to search by point/line/polygon on layers that contained all three types as well. GeoHash would work but the problem I ran into was the inability to pull enough entities at one time to feed into the secondary filter (the geometry). the datastore can return up to 1000 entities but in practice that number is far lower to keep from hitting the deadline limits. a typical spatial query might need to compare against 1000+ features before reducing it to a much smaller result set. to get around this, we store all the geometries for each layer in packed grids that are in turn indexed with r-tree like structures. the grid structure is identical to the zoom/x/y grid used in Google Maps tiles so finding what grids you need is just a simple calculation instead of db join. when you upload your data, you pick a grid level that puts an optimal number of features per grid cell (kinda like what you need to do in a traditional spatial rdbms anyway). then when searching with a filtering geometry, it pulls only a handful of grids and then quickly finds features within each grid that satisfy the filter geometry. It's not optimal for large queries that need to return 100s-1000s of features but the vast majority of spatial queries (for our use case at least) would return only a couple hundred at most and are concentrated on relatively small geographic areas (so its feasible). the cool part is the size of the grid and the number of features for each layer really doesn’t matter that much as long as your queries don't try to pull from a huge geographic area (although a smart client side query cursor could distribute it over several servers at once) here's a sample Flex based viewer, click on "Tools" menu (cube image with gears on it) and then hit the "Search" item. Choose a tool and select on the map http://tinyurl.com/anpq5p the Flex viewer itself is a free download for ESRI's ArcGIS Server REST api. We made our GAE app look like this REST api so we could use their viewers cheers brian On Mar 11, 7:39 pm, Barry Hunter <[email protected]> wrote: > There is no easy answer. > > The datastore has no 'geoindex' built in, so the application developer > has to develop their own. > > The bounding box one is probably one of the most complete examples. > Although there are other possibilities including more advanced geohash > based versions. > > At somepoint the datastore may implement a geoindex for you, but it > will probably use a similar implementation under the hood, until then > its upto you. > > On 11/03/2009, Dan Course <[email protected]> wrote: > > > > > > > Morning Group, > > > Hope everyone's all good? Got a dev. problem driving me nuts and I > > can't figure out or find a simple solution throughout the posts. > > > We're saving Lat/Lng in a GeoPt datatype. We then need to search > > within all those GeoPts for the nearest within a radius/square (range) > > > eg, search?lat=2&lng=5&range=5metres > > > What's the easiet way of sorting this? The bounding box method seems > > overly complex and crazy, are we just hoping for a simple solution to > > quite a complex solution? > > > WHERE GEOPT NEAR (LAT=2, LNG=2) > > > Any clues? > > > Thanks, > > > DanC > > -- > Barry > > -www.nearby.org.uk-www.geograph.org.uk- --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~----------~----~----~----~------~----~------~--~---
