Post author here. OSRM was quite nice to use once I got the hang of it, thank you for it! I wrote more about it in the first part: https://blog.dend.ro/map-matching-osrm/.
I’ve been playing around with a similar project and it surprised me how hard map matching actually is. I’ve also been using OSRM, but no matter how I tweak the settings, it never gets it 100% right.
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.
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.
If I remember correctly, the last thing I was working on was actually trying to see if GraphHopper performs better! I think I was either still trying to compile it or load a local map, I’m not sure. It has been a while since I’ve worked on this.
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.
It’s quite surprising, but I expect phones do a lot of snapping and smoothing on the gps data. I’d never get anything this smooth or precise with a top of the range Garmin watch for example.
Author here. Actually, the raw data looks quite different. Snapping it to roads is what I actually wanted to do. Check out the first part for more: https://blog.dend.ro/map-matching-osrm/.
Rust is fairly nice to use for scripting / high level programming tasks. Libraries tend to be of high quality, and typically well (and consistently) documented. Ownership and borrow checking does not tend to cause issues in pipeline-like applications where everything can be basically always moved or cloned.
I think describing Rust as a "systems language" in this context is pigeonholing it, and limiting your options.
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.
This is true. In the end all programming languages are Turing complete, so you can't really argue about the power of one language over another in terms of what projects you can do with them. This is about ergonomics, and my point is that there are better alternatives with a lower cognitive load, freeing your brain to think about high level architecture, or other important things such as security, or reducing time to market, improving maintainability, etc.
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.
I think the big deal here is that Rust is the best language choice for many tasks among the languages an average coder might know. For me, it's taken over a whole bunch of tasks for which I'd have whipped out Python before, which really surprised me.
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.
> 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 think this may be more of a problem for people who are, because of the language(s) they are coming from, used to throwing everything at the garbage collector to sort out.
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!
> A garbage collector is very useful for high level projects.
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.:
Lots of very large GUI applications and libraries are written in C++, and do just fine without language-level GC. And Rust gives you tools to manage a lot of the issues you have there.
