Petites requêtes Overpass de contrôle qualité

Voici une collection de quelques requêtes Overpass pour détecter des problèmes potentiels. Ces requêtes sont assez simples et peuvent donc comporter des faux positifs. À utiliser avec prudence.

Pour les utiliser :

1. Cliquez sur la requête.
2. Lisez les commentaires qui expliquent le type de problème ciblé, comment le corriger, et les cas de faux positifs et faux négatifs auxquels s’attendre.
3. Déplacez la carte et zoomez sur la zone qui vous intéresse.
4. Cliquez sur “Run” en haut à gauche.
5. Cliquez sur un des nœuds ou ways pour vérifier qu’il correspond au problème ciblé.
6. Puis cliquez sur le lien en haut du pop-up pour éditer la zone dans ID.
7. Ce n’est pas Osmose donc on ne peut malheureusement pas cacher les faux positifs.

Voirie

Visualisation

• Tous les lampadaires
  Le but est principalement de visualiser où se trouvent les lampadaires.

• Voies non éclairées et lit atypiques
  En ville la plupart des voies publiques sont éclairées. Il peut donc être intéressant de visualiser où se trouvent les voies non éclairées ou qui ont une valeur atypique dans le champ lit afin de vérifier que tout est correct.

• Voies souterraines ni toujours éclairées, ni éclairées à la demande
  Voies souterraines qui ne sont ni toujours éclairées (24/7), ni éclairées à la demande (automatic).

Anomalies potentielles

• Voies enterrées
  Un élément avec location=underground est enterré, c’est à dire directement au contact de la “terre” qui le recouvre jusqu’à la surface. Cela rendrait une route ou une voie de chemin de fer impraticable. C’est pourquoi les voies souterraines se trouvent normalement dans un tunnel.

Cheminements piétons

Visualisation

• Visualisation des chemins piétons atypiques
  En ville la plupart des chemins piétons sont soit des trottoirs soit des passages piétons. Ici le but est de visualiser les chemins piétons atypiques ou sans type spécifié afin d’identifier ceux qui ne semblent pas à leur place et pourraient avoir été mal classés.

Anomalies potentielles

• Passages piétons non/mal connectés aux trottoirs
  Vise à détecter les problèmes suivants :
  • Passage piéton connecté au milieu d’un chemin piéton au lieu d’être connecté à une extrémité. Cela force à placer barrier=kerb au milieu du trottoir ce signifie qu’un piéton empruntant le trottoir doit franchir bordure de trottoir à cet endroit. C’est bien évidemment faux et pourrait impacter le routage des fauteuils roulants, poussettes, trottinettes, etc.
  • Passage piéton directement connecté au passage piéton d’une rue adjacente alors que normalement il y a soit un îlot soit un passage piéton entre.
  • Passage piéton connecté à rien parce que les trottoirs n’ont pas (encore) été ajoutés dans OpenStreetMap.
• Nœud highway=crossing sur chemin piéton
  Vise à détecter les problèmes suivants :
  • Trottoirs qui traversent une rue.
  • Nœuds highway=crossing à l’intersection du trottoir et de l’allée d’une propriété privée.

• Intersections entre chemin piéton et rue
  Vise à détecter le cas ou un trottoir croise une rue sans que la partie qui traverse la chaussée ne soit marquée comme un passage piéton.

• Mauvais crossing=* pour un passage piéton avec feu piéton
  Certains passages piétons ont crossing=marked ou uncontrolled alors qu’il y a un feu piéton et qu’ils devraient donc avoir crossing=traffic_signals.

• Feu tricolore fusionné avec le passage piéton
  Les véhicules doivent normalement s’arrêter avant le passage piéton. Le nœud du feu tricolore devrait donc être distinct du nœud représentant le passage piéton.

