Author of Mapbox's Vector Tile specification here and also contributor to some of the code that is used by PostGIS and I wanted to add some additional clarity on some topics associated with Vector Tiles and dynamic serving of them that seems to be a new trend.
The Vector Tiles specification was designed for map visualization but has expanded into other uses as well, but in general the purpose is to be able to quickly provide a complete subset of data for a specific area that is highly cacheable. Most of this provided speed and cache-ability is specifically gained by preprocessing all the data you will use in your map into tiles.
The general steps for turning raw data into Vector Tiles are:
1. Determine a hierarchy of your data. For example if you are talking about roads at some zoom levels you will want to see only highways or major roads while at other zoom levels you will want all your data.
2. For each tile at each zoom level; Select your data following your hierarchy rules, simplify your data based on your zoom level (for example you might need less points to display your road) and then clip your data to your tile and encode it to your Vector Tile.
The problem is that doing these steps is often very complex and requires thought about the cartography of your final resulting map, but it can also drastically effect performance. If you are dynamically serving tiles from PostGIS it is very hard to reduce large quantities of data quickly in some cases. For example take a very detailed coastline of a large lake that is very precise and you are wanting to serve this dynamically. If you are attempting to serve this data on demand each time you need a tile you have to simplify and clip a potentially massive polygon. While this might work for single requests, if you increase in scale this quickly adds lots of load to a PostGIS server. The only solution is to cache the resulting tiles for a longer period to limit load on your database or to preprocess all your data before serving.
Preprocessing of all the tiles is already something other tiling tools such as tippecanoe are really good at doing and comes with the benefit of helping you determine a hierarchy for your data. Preprocessing might seem excessive when it comes to making potentially millions of tiles, but in general it makes your application faster because it is simply serving an already created tile.
Therefore, if your data does not very change quickly I would almost always suggest using preprocessing over dynamic rendering of tiles. You might spend more effort maintaining something than you expect if you start using PostGIS to create tiles on demand over existing tiling tools.
If you are interested in learning more about George, you should listen to him talking at Mapbox's Locate conference with the Mapbox CEO, Eric Gundersen [1]. Its another example of George being George. I just happened to be called out during the talk, but overall rather enjoyed it.
There are a lot of things being written outside of Node currently [1]. However, a large number of the tools are in node, primarily because lots of people at Mapbox are using Node. However, most of these are backed by C++ libraries so the potential is there for lots of porting to different languages, other people simply need to build against them. Some of the non-Mapbox libraries are not as up to date with the specification, but they are getting much better!
As an author of the vector tile specification it is really exciting to see how many different things people can do with the format. People are using data in ways that constantly amaze myself and others. There is an ever growing number of tools that have been built around the format and the future seems bright. I really enjoyed your map, great job!
If there was ever a game that encouraged me to become a developer during my youth it was definitely Railroad Tycoon. I remember being so curious how everything might have worked within the game with out knowing a thing about programming and it was definitely an inspiration to me in so many aspects. Games were my avenue for learning DOS and later my learning to write Software. I can't imagine what my life would have been like with out so many great early game developers.
As a background, I used to work on the FAA - WAAS[0] a system that provides more accurate GPS and more importantly provides realtime integrity reports of GPS for users. A big part of my work was studying ionospheric storms and how they affected GPS. We made the majority of analysis from collected data from the late 90s and onward, the sad truth is that we have no real idea of what a massive solar event would do to satellites and the earth.
Satellites in general have a very hard time discharging large amounts of current, because there simply is no ground and the possibility of a Carrington Event[1] in the modern age is simply frightening. An event of this size today could possibly knock out thousands of satellites at once -- including the entire GPS constellation.
The effects on earth could be very damaging too, what would happen we aren't quite certain. However, you could see arcs from power lines or any long distance wire as it would provide easy paths for electrons. This also could affect any computers much like an EMP blast. We could be looking at a large percentage of all electronics broken. So we might suddenly have large areas, with no power, no electronics, and no communication.
After spending lots of time learning about the science behind these storms, to me this is the stuff of nightmare fuel.
There is a very large difference between clinical depression and situational depression. The ideas and suggestions of those who have suffered from situational depression are often not very helpful for those who suffer from clinical depression. I think this article is clearly about situational depression, but I don't think people often know there is a difference.