I was playing around with this, but I was thinking "this is dumb - I can barely draw any sort of lengthy line at all."
Then I switched from the gaming mouse my sister bought for my birthday to my trackpad, and I could suddenly draw really long lines.
My hypothesis is that my gaming mouse has really high precision, so it was sending tons of mousemove events (or whatever) to Chrome. JS was using the aggregate number of such events, rather than the aggregate distance between them, as a cutoff. Therefore, people with really precise input devices can barely draw a line at all, while people without such devices can use the app just fine.
Also, if you move the mouse faster, you can get longer lines. It’s a very bad and stupid measurement, and I’m surprised Google would actually choose this.
sorry! this is a bug based on how many events the mouse is firing and I've open an issue for it -- I will take a look at the app with a gaming mouse and work on a fix.
My utterly ordinary "Microsoft Optical Mouse V2.0" draws lines about 1"/100 pixels long when moving at normal speeds. I've been trying to draw Michigan, but utterly unable to get a thumb on the lump.
The spec sheet [1] describes a resolution of 3000 FPS/800 DPI.
I'll take a look - thanks! note that we do limit the line somewhat since the best matches are curves, lines, etc and self intersecting lines don't match very well.. The best kinds of lines are like the ones in this video (https://www.youtube.com/watch?v=w6-LK9BOVTA)
Then are you using it kinda like a kd-tree (filter everything within a threshold of forwardDistance1, then angleDelta1, then next dimension and so on)? But then how do you handle the initial scaling? What about cumulative error in heading or distance?
which gives a value for how close to polylines are (it normalizes them and does some distance calculations)
the way the vp tree works is you provide a set of data and a metric for distance (in my case, the data was the polylines and the metric was from dollar) and it computes the structure. As long as the metric observes some basic principles (I think it's called triangle inequality) the spatial division will work and you can do a fast search for nearest neighbors.
How does one arrive on a data arts team? was it a passion project or was it an existing team in the org? also how would you hire for such a team? thanks.
It is possible that something is disabling your WebGL support. You can check the status of your GPU support in `chrome://gpu` and, if necessary, use the "Override software rendering list" in `chrome://flags` to force it.
also another tip -- you can click on the city name in the left corner to load the same view in google earth (if you are curious about what you are looking at!)
I tried to draw a section of coast line I'm familiar with but it doesn't seem to allow you to draw a line more than a certain length before the end of the line disappears.
I tried it your way and got as close to home as Delaware, then I got greedy and ended up in Madagascar (again). anyway thanks for sharing a fun approach, never would have thought to experience it that way.
I tried this and got back images really fast that have matching features. The first thing that came to mind was what "he who shall not be named" said in the first Harry Potter book, Harry Potter and the Philosopher's Stone: What is this magic?"
Hmm. While your browser seems to support WebGL, it is disabled or unavailable. If possible, please ensure that you are running the latest drivers for your video card.
I think I never bothered to install proper graphics drivers..
thanks -- do you know what graphics card that is? also you can try enabling "Override software rendering list" in chrome://flags/ -- I don't have a great handle on what gpus are blacklisted, but I know there are some that are.
putting this in the address bar can give you a lot of info as well "chrome://gpu"
how is this possible? The instant I release a line it has a perfect match - I would be impressed if it got one after working for 1000 ms, but how can it be instant? what's the back-end setup here?
are there natural limits to what kinds of lines are supported? For example drawing a Z doesn't work at all (whereas a C works well)
When drawing a Z the top bar of the Z is consistently ignored (I draw from the top down) and doesn't match anything in the picture, just randomly cuts into whatever is there. Whereas the remaining two strokes line up nicely. I think I don't need to screenshot it as it's quite consistent and you should see this yourself too. I wonder why this is...
the matching is based on the input (lines from the line detection) and we do some tricks to try to get better matches if the results aren't great. One trick is for matches that aren't super great, we start to trim the line slight from the start so if the first pass is a bad match, we try 95% of the line (ie, the last 95%) then trim is some more, etc.
another thing to note is that the app progressively loads data in the background so you get better results after the first minute or so once all the data is loaded -- the app launches with only 20% of the overall data.
But how can it be that you have extremely detailed photos matching all sorts of lines of all shapes (great job by the way! for normal curves I'm super impressed), but you don't have any with a natural Z in them? Zigzags aren't that uncommon - I can see some visually but your algorithm ignores them. I think it's not just due to the fact that you ignore the beginning of my line - it's that you somehow don't detect zigzags in the photos... Try drawing some capital Z's to see what I mean :)
I want to make sure to be positive, this is a super amazing result for almost all the curves I drew :) Just curious about that one.
no it's a really good question! I think this just has to do with the line detection algorithm and it tending to find more curves than sharp angle lines -- this is what the matches look like when you draw a Z:
they are not as good as when you draw a curve and I think it's just trimming based on general poor matches. I've found if I round the Z or make the angle less extreme I can get better results.
interesting! thanks. Yes, most of the matches you linked are poor matches
so what you said earlier about starting to trim the start of it must have applied.
I don't have more questions :) Thanks again for sharing this project - the result is fantastic, really shockingly good :) - goes to show...algorithms ftw :)
Then I switched from the gaming mouse my sister bought for my birthday to my trackpad, and I could suddenly draw really long lines.
My hypothesis is that my gaming mouse has really high precision, so it was sending tons of mousemove events (or whatever) to Chrome. JS was using the aggregate number of such events, rather than the aggregate distance between them, as a cutoff. Therefore, people with really precise input devices can barely draw a line at all, while people without such devices can use the app just fine.