From Chris.Ingrassia at fortiusone.com  Thu Apr 27 17:00:43 2006
From: Chris.Ingrassia at fortiusone.com (Chris Ingrassia)
Date: Thu, 27 Apr 2006 17:00:43 -0400
Subject: [Georuby-devel] find_by methods
Message-ID: <920F967F-4217-4C60-97EE-876E701BB757@fortiusone.com>

I hope there are at least one or two people monitor this list, or  
this is all for naught :)

	I'm working on some projects and applications that GeoRuby and the  
spatial database adapters fit rather neatly into, and I'm reaching  
the point where it's probably going to be in my best interests to  
spur things along a little bit by taking a crack at extending GeoRuby/ 
MySQL with spatially-enabled find_by_* features, which I'm assuming  
would be of interest to just about anybody using the spatial database  
adapters for obvious reasons.

	I was just sort of curious what people's thoughts were on how they  
should be implemented.  You'd obviously want to try and stay as rails- 
like as possible, but I'm not quite sure what a simple line of code  
like :

	"MySpatialModel.find_by_geometry(Point.from_x_y(0,0))"

	should really mean.  Where the geometry is equal to that point  
(which I guess is what the strict rails-like way of doing it would  
be)?  Where that point is within the model's geometry column?  They  
both seem almost equally correct to me.

	When you get to things like finding things closest to a specified  
geometry, or that cross a specified geometry, etc... it starts to get  
a little hazier to me.

	My initial thought would be to do something along the lines of:

	"MySpatialModel.find_all_by_geometry_crosses(some_line_string)"

	and

	"MySpatialModel.find_by_geometry_nearest(some_other_geometry)"

	I feel sort of like I'm missing something really obvious and that I  
may got mocked for even asking such questions, but what that obvious  
thing might be eludes me at the moment, and these sorts of things  
keep me up at night.

	Any thoughts?



From guilhem.vellut at gmail.com  Fri Apr 28 14:26:53 2006
From: guilhem.vellut at gmail.com (Guilhem Vellut)
Date: Fri, 28 Apr 2006 23:26:53 +0500
Subject: [Georuby-devel] find_by methods
In-Reply-To: <189D0E28-8A0E-4F62-AD79-9C1CF98F5E85@fortiusone.com>
Message-ID: <44525e7c.5e9f65c3.7535.2ba6@mx.gmail.com>

Congratulations! You got First Post!

>I was just sort of curious what people's thoughts were on how they  
>should be implemented.  You'd obviously want to try and stay as rails- 
>like as possible, but I'm not quite sure what a simple line of code  
>like :
>
>	"MySpatialModel.find_by_geometry(Point.from_x_y(0,0))"
>
>	should really mean.  Where the geometry is equal to that point  
>(which I guess is what the strict rails-like way of doing it would  
>be)?  Where that point is within the model's geometry column?  They  
>both seem almost equally correct to me.

This default find_by method should probably be the most common query
performed but, in my (limited) experience, I haven't seen the "=" (equality
of bounding boxes) or Equal (equality of geometries) operators a lot. Now
obviously, since there is a lot of operators and a lot of different cases,
everybody will have a different opinion but I would personally favor the &&
operator (bounding box intersection), since, to quote the PostGIS
documentation: 'The most common spatial query will probably be a
"frame-based" query, used by client software, like data browsers and web
mappers, to grab a "map frame" worth of data for display'.  

>When you get to things like finding things closest to a specified  
>geometry, or that cross a specified geometry, etc... it starts to get  
>a little hazier to me.
>
>My initial thought would be to do something along the lines of:
>
>"MySpatialModel.find_all_by_geometry_crosses(some_line_string)"
>
>	and
>
>	"MySpatialModel.find_by_geometry_nearest(some_other_geometry)"
>
>I feel sort of like I'm missing something really obvious and that I  
>may got mocked for even asking such questions, but what that obvious  
>thing might be eludes me at the moment, and these sorts of things  
>keep me up at night.

This looks like a good idea: One find_all_by for each geometric operator and
others that look useful (like nearest) would cover a lot of common queries. 

I am also thinking that, on top of Geometries, the user should be able to
pass a string as argument, which would be later interpreted by MySQL or
PostGIS (for example : something like find_by_geometry("BOX2D(0 0, 1 1)") in
postgis). Also, an option to indicate a restriction of the query using &&
(which can make use of an index) would probably be useful.    

guilhem