[OSM-talk-fr] génération de fichiers .osm à partir du cadastre

Mer 20 Nov 21:35:05 UTC 2019

Le 20/11/2019 à 18:58, lenny.libre - lenny.libre at orange.fr a écrit :

> Merci de ton idée, je l'utilise assez souvent, et bêtement je faisais
> Fichier> ; je n'avais jamais pensé à me faire un bouton
>
> leni

Ou un raccourci clavier bien-sûr.

Xavier tu as lu la suite mais j'avais oublié la liste.

Tu remarqueras que vdct a déjà réagi à mes tickets !

Jean-Yvon

Le 20/11/2019 à 15:43, Xavier BIZOT - xavierbizot22440 at gmail.com a écrit :

>
> Bon j'ai tenté pour Avenue de Bretagne.
> Si quelqu'un a le temps de vérifier je suis preneur.
Voir ci-dessous, en gras remarques pour tous, en particulier pour
Vincent et Vincent.

Alors que tout semblait bien au premier abord j'ai fait du cosmétique et
du travail de fond :

- changé l'ordre :

  * d'abord les segments de rue
      o inversé la direction (R), histoire de commencer par le 1. Pas
        obligatoire mais si tu vois qu'un chemin part d'un endroit tu
        supposes que les petits numéros sont de ce bout. Veiller à ce
        que les relations utilisant ces membres soient chargées histoire
        de réordonnancer les membres si nécessaire.
      o 1 premier membre ce bout puis continué dans cet logique pour
        faire un chemin contigu (ici il ne l'est pas car interrompu par
        un giratoire, c'est l'exception qui confirme la règle)
  * ensuite les adresses
      o là encore dans l'ordre (numérique croissant)
  * ainsi on voit mieux les trous dans la raquette même si d'un point de
    vue fonctionnel c'était bon.

- nettoyé :

  * supprimé les faux numéros (ici 9001) : 0, 7XXX, 9XXX sont des
    artifices pour indiquer "là il y a quelque chose qui devrait avoir
    une adresse mais cette adresse manque dans le cadastre". Avec
    Vincent on se demandait où filtrer. Effectivement peut-être en amont
    (BANO, préparation cadastre). *Retours bienvenus.*

  *   gardé le seul attribut utile sur l'adresse c'est à dire le numéro
    : le nom de rue et le code FANTOIR sont portés par la relation, ne
    pas dupliquer limite les travaux de maintenance style X se fait tuer
    et la mairie renomme un bout de la rue. Quand tu ajouteras name:br=
    tu comprendras aussi ^^. Oui des outils comme JOSM aident à
    maintenir la cohérence mais si c'est cohérent par définition ce
    n'est pas plus mal. Grosso modo il y a deux écoles : tout mettre sur
    les points adresses et se passer de relation (école allemande : ils
    ont viré les relations car elles n'étaient pas maintenues) ou avoir
    des relations et ne pas dupliquer l'info (école française). On peut
    aussi mettre ceinture et bretelles. Quand tu regarderas les erreurs
    Osmose sur les adresses tu verras que les gens se trompent en
    mettant le nom de la rue. Et corriger des dizaines
    d'adresses...Exemple :
    http://osmose.openstreetmap.fr/fr/map/#zoom=18&lat=47.276857&lon=-2.479585&item=xxxx&level=1%2C2%2C3&tags=addr&fixable=
    (oui Marc, tu as bien vu l'auteur). Là aussi je serais partisan de
    ne proposer que la relation (en affichant ne nombre d'adresse
    proposées à l'intégration). *Retours bienvenus.*

 > Mais OverPass n’aime pas du tout mon langage…
Et on va faire au plus simple t'apprendre son langage plutôt que le
contraire.

Vincent c'est exactement pour cette raison que je chargeais a minima:
les CTRL+A ne marchent pas tout à fait mais les sélections qui suivent si.

Alors je clique sur Relation, ça crée un nouveau calque JOSM (comme ça
je ne risque pas de tout mélanger).

Je mets en fond d'écran OSM noir et blanc, ça permet de zoomer sur le
Boulevard de l'Atlantique (qui est plus grand que les deux adresses
manquantes).

Je charge avec la requête magique :

[out:json][timeout:25];
(
   // les segments de voirie
   way[name="Boulevard de l'Atlantique"]({{bbox}});

  // les associatedStreet
   relation[name="Boulevard de l'Atlantique"]({{bbox}});

  // les points adresses hors associatedStreet
   node["addr:street"="Boulevard de l'Atlantique"]({{bbox}});
);
out body;
>;
out skel qt;

Je vois un bogue, j'ouvre un ticket :
https://github.com/osm-fr/osm-vs-fantoir/issues/52

(ça normalement ce n'est pas à faire^^ mais s'il y a un soucis, il vaut
mieux vérifier s'il a été signalé et à défaut de le signaler plutôt que
maudire dans son coin)

J'ouvre l'éditeur de relation sur la relation.

Dans la boîte Sélection je clique sur rechercher, je tape
"addr:street"=*, je vérifie que c'est l'option sélectionner qui est cochée.

Dans l'éditeur de relation j'ajoute les membres.

Je trie les membres (bouton à gauche, ne pas faire à la main).

Dans la boîte Sélection je clique sur rechercher, je tape "highway"=, je
vérifie que c'est l'option sélectionner qui est cochée.

Dans l'éditeur de relation j'ajoute les membres au début et les ordonne
à la mano (je ne sais trier automatiquement).

Je ferme l'éditeur de relation.

Dans la boîte Sélection je clique sur rechercher, je sélectionne
"addr:street"=*.

Dans la boite d'Attributs je sélectionne addr:street (important !), tous
pointent sur Boulevard de l'Atlantique et il n'y a que des points
adresse, allez un clic sur Supprimer.

Dans la boite d'Attributs je sélectionne "addr:housenumber"=*.

Je vois que je suis passé de 142 à 144 adresses (les 142 préexistantes,
les 2 ajoutées par Vincent) et que les adresses sont toutes dans la
relation et sur un seul segment (position 7-150).

Je vois une suggestion à faire, j'ouvre un ticket :
https://github.com/osm-fr/osm-vs-fantoir/issues/53

*Xavier* relevé des copies sur une autre relation^^.

*Vincent P*, sais-tu pourquoi je ne peux passer des variables comme ici :

http://overpass-turbo.eu/s/OhT

Limitation de JOSM ou (comme indiqué) du serveur overpass-api.de ? Il
râle sur {{name="Boulevard de l'Atlantique"}}

Étant donné que j'exécute la requête sur ce serveur, j'ai l'impression
que c'est JOSM qui a des problèmes avec les variables (mauvaise non
substitution ?).

-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20191120/f09d0b14/attachment.htm>