[MUSIC]
In this lecture, we will discuss adding Geokit Rails gem queries to our images,
so that we can take advantage of queries like closest to origin, within a range of
an origin and ordered by distance from the at origin and add some query finishing,
so that our object gets augmented with its distance from a particular origin.
To get started with queries, we'll be adding the gem from Geokit Rails.
This gem specifically provides geolocation database based query functions
like within or by distance and we'll also integrate in with it's related
geokit gem that will be able to go out toward geocode provider, and get results.
But right now, we'll just worry about querying those values in the database and
not worry about where those values came from.
So as we pick up on our implementation, our image has properties of lat and long.
We have a point class that's going to encapsulate the values of lat and long for
our image, and we have defined that composition the active record.
And now that we've brought in GeoKit Rails, we would like to take our image
with lat and long and be able to find images that are closest to an origin,
within range of an origin and order them based upon their distance from an origin
and return to us with an annotation that says, how far they are from that origin.
And if we look closely at the results of finds closest,
our first hint of why the test is failing is there's no closest method on an image.
And so, how we pick up that method?
We define a Geokit Rails macro of acts as mappable.
So with the macro defined, our image now has the closest method to find.
So, let's define an origin.
A point at Johns Hopkins University and
let's build a new image with no image content at that particular origin.
So now if we query for closest, notice that it's doing some mathematical
calculations on our database values and it's coming back with
a query result that is still a collection, a collection of one, but
it has identified the image that is closest to the location that we expressed.
So defining the macro gave us the query method of closest and
it able to look in to the lat, and
long property that we passed in and implement our query.
Now one thing to note if we're going to execute the query against our point class,
the origin, we're going to get an error,
because it doesn't understand what point is.
It knows what an active model class is that has a lot and long property, but
it doesn't know what this non-active model class class is that has one.
We can somewhat solve that by giving it an array of latitude longitude and
we get our value.
Except, we would like to not have to worry about what it is that we're passing in.
We would like some of these types to be treated inherently as an origin.
So what I'm going to do in addition to defining the macro is on the image class,
I'm going to define a to_lat_lng.
This is a method that Geokit Rails looks for in what's passed in.
And if you supply that, it says, great.
Give it to me, because I'll expect this latlng object to come back.
Although at this point in time, it doesn't seem like we need it for this image class,
what we would like to do is the same for the point class.
We could go over to the point class and do exactly what we did with image, except,
well, this is a place to do trial and error.
Why don't we just show an example of us adding a method
to an existing class outside of that class.
So, let's leave our point class pristine.
It knows nothing of Geokit Rails and it just has its core data types.
And then since our image already knows about Geokit Rails,
it did act as mappable.
It defined as to_lat_lng and it says, you know what?
The point class as well should know about that.
Let me add that method to it and we can do it with this class_eval.
And it knows if I can pass in the result of latlng, which is an array and
put an asterisk in front of that which will turn the two
element array into two parameters into the new like we did here,
we will end up returning a Geokit: :LatLng.
Now, the only negative to doing it this way is this
method won't exist until you load in the image class.
So if you go straight to the point, the method won't exist.
If we go ahead and come in fresh and try to new up a point and
ask for its latlng, he's going to say, I don't know what a latlng is.
But if we new up an image, cause image to get uploaded and
then we go to a point he says, yeah, I know what that is.
That's the one downside of extending a class outside of the class itself.
That if we do it this way, we have to load an image in order to
have this property available to point.
This is probably overkill since we have the source code to both classes at our
fingertips, but I wanted to leave this in the baseline as an example of how we might
want to add methods to a class that we don't have the source code to.
So now that our point class knows about this particular special method we can just
use it straight up without having to convert it into lat long.
That'll be convenient.
And if we look back at the test that we're trying to pass,
we'll notice that it sets up by creating an image from 0 to
90 degrees latitude at 0 degrees longitude and
then locates a particular image in that set that's at 0 degrees latitude.
And then when we say, find closest, it says,
please give me who's closest to the origin, who's not of id origin.
And what we should find is that the closest should be
somebody who has a one degree latitude.
Now just absorb that for a second,
what we're adopting is the ability to augment our query context.
You saw all those mathematical equations and then we're paring it down.
We want to add in some additional criteria and the query just gets bigger.
So we come back over to the rails console and set of origin,
because it's not defined that way.
We just say, 27.
We say, find us the closest that's not this row homes,
because we want something else.
And now, we get the Taney Statue.
Well, give me something that's not the Taney Statue and
it's going back to the row homes.
Give me something that's not of those two.
We get the Bromo Tower.
And what we look at is yes, those mathematical calculations are in there,
but we've also added in images not in this id set.
So now when we run our query test just by the addition
of that macro all of our query methods are passing.
We've only looked at closest in moment,
we'll take a closer look at what all these other methods meant.
So if we take a look at our test, we know the details behind closest.
So, the test finds within range what it is invoking is within and
the within query scope will not reduce it down to the closest.
It will reduce it down to all are that within our criteria.
So if you remember our dataset, there were all at the same value of longitude, zero.
There like all like Greenwich mean time and
then they all were one degree apart from one another from 0 to 90 degrees.
Well, Googling how far is that distance of 1 degree latitude from the equator to
the North Pole, we come up with a value of about 69 miles equals 1 degree latitude.
And I'm just saying, give me everything within 13 times 69
miles of an origin that's at 0 latitude, but not the origin and
I would expect to get 13 answers back minus the one origin as my result.
And then I would expect that if I were to call another method added by
that macro distance from, each of the images returned will say that
they're less than 13 times 69 miles from the origin.
Make sense?
Now, we can apply that same query for when we say ordered.
We just don't want to know who's in that overall collection of within
13 times 69 miles, we would like them ordered by distance.
And if we grab the first one, it would either be the closest or
the farthest, depending on how we've ordered things.
So if we add in the query context of by distance and pass to it the origin,
realizes first queries go is receiving an origin and
it's constraining the results to be within 13 times 69 miles and
the second query scope is working on the order by and
it's doing another calculation that says, okay,
now let's order these results by their relative distance from an origin.
So in theory, these could be two different origins, but
that really wouldn't make sense to me.
And then a test goes on to verify that in the order given,
that each of them is one step further away than the other.
And of note, this by_distance, it also takes an optional
argument of reverse true, false and it defaults to false.
And so you can go from farthest to closest,
if you put in reverse versus closest to farthest.
If you put in nothing or you put in false.
So, lets take a look at this for a second.
So let's go ahead and build our origin again and let's paste in the within, and
by_distance.
If we go back to the query as I was saying earlier, the where clause is constraining
things that are within those limits using mathematical calculations.
And then the order by is doing the same thing,
except for the purposes of ordering them.
Two independent query scopes working together to give us the desired answer.
So in this last test, what we don't want is to have to look back and
ask distance from each time to find out where are objects are.
We want them already resolved.
We want them coming to us with a value.
So if you look on their website, you'll see some discussion of how they used to
have it actually baked in to the query and why that was a performance problem.
And so now instead, they provide a helper function that'll effectively do
what we're doing here of going through each element and
performing a distance from, they'll use meta programming in order to
add the value from this calculation on the object that gets returned.
So if you go to the Geokit Rails GiutHub website and search for
the DistanceCollection class, you'll notice a method of set
distance from that takes an origin and some options and extends array.
The options really are only just there to say, what property name are they
going to use and what they do is they use a metaprogramming to go ahead and
add the property to the overall class and then set that property in a for
loop calling distance to and then calculating it per origin.
For some reason, this does seem kind of unnecessary, because we already
did an order by and that order by required obviously a distance to but
this is how we need to do it.
And honestly, we don't really notice the performance.
It's pretty quick.
So what this last test verifies is that after coming out of DistanceCollection,
we walk through each of our objects and they all respond to distance and
they are all, of course, less than 13 times 69 miles.
So to demonstrate some of the capability that it's doing, just notice if we create
a new image and it asks for distance, it says, I don't know what a distance is.
But if we go ahead and get our origin and then if we go off and
get all the images that are within 13 times 69 miles of that origin,
the fact that we are going to order by distance is not important.
A result came back and then I'll take that collection,
and pass it through the distance collection helper method.
And if I look at the distance for a particular one, it's going to say,
two miles.
But in addition to that,
any new image that we create now understands what distance is.
So, this is what this method did.
It added this property to our overall class, so
that all new instances of that class would know about that property.
And if we take a look, this is logically what we did in the case of the point class
here, except we used a different syntax in order to achieve a similar behavior.
In summary, we added Geokit Rails query capability to our image and
used our point.
We integrated image, rather easily, because it already had lat and
long by adding the macro, acts_as_mappable.
And then we demonstrated a Ruby class capability where we extended the point
class to have an additional method required by Geokit Rails, but
we defined that extra method within the image class.
Pretty neat how that works.
We can keep our Geokit Rails stuff isolated and
not pollute some generic classes like point.
And then we took advantage of Geokit Rails queries like closest to an origin,
within a range of an origin and ordered by_distance from that origin and
then added some finishing of annotating the object.
How far it is from the origin when we return it back to our caller and
leveraging a helper class provided by Geokit Rails in order to do that.
What's next?
Associated Object Geolocation Queries.
Not every object within our applications is going to have lat and
long associated with it, but we would like to get some geolocation query
results from related objects to image and let's do that next.
Jim StaffordAdjunct Professor, Graduate Computer Science
