ikawe

...though the elevation model I'm currently using is courser (~30m, from Mapzen skadi). This is a good reminder to fix that where available!

Hit me up if you want to use the iOS beta which has some nice transit features (already available on the web).

Though I do know some people who prefer them because they can be a little faster. Not worth it for me. I'd much rather go a little out of my way for a comfortable safe ride.

https://www.telcomhistory.org/ConnectionsSeattle.html

The volunteers there maintain a bunch of functioning cool vintage equipment you can see in action and even use.

If you never rewrite history, you could achieve something similar, but it precludes you from having a “tidy” branch.

Whether or not you’re into rewriting history is a different discussion that has been hashed out over and over again.

It’s interesting that you did the experiment, and I appreciate you sharing your results. It all seems reasonable, even if a bit depressing.

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.

I'd expect there's not a big effect on the ultimate amount of water being released downstream either way.

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.

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 can see why there is trepidation and guard rails around giving them the key to your office planner.

IIRC it was more about production methods than developing new treatments.

https://fourthievesvinegar.org/

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.

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)

According to TFA, about 95% are made in China and Taiwan.

I'd love to see OpenStreetMap.org be more directly useful to more people, rather than only as a "developer site".

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.

This happens upon initial contact and after Alice revokes her credential (which can happens if she blocks someone).

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.

https://github.com/facebook/zstd?tab=readme-ov-file#the-case...

Different folks, different key strokes.

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.

It’s a short list of charts - worth a quick scroll through if you didn’t already.

He concludes that those adhesives are causing the PETG to become brittle, and you should prefer others which don’t.