By the way the original use of the code was used for solving real life traveling SalesMan routes for shipping and receiving for a VERY, VERY large client, and GAE is not what the final product runs on but we needed infrastructure to test the logic on which is what was sold, not the actual source code.
-----Original Message----- From: google-appengine@googlegroups.com [mailto:google-appengine@googlegroups.com] On Behalf Of Brandon Wirtz Sent: Wednesday, December 14, 2011 6:53 PM To: google-appengine@googlegroups.com Subject: RE: [google-appengine] Re: Isn't .08/hr 1.92/day $59.52/month for a 600 MHZ CPU instance with 128 MB memory a LITTLE EXPENSIVE I have very nice Teselation Code, uses concentric Hexagons in place of Circles and works for nested families on a map, and even has a "Driving" distance function rather than "As the crow flies" that requires there be a road of a given size in the Hex to make the move. And While it isn't well tested we have a "driving Time" function that allows for City, Highway, and Rural, hexes so that you can specify a that you'd like to find something with in a 30 minute radius instead of a 30 mile radius, and if you can hop on i80, that will search 30 miles, and if you are in LA it will search 7 miles. Currently only being used for US maps, but it can be used for Global. Works really well and is blazing fast on GAE. Sell it to you for $500k. -----Original Message----- From: google-appengine@googlegroups.com [mailto:google-appengine@googlegroups.com] On Behalf Of Jeff Schnitzer Sent: Wednesday, December 14, 2011 6:33 PM To: google-appengine@googlegroups.com Subject: Re: [google-appengine] Re: Isn't .08/hr 1.92/day $59.52/month for a 600 MHZ CPU instance with 128 MB memory a LITTLE EXPENSIVE On Wed, Dec 14, 2011 at 8:08 PM, Brandon Wirtz <drak...@digerat.com> wrote: > GAE FORCES you to think about your code. But it allows you to forget > about everything else. Brandon, I humbly suggest you just haven't hit an edge case yet. There are plenty of indexing problems which GAE simply doesn't offer a solution to. When I am forced to think about "does polygon A overlap with polygon B?", I look for R-tree indexes... which GAE doesn't offer. There are a million spatial index functions which are no-brainers in PostGIS but represent man-years of work on GAE. And of course there's fulltext indexing. GAE gets more features every month, which is great. The magic anti-exploding-index queries recently added are a godsend. Fulltext indexing is on its way. And I'll be jumping up and down in happiness when true spatial indexes show up. But let's not pretend that GAE is complete. And let's make sure Google knows it when they make missteps like pricing large instances unreasonably or offering halfway email solutions that do little more than generate complaints on this list. Jeff -- 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 google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en. -- 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 google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en. -- 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 google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.