a-b-street / a-b-street/speedwalk
Crossing QA: Filter data on landuse=residential / Input multipolygon
- Langage dominant
- Svelte
- Étoiles
- 24
- Forks
- 5
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Description
(This is low prio IMO and likely out of scope. But wanted to document the idea…)
When doing the QA for a larger region, we want to get an idea on the total number of intersections to validate. In this case, the non-residential intersections are likely out of scope for the project.
So maybe we could have a filter that shows only junctions that are within the buffered `landuse=residential` areas? ([Example](https://www.openstreetmap.org/way/122432927/history#map=16/52.73558/13.23360))
Or, maybe it would be better to be able to upload an area of interest multipolygon which the app transforms in the overpass bbox and then filters the QA responses on?
Guide de contribution
Aucun guide de contribution indexé pour ce dépôt
Piste de recherche
L’issue décrit l’ajout d’un filtre à l’interface QA afin d’afficher uniquement les intersections situées dans des zones landuse=residential mises en tampon ou dans un multipolygone téléversé par l’utilisateur. Commencez par examiner le code frontend utilisé pour l’affichage de la carte QA et la logique de filtrage, probablement dans des composants Svelte. Comprenez comment les requêtes Overpass sont actuellement formées et comment les résultats sont filtrés. « Done » signifie que l’UI dispose d’un nouveau contrôle de filtre qui modifie les intersections affichées en fonction des critères géographiques.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- javascript
- Domaine
- frontend, tooling
- Type d'issue
- Fonctionnalité
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Activité
- À l'abandon
- Clarté
- Plutôt claire
- Accessibilité débutants
- 35/100