Querying Coordinate Information – Web Development


Here’s our map API. What we need to do is figure out how to draw this map. The URL is going to look like this. It’s going to be this URL–maps.googleapis.com/maps/apis/staticmap, and then it’s going to have some parameters. I’ve done a little research already to find that the only required parameters are size– which is going to be the size of the map, sensor– if we were doing this on a phone or in a browser that knows where you are already, whether to actually try to figure out where the user is. We’re not going to use any of that. Then we can just add these marker parameters. Here’s one marker, and you can see in here this marker is defining the color to be blue, and it has a label, and then, also, you can see something that looks like coordinates in here. I’ve learned that the color and the label aren’t required. We can just say marker and given it the coordinates. If you notice here there is another marker parameter. The way this API works is it just looks from for multiple marker parameters. We’ll just add one marker parameter in the URL for each point that we have. Let’s go ahead and do that. Now we want to update our front page to actually have the art images. Let’s think about what we’re going to do. We’re going to first find which arts have the coordinates. If we have any arts with coordinates, then we need to display the image URL. First thing we need to do is we need to define which arts have coordinates. This is fairly easy. What we can do is we’re going to take this list of arts, and for each one we’re going to check to see if it has coordinates. Let’s say for a in arts: if arts.coords: points.append(a.coords). We have to define points as equal to the empty list. This is pretty straightforward. For a in arts–for each one of these–if there are coordinates– The way the datastore works is if there are not coordinates in the database, this’ll just be None. It won’t blow up on us or anything. Just add it to the list points. This is a clear way of writing it. How I would have written it is slightly less clear. A little shorter. This is just some Python learning for your own edification. Points=filter(None, (a.coords for a in arts)). This is a generator–a.coords for a in arts. This would return an iterator of all the coordinates, which may be either coordinates or None. Then filter takes two parameters. It takes a function or None and a list or an iterable and basically returns all of the items in the list that match the filter. In this case, if the filter is None, it basically says match all the ones that aren’t None. This will give us all of the coords for each a in art if it’s not None. That does exactly the same as this. We’re going to use the slightly shorter version. This should work. Let’s make sure this doesn’t blow up on us. Here we are in the browser. We reload the page, and we see our little guys. Maybe we should print out the coordinates so we can see them. Let’s go ahead and do that. Okay, we’re going to go ahead and write that out. Let’s try that in our browser. There we go. There’s a list of our points, and in this case we only have one. That’s good. There’s one subtle bug I’d like to point out to you in this code. Arts is a query. When we iterate over arts, that’s when we actually run the query. If we never iterated over arts here, this query wouldn’t run. Well, we iterate over here, and then when we’re rendering the front.html– this template, if you recall, has a loop in it that draws all the arts. This also iterates over that arts query. Each time we do that we run the query. We don’t want to run the query twice. That’s wasteful. Not only is it wasteful a query, the results of that query could change. When ever you find yourself in a situation of iterating over results you get from a database, whether it’s datastore or some other kind of curser based abstraction from a database, it’s usually good to say something like this: [arts=list(arts)] What this does is it creates a new list out of that arts. The arts that comes out of here is a curser, and then we basically call the list constructor on it, which says, okay, make a new list out of that iterable. Then we can iterate over this list as many times as we want, and we’ve kind of detached it from the query. This is a good habit to get into if you think you’re going to be using results from a database more than once or you’re going to be manipulating this result from a database too far away from this query, because generally if you get a list of things from an iterable, you assume that you can go over it a couple of times. That’s all this is going to do. It’s basically going to cache the results of this query in a list. It’s very subtle, and I was actually struggling a little bit how to demonstrate that to you. I don’t know how to debug Google queries. If I could have made this print in the console, I would have. If we figure that out between now and when we wrap this lesson up, we’ll include that in the instructor comments how to show what queries are actually running. But I did a little googling and confirmed for myself that this would be the case. That’s good to do.

Add a Comment

Your email address will not be published. Required fields are marked *