DB: Geolocation Queries with Geokit Rails

Loading...

Do curso por Johns Hopkins University

Capstone: Photo Tourist Web Application

18 classificações

Johns Hopkins University

Capstone: Photo Tourist Web Application

18 classificações

Curso 6 de 6 em Specialization Desenvolvimento Web com Ruby on Rails

In this Capstone project for the Photo Tourist you will implement a Ruby on Rails web application that makes use of both a relational and NoSQL database for the backend and expose the data through services to the Internet using Web services and a responsive user interface operating in a browser from a desktop and mobile device. You will have a chance to revisit and apply what you have learned in our previous courses to build and deploy a fully functional web application to the cloud accessible to your co-workers, future employers, friends, and family. In developing the Photo Tourist web application, you will get to work with different data types and data access scenarios (e.g., fielded data display and update, image upload/download, text search, access controlled information) to provide your users the ability to show off their photos and information from trips they have taken and to seek out photos and information from trips taken by others. Using the application you develop, your users will be able to • Create an account • Upload and download photos to the site and make them accessible to others • Provide descriptions of trips and photos that others can read • Organize photos by location and trip, • Find photos based on location • Find photos based on text searches of descriptions • Locate the place where the photo was taken on a map

Na lição

Geolocation

In this module you will add geolocation capabilities to the end-to-end application. This will allow your users to assign a geolocation position to images as well as identify the current origin and distance limits for future API queries. You will implement the model and API queries for subjects within this module and complete the UI components within the next module. At the data tier you will add geolocation coordinates to the Image model, make those geolocation coordinates available to ThingImage though the 1:1 relationship between them, implement geolocation queries using the Geokit Rails gem that determine all items within a distance limit from an origin and supply their distance from origin. These queries will leverage custom SQL selects, joins (inner, right outer, and left outer join) and will be encapsulated within ActiveModel query scopes. At the API tier you will implement API service endpoints to geocode addresses and reverse geocode positions into a resolved location using the Geokit Rails gem and the Google Maps Geocode service, implement a persistence cache of geocode results using MongoDB to help stay within free service limits and speed up lookups, enable an API service endpoint to query for subjects (ThingImages) of a certain type, within a distance limit, and dynamically annotate them with the distance from the supplied origin, implement HTTP caching headers for both geocode and subject results. At the UI tier you will implement a geocoder service to lookup a location by (partial) address or position from the API implemented on the Rails server, add geocoding to the Image editor to allow a user to specify the Image's position using an address, build a current origin component to express and retain the center origin and distance limits for future subject queries.

Module 6 Introduction3:05

DB: Geolocation Coordinates4:51

DB: Image Position and Value Objects14:01

DB: Geolocation Queries with Geokit Rails14:19

DB: Associated Object Geolocation Queries13:08

DB: ThingImage Geolocation Query Scopes9:46

DB: PostalAddress and Location Value Objects7:34

Conheça os instrutores

Jim Stafford
Adjunct Professor, Graduate Computer Science
Computer Science, Whiting School of Engineering

[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.

Explore nosso catálogo

Registre-se gratuitamente e obtenha recomendações, atualizações e ofertas personalizadas.

O Coursera proporciona acesso universal à melhor educação do mundo fazendo parcerias com as melhores universidades e organizações para oferecer cursos on-line.

© 2018 Coursera Inc. Todos os direitos reservados.

Baixar na App Store

Baixar no Google Play