[Georuby-devel] find_by methods
guilhem.vellut at gmail.com
Fri Apr 28 14:26:53 EDT 2006
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
> 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:
>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.
More information about the Georuby-devel