> Instead of projecting the Earth directly onto a single square, it projects the Earth onto the 6 faces of a cube enclosing the Earth and then applies an extra non-linear transformations to reduce even more the deformations. Each cell in s2 is in fact part of one of six quadtrees that describe the whole planet.
That's a super cool detail! I once implemented a 2D index using a Z-Order curve that directly translated lat/lon coordinates to a linear ordering. It works well enough because nobody really lives at the poles--the search regions with a single projection get really obtuse there. Projecting the earth onto a 6-sided die is a really elegant solution to that problem! Go go Google engineering!
There is a subtle concept at work here that many people don't know but which manifests in geospatial data models: the representation you use to shard data should be homeomorphic to the intrinsic topology of the data model. Using cartographic projections is popular but does not meet this criteria, and it does eventually break for non-trivial geospatial data models. A cube, on the other hand, is homeomorphic to a spheroid (like a donut is to a coffee cup) and therefore capable of practically representing much more complex data models.
That said, using a cube projection has its own set of limitations and issues for advanced geospatial analytics even though it is well-behaved for sharding. Current best practice representations embed a spheroid in a synthetic 3-space and shard the 3-space, which has few edge cases to worry about and is very efficient in time and space.
Some valid relationships in the data model may not be representable in the sharding scheme. As a simple example, this is why many projection-based sharding schemes do not allow geometries in the polar regions. For any sufficiently rich analytical data model, you will eventually run into data or derived relationships that can't be properly represented in the system.
On a more practical level, non-homeomorphic representations also create a large number of additional edge cases that need to be handled to ensure correctness, many of which are obscure and non-obvious. In most implementations (including open source), developers tend to ignore many of these defects because they rarely affect simple mapping applications -- the reason they used a projection based representation in the first place is because it was easy. For complex, massive-scale geospatial analytics, customers have an uncanny ability to find these edge cases almost immediately.
I spent some time doing adapting some geometry algorithms to work with geospatial coordinates a few years ago. The problem with the poles is that latitude converges to 90 degrees whereas longitude degrees are all over the place if you move even slightly. This combined with precision issues with floating point math causes all sorts of issues.
This works perfectly fine if you stay away from the poles but if you get close enough the circles become a bit irregular. The algorithm tries to work around some of the issues but the results don't look pretty.
Other issues I encountered were several datasources with invalid degrees due to rounding errors. This is an issue along the dateline (180 degrees longitude). E.g. 180.0000001 degrees is invalid.
Another fun edgecase in geo is null Island, a fictional island of the coast of Africa at (0,0) that has become a fun little easter egg in many datasources. A friend of mine dedicated this website to it: https://www.vicchi.org/2014/04/05/welcome-to-the-republic-of...
Because of time bombs like "It works well enough because nobody really lives at the poles--"
That's exactly the sort of thing that works well until one day it just breaks your code because you forgot to make sure never to to do a computation on a thing that includes on of the poles. And it won't happen because someone starts living there rather it will happen because of a complicated logical chain of reasons that make perfect sense, but only in hindsight.
Yes! So much covered in so few words. This ordering works shockingly well for constructing robust solutions to complex problems.
Keep it simple. Do what needs to be done now, leave off for later everything else. By the time later arrives, what the project needs will have gone in new and surprising directions. Refactoring complex and coupled code into logical discrete units pays off in multiples down the road. Removing that which is no longer needed is like giving your whole team extra time to breath and new room to think. For all the times that simplifying also solved the two other problems, we used that time for making more cool stuff.
First, it must be said that this is super cool, and I love it so much!
I've got questions...
1. What is the relationship between the bottom colored dots and the colored notes? I'm looking in the "scalar" tool, key of C. It looks like the bottom dots are for coloring a cross-fretboard position. I would have expected the red bottom dot to mark the position from C on the 8th fret for all the scales, as it does for pentatonic minor to dorian. However pentatonic and blues major are on the 5th fret position, and major is in open position.
2. The pentanizer, what is it? I also don't understand the relationship between the colored and numbered dots and the fretboard coloring. The UI has a strange way of switching the numbers if I switch the scales. E.g. select pentatonic major, red dot, and 1 dot. Then switch to pentatonic minor, and it auto-switches to 5 dot. Overall, it's pretty disorienting the relationship between these design elements and the scales. Or I've fundamentally misunderstood the tool.
3. What tools did you use to make this? Will you open source?
1. Bottom colored dots are connected to shape colors, nothing else. Those shapes are often (in guitar literature) referenced by number, 1 to 5 (e.g. pentatonic shape 1), I decided to use colors
2. Pentanizer is adding interval colors. It splits "scaler" shapes into 5 micro interval shapes. It is explained in https://grunfy.com/updates.html section and this video might help to understand the concept: https://www.youtube.com/watch?v=H3DCpJlGQFA&feature=youtu.be...
3. I use some own JS on top of http://svgjs.com/ library...I'll need to cleanup things and make it somewhat "stable" before opensourcing it.
Two weeks. I refer to it as the cussing period because it's full of situations where I know something is possible and easy, but I have to figure out how to find the right documentation and put together the peculiarities of the new language in my mind. Usually that feeling of frustrated helplessness goes away after two weeks.
In my circle of peers, and perhaps beyond, we use "clever" as a pejorative. It roughly means what you said in the last sentence, "more of a display of cleverness than actual cleverness." In other words, calling a piece of code clever, indicates that it was made too complicated to easily grok. We also have an explicit goal of making code not clever.
Nice! This is definitely an important tool when creating a site traffic in images to be displayed across a variety different sized screens. Having worked on this type of project before I'll mention a few challenges you have not yet addressed.
At some scale point, your single DynamicServer server will have more resize requests than it has CPU cycles to serve. The straightforward solution will be to add more DynamicServer instances. This means that your source image directory will have to be accessible from both instances. It also duplicates your cache directory, meaning a single image size could get generated on both servers. You might solve that by having a shared image cache network directory. Another solution could be to use a hash mechanism to determine a particular backend server from the load balancing layer, so any particular image would always be generated on the same instance.
Something interesting happens when people upload an image to their newsfeed. If it's a public newsfeed, there can be a good many requests of the image within the next several seconds at upload. This means that you can get multiple cache miss requests at the same time coming into your DynamicImage server. Your PHP processes are vertically partitioned, so your server will be simultaneously generating the resize. For users with only a few friends, this is a small waste of CPU cycles, but for users with massive user bases (e.g. Britany Spears), a single upload could grind your DynamicImage server to a halt just because of simultaneous duplicated work. Varnish (and other load balancers) can solve this by collapsing multiple requests to the same resource into a single HTTP call (https://varnish-cache.org/docs/3.0/tutorial/handling_misbeha...).
I really love this article about Fan Hui and AlphaGo, [The Sadness and Beauty of Watching Google's AI Play Go](https://www.wired.com/2016/03/sadness-beauty-watching-google...). It's the first time I've read a balanced intimation of what it can be like interacting with artificial intelligences. I come away from this and the Kasparov article feeling that AIs will be friends as well as partners.
It's not boorish. I only learned about this practice of new American slavery from a friend who had come out of prison recently. Not enough people are talking about it, so nobody knows this is what's going on. Please, keep talking about it!
That's a super cool detail! I once implemented a 2D index using a Z-Order curve that directly translated lat/lon coordinates to a linear ordering. It works well enough because nobody really lives at the poles--the search regions with a single projection get really obtuse there. Projecting the earth onto a 6-sided die is a really elegant solution to that problem! Go go Google engineering!