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

Issue mô tả một workflow ở cấp độ cao để QA và phát hiện vấn đề trong việc lập bản đồ vỉa hè. Issue đề cập đến các 'problems' hiện có trong công cụ và những ý tưởng cho các bước kiểm tra mới như crossing audit mode. Hãy bắt đầu bằng cách khám phá codebase để tìm các định nghĩa vấn đề hiện có và các component UI dùng để hiển thị các tác vụ. Việc hiểu cách công cụ hiện mở các trình chỉnh sửa bên ngoài (iD/Rapid) và làm mới dữ liệu OSM là rất quan trọng. 'Done' có nghĩa là thiết kế và triển khai một UI danh sách tác vụ cùng workflow rõ ràng, không chỉ thực hiện một thay đổi code đơn lẻ.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.