What do you think is happening to the water not being utilized in the production of power? I assumed it's still being run downstream, just not through the power producing turbines.
I'd expect there's not a big effect on the ultimate amount of water being released downstream either way.
Transit routing is provided by OpenTripPlanner, so the deployment artifact is their OTP serialized graph format.
So it’s not really incremental with respect to the existing transit zone deployment. I just mean I can redeploy a single transit zone with the latest GTFS without having to touch the other transit zones, tileserver, geocoder, etc.
Indeed there is currently no incremental update in Headway, and deployments are largely an exercise left to the reader.
For maps.earth (a Headway planet deployment), I typically rebuild the world, and then do a blue/green deployment.
I guess the one exception is for transit routing. We have individual transit zones small enough to fit into memory, which can be deployed incrementally. There’s nothing really built in about it - just another level of indirection via our “travelmux” service which redirects your routing queries to a different backend depending on mode and region.
I'd love it if it were easier than I think, because I spend a lot of time thinking about it! I host maps.earth, which is a planet sized deployment of Headway mapping stack (which I also maintain).
To first order, you're right on about the storage size of a vector tileset and an geocoding dataset based on OpenStreetMap. But Google maps is a lot more than that!
Headway uses Valhalla for most routing. A planet wide valhalla graph is about ~100gb of storage. It doesn't produce reasonable transit directions. Transit is an even tougher cookie.
OpenTripPlanner gives good transit routing, but it doesn't scale to planet-wide coverage. We've settled on a cluster of OTP nodes for select metro areas - each one being on the order of 5-10GB of RAM.
So, I'd say we have some of the pieces of a general purposes mapping tool that could replace Google Maps usage, which you could host yourself.
But we don't have satellite imagery, real time traffic data, global transit coverage, rich POI data (like accurate opening hours, photographs, reviews).
Do all people want all these features? Probably not, but a lot of people seem to want at least some of it and it's not obvious to me that they'll be quickly solved.
One tricky thing about maps, as they relate to privacy, is that the earth is large.
Compare that to encrypted email: if I’m sending you an encrypted message, the total data involved is minimal. To a first approximation, it’s just the message contents.
But if I want “Google Maps but private,” I first need access to an entire globe’s worth of data, on the order of terabytes. That’s a lot of storage for your (usually mobile) client, and a lot of bandwidth for whoever delivers it. And that data needs to be refreshed over time.
Typical mapping applications (like Google Maps) solve this with a combination of network services that answer your questions remotely (“Tell me what you’re searching for, and I’ll tell you where it is.”) and by tiling data so your client can request exactly what it needs, and no more, which is also a tell.
The privacy focused options I see are:
1. Pre-download all the map data, like OrganicMaps [1], to perform your calculations on the device. From a privacy perspective, you reveal only a coarse-grained notion of the area you’re interested in. As a "bonus", you get an offline maps app. You need to know a priori what areas you’ll need. For directions, that's usually fine, because I’m usually looking at local places, but sometimes I want to explore a random spot around the globe. Real-time transit and traffic-adaptive routing remain unaddressed.
2. Self-host your own mapping stack, as with Headway (I work on Headway). For the reasons above, it’s harder than hosting your own wiki, but I think it’s doable. It doesn’t currently support storing personal data (where you’ve been, favorite places, etc.), but adding that in a privacy conscious way isn’t unfathomable.
Mapping applications split up data into "tiles" so you can download only the data you are currently looking at. For example, you don't want to download the entire planet, just to look at your own neighborhood.
Historically, these tiles were literally images that the client application (i.e. web map) could "tile" side by side to cover the part of the map you were looking at. Now we refer to those images as "raster" tiles, to differentiate them with "vector" tiles.
Rather than a rendered image, Vector tiles contain the raw data that you could use to render such an image. Vector tiles allow a smaller file size and more flexibility. For example, with vector tiles you can crisply render at partial zoom levels, keeping lines sharp and avoid pixelating text. The client can also have customizable styles - hiding certain layers or accentuating others from the vector tiles.
Vector tiles are not new technology. For example, Google Maps started using them over a decade ago. So why has it taken so long for OpenStreetMap.org? One reason is no doubt a lack of engineering capacity. There were also concerns about older and less powerful clients hardware not being up to the task, but that concern has lessened over time.
OpenStreetMap also has some unique requirements. It is a community edited database, and users want to see their edits soon (immediately really). It's not feasible to dynamically generate every tile request from the latest data, so caching is essential. Still, to minimize the amount of time tiles will be stale, a lot of work went into being able to quickly regenerate stale tiles before the new vector tiles were rolled out.
The short version is: Traditionally, Bob needed to “log in” to be able to send a message to Alice’s inbox.
With Sealed Sender, Alice gives Bob a credential that allows him to message her from now on without logging in.
Only Alice can tell that the message she received is from Bob.
There’s some subtlety around bootstrapping these credentials and preventing abuse which means that not every message can be sent as Sealed Sender, but the vast majority are. Read the blog post for the authoritative explanation.
There’s an option in the app settings to make visible which of your messages were sent without identifying your client to the server if you’re curious.
Typically I’m a vim in terminal kind of person. Every few years I go galaxy brain and try to be a terminal in vim person, but it just never works out for me.
I think by and large this doesn’t play out with trains. American trains tend to be much less frequent, slower, and less comfortable than most European trains.
I road a swiss train a couple years ago that was something like 5 minutes late. To me (American) it was “on time” but the conductor came on the PA and apologized. He did make a point to clarify the delay was because they’d been stuck behind an off schedule German train.
Counting yes, but the charts in the article show that the largest group of shooters is students. About 1/3 are unrelated to the school or have an “unknown” relationship .
It’s a short list of charts - worth a quick scroll through if you didn’t already.
domain: endoftheworl.de
Say hi to mkirk at the above.