• Passages piétons avec une valeur crossing invalide, aka “Crossing Bad”
  • Il peut être utile pour les personnes malvoyantes de savoir quel type de passage piéton elles vont rencontrer mais ce n’est possible que si le champ crossing est renseigné. Les algorithmes de routage spécifiques pourraient aussi vouloir privilégier les passages piétons avec feu.
  • De nombreux passages piétons ont une valeur crossing obsolète.

• Crossing incohérent entre nœud et chemin
  Les passages piétons et cyclistes peuvent être représentés à la fois par un nœud highway=crossing sur la rue, et par un chemin highway=footway + footway=crossing (resp. cycleway). Chacun a un attribut crossing pour décrire le type de passage piéton / cycliste et ces deux attributs doivent donc avoir la même valeur.

• Crossing:markings incohérent entre noeud et chemin
  Les passages piétons et cyclistes peuvent être représentés à la fois par un nœud highway=crossing sur la rue, et par un chemin highway=footway + footway=crossing (resp. cycleway). Chacun a un attribut crossing:markings pour décrire le type de marquage au sol et ces deux attributs doivent donc avoir la même valeur.

• Crossing et markings incompatibles
  La propriété crossing indique le type de passage piéton ce qui implique pour certains la présence ou l’absence de marquage au sol. La propriété crossing:markings donne plus de détails sur le type de marquage au sol… ou sur leur absence. Cette requête vérifie donc que ces deux champs sont compatibles.

• Trottoirs qui forment une boucle
  Lors de l’arpentage, par exemple avec StreetComplete, un contributeur ne voit que la portion du trottoir qui se trouve dans sa rue. Or un trottoir qui forme une boucle passe par plusieurs rues que l’arpenteur ne peut voir lorsqu’il contribue. Il risque donc de renseigner une valeur pour lit ou surface qui n’est pas valable dans ces autres rues ou, s’il se rend compte du problème, devra renoncer à sa contribution.

• Chemins piétons qui devraient probablement être scindés
  Plus un trottoir est long, plus il est difficile de s’assurer que des propriétés comme lit ou surface sont valables d’un bout à l’autre, notamment s’il couvre plusieurs rues comme dans le cas ci-dessus. Les passages piétons s’étendent aussi parfois nettement au-delà de la chaussée.

Métro

Visualisation

• Métros en surface et aériens
  Les métros sont généralement souterrains mais certaines portions peuvent être aériennes. Le but ici est de visualiser ces portions afin de vérifier qu’elles correspondent à votre connaissance du terrain. Cela permet également d’identifier les ateliers de maintenance d’un coup d’œil.

Anomalies potentielles

• Quais de métro couverts
  Les quais des métros aériens sont généralement couverts et ont donc covered=yes. La plupart des autres quais sont souterrains, donc tunnel=yes, et dans ce cas ajouter covered n’a pas vraiment de sens.

Pipelines

Anomalies potentielles

• Champ location des bornes de pipelines
  Détecte les valeurs anormales du champ location des bornes (marker). Par exemple location=underground pour marker=aerial ! Mais on trouve aussi location=overhead qui voudrait dire qu’un véhicule peut passer sous la borne ?

• Champ utility des bornes de pipelines
  Vise à détecter les cas où le contributeur a confondu utility et substance, ou bien a mis utility=yes à la place d’une valeur plus spécifique.

Lignes électriques

Anomalies potentielles

• Lignes électriques sans cables ou voltage Il est intéressant de spécifier le nombre de câbles et le voltage des lignes électriques RTE (>=50kV) et du réseau de distribution (principalement 20kV).

• “Croisement” de lignes électriques
  Plusieurs lignes électriques peuvent arriver à un même poteau ou pylône. Lorsque cela arrive il est utile de savoir si elles sont reliées électriquement ou pas, ce que permet de déterminer la propriété line_management.

• Détails manquants pour transformateur sur poteau
  Plusieurs propriétés des transformateurs sur poteau sont facilement accessibles et devraient donc être systématiquement renseignées.