That Shouldnt Be Possible

That Shouldn't Be Possible's solution map

That Shouldn't Be Possible ("tsbp") is an under development GPS trace analyzer for analyzing a GPS trace's correspondence with the routability of the OpenStreetMap database. Essentially it does what it says. You give it a GPS trace and it uses various pieces of information present in the trace (most importantly the timestamps) to tell you whether, according to the OpenStreetMap database, the route you took should be possible. Assuming the person was driving/cycling according to the rules of the road, a region of a trace that Shouldn't Be Possible is a good indication that something may be significantly wrong with the map in that area.

Source

Source is on bitbucket at http://bitbucket.org/ris/tsbp and contributions are welcome. Code is under the GPLv3.

Demos

Talk at SotM Scotland(Youtube), October 2013.

Bookmarklet

For a little added convenience, here's a bookmarklet (huh?) that can be used to jump from the openstreetmap.org trace page (e.g. https://www.openstreetmap.org/user/PHerison/traces/1134833) to the tsbp page for solving it, without you having to do any of that looking-up-copy-pasting-the-id nonsense:

javascript:(function(){window.location="https://ris.dev.openstreetmap.org/tsbp-proto/solve?osm_trace_id="+/\/traces\/(\d+)\b/.exec(window.location.pathname)[1]}())

To install it, create a new bookmark and paste the above code into the destination url field. Run it by loading the bookmark when viewing the desired location on openstreetmap.org (more information).

FAQ

What is this red-grey plot showing?

The "cost plot" (as I call it) shows to what extent a part of the track Shouldn't Be Possible. Now, that could mean one of a couple of things.

The way tsbp works is it tries to fit known possible routes to the traces you give it. It uses point timestamps to try and determine how Not Possible point-to-point routes should be in the amount of time it apparently took. As tsbp works, it tries to minimize the impossibility or cost.

So an area of high cost could be either somewhere there's something genuinely wrong with the map or somewhere tsbp's being stupid and can't find the right route. Often it's somewhere in between. As far as tsbp's concerned, the two things are the same. If tsbp's not really finding a good solution in part of a track, there's often a good reason for that.

But tsbp is sometimes wrong, and that's why we have Recalculations where you can give it a hint as to what was really going on at a point and ask it to give the situation some more thought.

What are the red crosses/red blocks on the plot?

tsbp generally only looks in the ~100m around a trackpoint. If a suitable candidate road can't be found inside that area, tsbp simply totally ignores it. You can also manually ask tsbp to totally ignore a trackpoint (or trackpoints) in a recalculation by selecting "Ignore this point" from the point's pop-up menu in the cost plot.

It doesn't work on my browser!

This is never going to work on IE8 or lower. In fact I don't even know if it works on IE9. It probably should. I'm thoroughly fed up with having to deal with old broken browsers and sitting by the sidelines unable to use the last ten years of web features. In all my other web projects I have to deal with IE, and I've had it. This project is a clean break where I'm allowing myself to use modern features without spending all my time on byzantine fallbacks.

Please use a real browser.

Does it support (routing feature...)?

tsbp is built using OSRM as its router, and so generally supports the features/restrictions it supports. I deliberately try to keep the OSRM routing profile as "vanilla" as possible, and don't really want to tweak it to e.g. allow it to pass through gates unhindered, allow it to go on access=private roads, because, really... to some extent what we're trying to test is whether a "normal router" would be able to generate a route corresponding to the trip that was taken. And if a vanilla OSRM is refusing to go through a barrier=lift_gate, perhaps what we should be looking at is whether the particular feature should be tagged as such, or whether OSRM should generally be letting people through them, or whether a much better tagging scheme is needed for this sort of thing. Because otherwise, we might have the situation where OSRM isn't allowing any routing into or out of the Isle of Dogs.

In a similar way, tsbp may also prove to be an effective way of finding bugs in OSRM itself.

What do you mean by a prototype?

Well.. I'm going to be changing things. And possibly breaking things. And while tsbp's url scheme is designed for solutions to be "permanent", in the prototype I'm not going to have much fear deleting old solutions if I really need to. I'm not sure if people have much need of a permanent solution, but I'm a big believer in permanent urls, so, whatever.

And there are some ugly corners. And a whole heap of features I haven't implemented yet.

How often is the planet updated?

Nightly. At 3 in the morning-ish UTC. And it is not yet graceful if it happens to be calculating one of your solutions at that time. Your solution will probably just get killed and leave you to try again. But what are you doing trying to analyze GPS traces at 3 in the morning anyway?

On that subject, recalculations can only be done on the planet snapshot their solutions were started with. Because otherwise all kinds of strange ambiguities get involved. So don't expect to be able to hit "recalculate" on a solution the next day and have it work.

So... what is this useful for?

That Shouldn't Be Possible can often find even quite minor errors, for example here a slightly screwed up section of the M6 near Carlisle is shown as a small but noticeable peak in the cost plot

It's useful for whatever you find a use for it for. (?)

Really, it can be used as a general error checker. It can be used to test complex junction systems work as intended. You could think of a GPS trace as a statement of truth. "This route is possible". And so you could consider each trace like a unit test for data. Things are somehow going wrong when the unit tests don't pass.

Another way of looking at it is as a timesaving tool. Manually poring along a massive trace that you've uploaded looking among the 99% of your journey that is already mapped for the 1% of your journey that isn't already mapped is really very boring and time consuming. People who do a lot of driving or somehow else generate a lot of trace data I'm sure find this too much of a pain to bother looking at their traces in detail. With tsbp, you should be able to point it at your trace and minutes later have highlighted that one place on the trip where you used a slip road we don't have yet.

This would probably prove even more useful in countries which aren't as complete as the UK. Or countries that have had an import with areas of lower and higher quality.

The plot mostly just seems to correspond to the speed I was going

That's probably a good thing. It probably means everything on that track is more or less a-ok. Real routing problems tend to cause spikes that absolutely dwarf speed-caused costs.

Since all cost in tsbp is relative (absolute costs would be impossible with the different accuracies of GPS devices, different logging rates, different logging schemes etc.), tracks display costs normalized to the costliest point in the track. So don't try comparing costs between tracks.

On the subject of speed, tsbp takes speed limits into account. Of course, a red/high cost section doesn't necessarily mean you were speeding, but the closer you are to the speed limit the more Not Possible it is likely to look. Of course, this does often catch out problems with wrongly defined speed limits. If someone's marked a section of a trunk road as a 30 limit and you tear down it at 70, it's quite rightly going to say That Shouldn't Be Possible™.

What about GPS accuracy?

tsbp uses DOP values if present (I highly recommend trying to get your device to include these in trace files, though many just don't), so should try and cause less of a fuss and be more flexible in its search where the GPS is telling us there are accuracy problems.

But in general, traces further from the target road will cause a higher cost than otherwise. But then again, that's quite possibly a problem that tsbp should indeed be flagging up. The GPS could be right and the existing road could be inaccurate. It's up to you to try and deduce from other sources or argue it out with someone with a different trace.

How do I upload a trace?

You don't. Traces are all taken from OSM's traces. You need to upload them to OSM, make them publicly visible, and supply tsbp with the trace id of the desired trace. Yes, eventually there's going to be a nicer way of doing this and also a way of analyzing peoples private traces using oauth, but it's not a huge priority now.

Doing it this way means I don't have to worry about licenses of traces or having any stewardship of peoples data, gives me a few guarantees about the validity of the gpx files, and means all the source traces are uploaded to OSM for posterity. And eventually I want to drive a few useful things (e.g. transport type) off the trace's tags.