Mapper QA user story

One of the main purposes of Speedwalk is to find problematic data and inconsistent tagging somewhere, and make it easy for somebody to manually fix these issues. A few fixes are possible in Speedwalk directly, but many will just be opening another editor in a targeted area and having a clear task. Speedwalk's job is more to detect these problems and make the overall workflow of tackling them easy.

When all of the problems somewhere are resolved, then automated processing -- generating separate sidewalks where they're missing, and generating all possible crossings (as desire lines, even when nothing really exists) should yield pretty clean results.

## Workflow

We need to figure out the overall workflow for this. Some known tasks:

- [ ] Open iD using `gpx=` or Rapid using `wktPoly=` to focus on an area
- [x] Make it easier to refresh and grab latest OSM data after doing some work in another editor
- [x] Present a very clear task list of problems to solve, making a sense of progress more clear

## The QA checks

- There are already some "problems" defined in the tool, with some pending ones as other GH issues
- We need to think through ways of ignoring false positives (persisting those how?)
- There are some new ideas around sidewalk consistency. https://www.openstreetmap.org/way/311651687#map=18/52.757318/13.240729 is a good example of two problems. A separate sidewalk is mapped only one side, with the other tagged as `yes`. And the separate sidewalk covers almost all of this road, except a few blocks. We should urge mappers to manually finish the separate sidewalks here. It's better to consistently map separate sidewalks for an entire section of road, rather than disconnected stops and starts.
- We need a new crossing audit mode; I'll start another issue to think through this more

El issue describe un flujo de trabajo de alto nivel para QA y la detección de problemas en la cartografía de aceras. Hace referencia a los 'problems' existentes en la herramienta y a ideas para nuevas comprobaciones, como un crossing audit mode. Empieza explorando el código para encontrar las definiciones de problemas existentes y los componentes de UI que presentan tareas. Es clave entender cómo la herramienta abre actualmente editores externos (iD/Rapid) y actualiza los datos de OSM. 'Done' significa diseñar e implementar una UI y un flujo de trabajo claros para una lista de tareas, no solo un cambio aislado en el código.

Escrito por el modelo de indexación a partir del texto del issue.