Mapping my walks with OSRM and Rust
blog.dend.ro
blog.dend.ro
Some examples: the GPS error is often more than the distance between a road and a cycling path next to the road, so it often confuses them.
The default cycling profile of OSRM actually takes into account the possibility of dismounting and walking with the bike. This is very useful when that is what you did, but it also creates a lot of extra possibilities. For example, a one way cycling path can then be used in the opposite direction by walking.
There’s also a limit to how many points it can process at once (and it becomes quite slow if you increase that). Should I slice up the trip in multiple segments and then somehow connect them, or is it better to drop some of the points? Still haven’t found out what the best option is.
It also helped me spot some subtle errors or missing data on OSM, but that's easy enough to fix.
Interesting. Did you try GraphHopper? You'll always find cases where it performs poorly but overall we get positive feedback for it and it is very often right and performs als in most cases fast. You can try one bike example here: https://graphhopper.com/api/1/examples/#map-matching or send your examples via our JS client https://github.com/graphhopper/directions-api-js-client
Probably one current problem of the bike profile is that we do not yet allow to walk in the opposite direction, but this might be beneficial for map matching.
Also, I don’t expect it to be 100% correct everywhere, sometimes the GPS data is just not good enough or I might have traveled in a way that the map wouldn’t allow, but there were some instances I found where I thought it should’ve been able to find a match and it didn’t.
I wonder if I could do something similar with my Garmin data.
Rust can be used as a Python replacement despite not sharing some of its properties. It's a matter of choosing the tradeoffs the author is comfortable with: the familiarity with and availability of libraries, the ability to run unfinished code versus being informed about mistakes at compilation, etc.
There's nothing inherent about Rust that makes it unsuitable for high level projects.
I don't agree. A garbage collector is very useful for high level projects. The problem with Rust is that you might run out of options once your project grows bigger. So in fact, choosing Rust is limiting your options. Garbage collected closures are very powerful, and missing in Rust. It's probably one of the reasons why Rust has no stable GUI yet.
I've been writing Rust for years now, and the number of times I think "jeez, I wish I had a garbage collector right now" are so very few and far between that I can't come up with a single example right now.
That is to say, I really think it has more to do with what you're familiar with.
> It's probably one of the reasons why Rust has no stable GUI yet.
I don't think there's much to this hypothesis. It's more likely that for people who really want something right now, there are plenty of bindings to GTK etc. that work quite well. People who are interested in a novel, idiomatic Rust GUI framework tend to be more interested in thoroughly exploring lots of different ideas than committing to one of them. That is to say, there's not actually any great urgency to slap together something that works that you could call "a Rust GUI", because in practice plenty of those options already exist!
Rust solves most (or even more) of the problems GC does already with the borrow checker, I'd argue that one does not want to spent time thinking about stutters/latency spikes due to micro pauses or stop-the-world events from a GC in a very complex code base — granted GC's got a lot better, but there are still issues out there.
At work, we may not be the big, huge enterprise project, but Proxmox Backup Server is not small either and packs a lot of features (REST API, content addressable storage layer, backup management, system (network, time, update) management, ...) together spanning from low to high level. So, I'd figure it has at least a medium complexity. The thought that a GC would help us never entered my mind, nor did any of our devs mention it — most of them explicitly expressed at some time that they are glad there's no GC.
Besides that, Rust makes refactoring a bliss, which is a major plus point in big, complex projects with multiple teams working on a (partially) shared code base.
> It's probably one of the reasons why Rust has no stable GUI yet.
I think that is rather a reason of why a rust GUI could be superior to use, even from another language (GC or not) — I mean, it allows memory management without GC (slightly better performance, faster memory reclaim and no micro-pauses or the like) but also avoids lots of memory (mis)management bug classes. But yes, you're right in that there's no good plain-rust GUI framework with a stability guarantee, druid may be pretty close and has some project showing that it can work OK and look good already, e.g.:
Dealing with garbage is a waste of intellectual effort, and is not something you want to be doing in high level projects.
There's a big gap between "not perfect" and "unsuitable".
I have nothing against Rust. I'm sure it is a great language for systems work. I would love to see a language combining the power of Rust with that of e.g. Haskell, so Rust code could be used in the inner loops and Haskell code could orchestrate the high-level parts of the application. But let's not fool ourselves that Rust is the best choice of language for just about any project, which is the impression you get from all of these Rust-oriented blogposts on HN lately.
But it's absolutely not perfect at those tasks. Worse, now I see how Python was never perfect at them. I wish I knew which language combines their advantages for prototyping high level things.