ES:That Shouldnt Be Possible
Si comprendes el artículo original en inglés, por favor, ayuda a completar esta traducción al español. Lee las instrucciones sobre cómo traducir este wiki.
Parece que nadie está trabajando en la traducción en este momento. Anímate y colabora en la tarea de traducción.
That Shouldn't Be Possible ("Eso no debería ser posible") es un analizador de trazas GPS en desarrollo, para analizar la correspondencia de una traza GPS con la ruta posible según la base de datos de OpenStreetMap. Esencialmente hace lo que dice. Le das una traza GPS y usa información en la traza (especialmente las marcas de hora) para decirte si, según la base de datos de OpenStreetMap, la ruta que seguiste debería ser posible. Asumiendo que la persona iba conduciendo siguiendo las reglas de la carretera, una región de una traza que "No Debería Ser Posible" es una buena indicación que algo podría estar muy mal con el mapa en esa área.
Hay una instancia prototipo de tsbp corriendo en http://ris.dev.openstreetmap.org/tsbp-proto que por ahora sólo tiene datos para las islas británicas (mantener la base de datos actualizada para todo el planeta necesita recursos de procesamiento que aun no tengo).
Código fuente
El código fuente está disponible en bitbucket en http://bitbucket.org/ris/tsbp y son bienvenidas las contribuciones. El código está bajo la licencia GPLv3.
Preguntas frecuentes
¿Qué muestra esta línea red-gris?
El "gráfico de costo" (como le llamo) muestra en qué medida una parte de la ruta No Debería Ser Posible. Ahora, esto podría significar varias cosas.
La manera en que funciona tsbp es tratar de encajar rutas posibles conocidas a las trazas que le das. Usa las marcas de tiempo en los puntos GPS para tratar de determinar qué tan posibles son las rutas entre puntos en la cantidad de tiempo que aparentemente tomaron. tsbp trata de minimizar la imposibilidad o costo.
Entonces un area de alto costpo podría ser que algo está realmente mal con el mapa, o que en alguna parte tsbp está siendo estúpido y no puede encontrar la ruta correcta. Usualmente es una combinación de ambas. En lo que a tsbp concierne, las dos son lo mismo. Si tsbp no encuentra una buena solución en una parte de la ruta, suele haber una buena razón.
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?
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.