gistfile1.txt

14:31 <cdepue> anyone doing geospatial encoding w/riak 

14:38 <sylvainsf> cdepue: I am 

14:38 <sylvainsf> but basically that means I'm doing my geo stuff outside of riak and 
having it return riak keys 

14:38 <cdepue> did you write your own geohash? 

14:39 <sylvainsf> I tried to but it wasn't performant, basho guys agreed geospatial stuff 
just isn't a good match 

14:39 <sylvainsf> but the hybrid system works great for us 

14:39 <cdepue> what did you write it in? i have in my "available toolkit" - 
redis, riak, ripple, and ... diet coke 

14:39 <sylvainsf> erlang functions in riak 

14:40 <sylvainsf> the issue is there's no query partitioning unless you break your 
geo data up into some sort of bucket scheme 

14:40 <sylvainsf> like bucket per zipcode or somesuch 

14:40 <cdepue> yeah i was going to build a tree of linked keys 

14:40 <cdepue> right 

14:41 <sylvainsf> and the hassle of developing and maintaining that wasn't worth it to us 

14:41 <sylvainsf> first I did a geo layer in PostGIS, worked great but then I had to 
maintain postgres servers 

14:41 <sylvainsf> so we moved the geo layer to simplegeo 

14:41 <sylvainsf> I get an object, write it to riak, take the key and store it in simplegeo with the position data 

14:42 <cdepue> interesting 

14:42 <sylvainsf> then I do spatial queries against simplegeo get back a list of riak keys 

14:42 <cdepue> that's way less hassle 

14:42 <sylvainsf> yeah though it does add an external dependency and some cost at scale 

14:43 <sylvainsf> our use case allows the client to store quite a bit of info about 
their local area so every view doesn't hit simplegeo 

14:43 <cdepue> ours is like a once/month type query probably per user so it could be ok 

14:45 <cdepue> sylvainsf: that's helpful thx 

14:47 <sylvainsf> no problem 

14:47 <sylvainsf> btw the simplegeo docs aren't all that great for ruby, feel free 
to ping me here if you get stuck 

14:51 <cdepue> ok will do