HN user
I'm usually working on geospatial stuff, usually in rust.
domain: endoftheworl.de
Say hi to mkirk at the above.
I know this isn’t a very interesting comment, but just to provide some balance to the mostly negative comments I’m seeing:
It’s interesting that you did the experiment, and I appreciate you sharing your results. It all seems reasonable, even if a bit depressing.
It’d be nice if they at least mentioned the existing pure rust implementation.
https://github.com/KillingSpark/zstd-rs
And better yet if they compared it explicitly in their “why” section. As it is, I’m left guessing.
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.
(outside an abortion facility)
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.
Deployment/rollback is handled by k8s config.
(Headway maintainer here)
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.
Open source is weird. It’s like everyone on the entire planet is your coworker and you have no real say in their hiring, on boarding, or firing.
I can see why there is trepidation and guard rails around giving them the key to your office planner.
These folks gave an interesting talk on producing pharmaceuticals at defcon a couple years ago.
IIRC it was more about production methods than developing new treatments.
If your brain was distributed as software, I think it might?
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.
https://about.maps.earth/posts/2023/03/adding-transit-direct...
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.
[1] https://organicmaps.app (though there are others)
[2] https://github.com/headwaymaps/headway (see a hosted demo at https://maps.earth)
This article is entirely about where displays are produced, so no need for “from the gut” stats.
According to TFA, about 95% are made in China and Taiwan.
Official? I've never heard this as official doctrine. Can you point me to anything official?
I'd love to see OpenStreetMap.org be more directly useful to more people, rather than only as a "developer site".
Background:
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.
For example, before you have Alice’s sealed sender authorization credential, you cannot send Alice Sealed Sender.
This happens upon initial contact and after Alice revokes her credential (which can happens if she blocks someone).
https://signal.org/blog/sealed-sender/
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.
Custom dictionaries are a feature of vanilla (non-seekable) zstd. As I understand it, all seekable-zstd are valid zstd, so it should be possible?
https://github.com/facebook/zstd?tab=readme-ov-file#the-case...
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.
Different folks, different key strokes.
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.
Yes, but there is a reproducible difference between when different adhesives break the PETG.
He concludes that those adhesives are causing the PETG to become brittle, and you should prefer others which don’t.
It’s more of a “jostle” than a stir when cooking spaghetti in a frying pan.
What’s the issue with yanked crates? It should still build from your lockfile, even if it contains yanked crates.
This is an aside, but I’d never seen that “Beyond 2000” show before.
Retro future is a favorite topic of mine, so thanks for sharing.
Yeeesh though, re: part 2 of that episode, it’s wild to watch people in 1988 articulate the looming threat of global warming, and to hear them say on this 25 year old program “we’ve known about this for 30 years”
I’m not an expert, but I’d like to know more. To me it’s interesting to know what the workers are concerned about specifically.
Otherwise it just reads like “lots of people are mad”. Well about what exactly?
It’s fine for a headline, but not very impressive reporting.
I’m going to assume the “illegal” is hyperbole, but yes I agree.
Another pet peeve of mine is omitting the time frame for wage increases. A 25% raise today is not the same thing as a 25% raise over the course of 4 years.
The current "mile", the "International Mile", is very close to the 1593 "statute mile", going through a lot of history, but ultimately coming from 1,000 (a "mil") paces.
The kilometer: As part of the widespread rationalization that occurred during the French revolution, the meter was defined in 1791 as 1 ten millionth the distance of a line drawn from the equator to the north pole, through Paris.
Golden ratio: 1.618... km / mile ratio: 1.609...
So, seems like just a coincidence.
But these are fun:
https://en.wikipedia.org/wiki/Mile https://en.wikipedia.org/wiki/Kilometre
The context here is that IE has absolutely dominated the browser market for years in 2005.
So I read it as “Given we’re trying to have an alternative to IE, it’s silly for us to further fracture the ecosystem, rather than collaborate on a viable contender.”
Wikipedia shows november 2005 browser share as 88% IE, firefox at 8%, and netscape+other at 2%. (not sure why this doesn’t add up to 100%)
One probably small thing: Having a cohesive ecosystem where you can share links makes a map app more useful.
There’s a lotta links to a lotta documents in this world, and this one is a few dozen pages longer than I can quickly peruse.
Anything in it you want to highlight?