Dave, Thank you for this post. Your description of how to handle date ranges led me to a solution on the map lat/long issue that has gotten so much discussion in various threads. I've posted the following in a couple of other threads as well, since it seems to be a real issue. But the solution is redundant properties, as you indicate. Basically, the idea is finding a way to tokenize a region so that an infinite number of points becomes a block...
What I do is that I break down the grid into sub-degree squares by truncating after the first decimal point, and then when I save something that I need to find on the map later, I save metadata with that point indicating the surrounding grid squares. So if I have a point with long -122.123123123 and lat 35.56565, that's in a grid square called -122.1x35.5, and it's surrounded as follows: [-122.2x35.6][-122.1x35.6][-122.0x35.6] [-122.2x35.5][-122.1x35.5][-122.0x35.5] [-122.2x35.4][-122.1x35.4][-122.0x35.4] Those are all represented in my object as a list (db.StringListProperty, so you have to do the right permutations to make them into strings), and because of the way lists work, if a point that you're searching on is in any of the grid squares associated with a saved point, that saved point will come up. To wit, if you have saved that above point, and someone comes in searching on an address that corresponds to: LONG -122.0857 LAT 35.69999 that corresponds to grid square '-122.0x35.6', which is in your upper right hand corner. Thus, if your code is something like... square = '-122.0x35.6' # based on whatever normalizing function you use points = (SELECT * FROM Locations WHERE gridList=:1", square) ...you'll find that the original point we saved above will return. Of course, this is a simple example. Each grid square can be any size and shape, and you can cluster as many as you like in whatever shape you like. For me, a 3x3 grid of 0.1 degree squares is good enough. 0.1 degrees is approximately 7 miles in the north/south direction, and up to that big in the east-west dimension, at least at the equator. It's a blunt tool, but once I've got a reasonable set of map data back, then I can do further operations to throw out what I don't need. It's all about metadata. Don't think in terms of inequalities and boundary conditions, think in terms of inclusive ranges. With a little creativity, you don't need inequalities, at least for this problem. Best, Ben On Sep 7, 7:37 am, "David Symonds" <[EMAIL PROTECTED]> wrote: > On Sun, Sep 7, 2008 at 9:42 PM, Nash <[EMAIL PROTECTED]> wrote: > > > This is the part of the appengine that starts to get frustrating, the > > more criteria you will want to add, the more impossible you will find > > it to be. > > If all you are looking for is to find data for a particular date then > > I suggest adding three fields to your entity: year, month, day. If you > > want to get results for a particular day, just provide values for > > these attributes. By breaking the date unto three parts, you can also > > get results by month, by year etc. But if you have want to pull data > > between two points and between two dates, then good luck! > > In that case, you would use multiple properties: one for the whole > date, and then split it out Y/M/D. Remember: BigTable is designed for > lots of redundant data that makes it really easy and fast to index and > find what you want. Don't be afraid to drop in redundant properties. > > Dave. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
