HackerTrans
TopNewTrendsCommentsPastAskShowJobs

ikawe

1,060 karmajoined há 15 anos
I'm usually working on geospatial stuff, usually in rust.

domain: endoftheworl.de

Say hi to mkirk at the above.

comments

ikawe
·há 5 dias·discuss
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.
ikawe
·mês passado·discuss
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.
ikawe
·há 5 meses·discuss
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.
ikawe
·há 6 meses·discuss
(outside an abortion facility)
ikawe
·há 6 meses·discuss
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.
ikawe
·há 6 meses·discuss
(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.
ikawe
·há 6 meses·discuss
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.
ikawe
·há 7 meses·discuss
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.

https://fourthievesvinegar.org/
ikawe
·há 8 meses·discuss
If your brain was distributed as software, I think it might?
ikawe
·há 9 meses·discuss
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.
ikawe
·há 9 meses·discuss
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)