Hacker News Reader

Comment by kcimc | Hacker News Reader

I helped out with this project, happy to answer any questions. I was involved from the beginning, but my biggest contribution was on the deep learning side that does the tile-matching. I helped with the initial prototype using DIGITS, Caffe, and a bunch of Python. Then Aman Tiwari moved us to a more accurate 34-layer ResNet trained in TensorFlow, and a more efficient nearest neighbor lookup using a new implementation of CoverTree search.

View on HN

Since you've opened up yourself to questioning :)...Thanks for sharing, I apologize for this very laymanny question:

I clicked on a swimming pool in New York City...there aren't a ton of them in NYC, but very few of the matches have even a spot of blue in them...I know the algorithm is more than just "look for more blue patches"...if I were to explain this to another layperson, what is the most obvious explanation for something that seems more non-intuitive than expected?

Screenshot of my panel: http://imgur.com/H0wo5jK

http://nyc.terrapattern.com/?_ga=1.84865689.1830936426.14642...

I'm not a part of this project, but if you look at your tile it's about 2/3 trees (by area), and the results are mostly tiles full of trees. Out of the results from your search, I picked out another tile [0] that I thought was more "swimming pool" with fewer "distractions". The results look like they're more in line with what you were hoping for. You could iterate this way a bit until you find the best prototype for a swimming pool.

0: http://nyc.terrapattern.com/?_ga=1.84865689.1830936426.14642...

Not Kyle, but another of the team involved in the project. When we built the training model, we used OpenStreetmap data to find locations of ~1,000,000 "things". A thousand churches, a thousand water towers, a thousand playgrounds, and so on. For each of those locations, we downloaded a satellite image.

The neural net was then trained to look for the things that make each one of those things distinct; what makes a playground different than a church? It could be patterns, it could be colors, it could be any number of things. (For more precise details, you'll need to talk to Aman or Kyle.) It compares lots of things to lots of things, makes some guesses, and then sees whether those guesses help it correctly determine what we told it was in each tile.

Once the model is trained, it's identified the 1024 "features" that are most significant in correctly distinguishing types of things from each other. We then run every tile of a geographical region through that feature determiner, which converts each tile into a point in our 1024 dimensional space. The search function then identifies a tile, looks up its location, and finds the 100 things closest to it within the 1024 dimensional space.

So, TL;dr: It's not looking for colors, it's looking for computable features, which may or may not be color-specific. (Actually, they're highly non-color-specific: the training model randomly "wiggles" the color to makes sure that it doesn't get too tied to a very precise color.)

In my experience in the USA, OpenStreetMap data that comes from TIGER (?) imports, like heliports, are close but wrong. Playgrounds and watertowers are usually accurate because someone added them by hand. Churches are mixed. Other items are confusing; a hospital is typically a single point, but they tend to be some of the largest buildings in small towns.

Any thoughts on how that affects your model?

Most of the messy point features in the US were imported from GNIS. TIGER is the primary source for the messy line features.

Sticking to features modeled as areas would generally avoid the spatial accuracy problems with GNIS.

We found the same—using OSM data that just had points was problematic, both because of accuracy and because it tended to often be the front door, not the centroid of the object.

I believe we limited our model generation to selecting places that had outlines, and computed the centroid of that outline. One of the benefits of our technique is that we didn't need to be comprehensive—we can throw out lots of places and still have enough to be useful for the model.

Any plans to take imagery with suitable licensing and produce a list of items that seem to be missing in OSM?

(Google prohibits feature extraction in their TOS and claims copyright, so OSM can't use information derived from their imagery)

Thanks for the explanation...yeah, as I said, you're talking to a layperson :). I just realized that it was possible that the training was done on images where the color scale was changed, so thinking about it in terms of "well blue patches are so easy to see" is obviously wrong.

everything david (workergnome) said, and also: in the tile you point to, "swimming pool" is most interesting/recognizable feature, but most of the image is just "trees and asphalt". if you pick another image where the pool takes up more of the image, you'll find more of what you're looking for: http://nyc.terrapattern.com/?_ga=1.84865689.1830936426.14642...

Interestingly, it worked amazingly well detecting small round swimming pools in Pittsburgh: http://pgh.terrapattern.com/?lat=40.3944695&lng=-79.98947650...

This would have been very handy when the Greek government was scanning for undeclared swimming pools!

Try with a better tile: http://nyc.terrapattern.com/?lat=40.7198568&lng=-73.98089090....

It works beautifully.

good stuff. As far I can see, the current version searches for similar tiles to one that a user clicks on.

How would I train this with labeled training data and custom images, so that I could do searches for specific things, either by typing what I'm looking for into a search field, or uploading an image of it? Sort of like Google images search

Very impressive :-)

How easy would it be to roll it out on all other places on Earth than the current 4 cities?

On the front end, it's easy——Add a couple lines to a configuration file, make a couple images, and it's done.

The difficult part is that the search is not optimized to be RAM-efficient; each city takes between two and ten gigabytes of RAM. You also need to have several hundred thousand tile images, which are commercially available, but not free.

If you've got a hefty server and the images, then it takes about a computer-day to compute the features and create the search index.

Reply on news.ycombinator.com