Looks like they're randomly dropping the viewer until they get a hit (I've gone over "searching (600)"). I wonder if there's a faster way to do that with their API?
Completely random drop would fare really bad (street view is very rare compared to Earth's surface).
What I would do is a sort of "computer vision". Map has well defined colors for features, so you just need to check pixels with proper shading.
This should be quite easy as street view availability seems like a transparent overlay image, so you even wouldn't need to distinguish it from other map features.
And even if it's composited with the map image server-side, it should be still quite easy to extract it, just look for pixel diff compared to normal map image.
In the time it took to act smart you could have just read the code and seen that his intuition was mostly right. The code is extremely simple. It reads like a half day project just for fun that happened to get picked up on HN. It doesn't seem to be at all related to his line of study either.
For you interest and information, he has a defined set of bounding boxes in the world for each of the user pickable regions. He generates random lat lons until one lands in an enabled region's bounding box and then makes a request for street view data to google. If google returns a 200 he sets the street view display to the lat Lon and otherwise tries to find another lat Lon. If he ever gets a 500 from
Google he quits.
I wasn't trying to figure out how it was done, I was trying to figure out how to do it fast (irrespective of the present implementation), responding to the question:
"I wonder if there's a faster way to do that with their API?"
I did check the source code. The most time is spent doing dozens to hundreds requests to Google API.
If instead of this you generated random locations just from "blue" regions of StreetView coverage, user experience would be better.
The simplest way how to do it would be to fetch StreetView coverage overlay PNG and use canvas getImageData to check pixel values for random locations, thus moving costly roundtrip validity query mostly to the browser.
This is not something terribly difficult and perfectly suitable for half day fun project.
There are ways how to get around cross-domain security restrictions. Long ago, I have done it myself by a simple server-side proxy here (few lines of PHP):
About Globe Genie optimization. In fact, I implemented it, sent a patch to the author and it's already live there (check the source code). It cuts cross-network locations validity lookups by about 60%.
Here I didn't do proxy, just fetched a complete set of overlay tiles once and stitched them together with a Python script:
It's just a static prebaked lookup map (served from the same domain), though if you really want to have it up-to-date, you could hook up Python script to cron.
All this took few hours (Sunday evening hacking) and was quite fun to do.
I'd assume it only attempts drops on streets. In which case, as badly as one in a few hundred drops on only streets? I bet it'd be pretty close. They've street-viewed an absolutely ridiculous amount of roads.
It seems like it would be fairly easy to build up a cache of found places, and then queue up new ones across different users.
But still it's amazing, looking around the world randomly. It would be nice if there was a better virtual driving tool, or more zooms (aerial views). At the moment you can only double click repeatedly and you go about the same speed as a car.
This. Every new user should get a cached random location and immediately start calculating another drop in the background to upload to the servers cache.
While I wait for the page to reload I pretend I'm being teleported randomly from place to place. I spend a few moments figuring out how I would survive in this new environment or move down the street to see what is around the next corner before I'm moved again.
