Re: [OSM-talk-fr] bano fantoir
Le 17 sept. 2022 à 18:36, didier a écrit :
>
> avec la remarque de marc
> la requete toto faire jusqu'a n fois separés par un ;
> ^(no|toto)(|(|;toto){1,5})$
>
> et celle de vincent pour la corse
> de 01 a 09 | 10 a 19 | 2A | 2B | 21 a 29 | 30 a 89 | 90 a 98
> (0[1-9]|1[0-9]|2A|2B|2[1-9]|[3-8][0-9]|9[0-8])
>
> cela donne le regex藍️
> ^(no|((0[1-9]|1[0-9]|2A|2B|2[1-9]|[3-8][0-9]|9[0-8])([0-9]{3})([0-
> 9]|[A-Z])([0-9]{3})([ABCDEFGHJKLMNPRSTUVWXYZ])))(|(|;((0[1-9]|1[0-
> 9]|2A|2B|2[1-9]|[3-8][0-9]|9[0-8])([0-9]{3})([0-9]|[A-Z])([0-
> 9]{3})([ABCDEFGHJKLMNPRSTUVWXYZ]))){1,3})$
Pour capitaliser, regex mise à jour sur le DataItem correspondant :
https://wiki.openstreetmap.org/wiki/Item:Q600
George
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] bano fantoir
avec la remarque de marc
la requete toto faire jusqu'a n fois separés par un ;
^(no|toto)(|(|;toto){1,5})$
et celle de vincent pour la corse
de 01 a 09 | 10 a 19 | 2A | 2B | 21 a 29 | 30 a 89 | 90 a 98
(0[1-9]|1[0-9]|2A|2B|2[1-9]|[3-8][0-9]|9[0-8])
cela donne le regex藍️
^(no|((0[1-9]|1[0-9]|2A|2B|2[1-9]|[3-8][0-9]|9[0-8])([0-9]{3})([0-
9]|[A-Z])([0-9]{3})([ABCDEFGHJKLMNPRSTUVWXYZ])))(|(|;((0[1-9]|1[0-
9]|2A|2B|2[1-9]|[3-8][0-9]|9[0-8])([0-9]{3})([0-9]|[A-Z])([0-
9]{3})([ABCDEFGHJKLMNPRSTUVWXYZ]))){1,3})$
Le samedi 17 septembre 2022 à 17:23 +0200, Vincent de Château-Thierry a
écrit :
> Salut Didier,
>
> Le 17/09/2022 à 14:28, didier a écrit :
> > merci pour le lien wiki
> >
> > la regle devient
> > *["ref:FR:FANTOIR"]["ref:FR:FANTOIR"!~/^(no|([1-9][0-9]|0[1-9])([0-
> > 9]{3})([0-9]|[A-Z])([0-
> > 9]{3})([ABCDEFGHJKLMNPRSTUVWXYZ]))$/][inside("FR")] {
> > throwWarning: "mauvaise référence ref:FR:FANTOIR";
> > group: tr("validation rules nat_ref in France");
> > -osmoseItemClassLevel: "9019/9019002/3";
> > -osmoseTags: list("ref", "highway");
> > -osmoseAssertNoMatchWithContext: list("way highway=residential
> > name=impasse ref:FR:FANTOIR=75106S581T", "inside=FR");
> > }
> > idem pour ref:FR:FANTOIR:left/right
> >
> > il y aura des faux postifs dans les cas de plusiers reférence comme
> > ref:FR:FANTOIR=75106S581T;75107S581L
>
> J'ai l'impression qu'il manque la possibilité de A et B en 2e
> position
> pour la Corse ?
>
> vincent
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] bano fantoir
Salut Didier,
Le 17/09/2022 à 14:28, didier a écrit :
merci pour le lien wiki
la regle devient
*["ref:FR:FANTOIR"]["ref:FR:FANTOIR"!~/^(no|([1-9][0-9]|0[1-9])([0-
9]{3})([0-9]|[A-Z])([0-
9]{3})([ABCDEFGHJKLMNPRSTUVWXYZ]))$/][inside("FR")] {
throwWarning: "mauvaise référence ref:FR:FANTOIR";
group: tr("validation rules nat_ref in France");
-osmoseItemClassLevel: "9019/9019002/3";
-osmoseTags: list("ref", "highway");
-osmoseAssertNoMatchWithContext: list("way highway=residential
name=impasse ref:FR:FANTOIR=75106S581T", "inside=FR");
}
idem pour ref:FR:FANTOIR:left/right
il y aura des faux postifs dans les cas de plusiers reférence comme
ref:FR:FANTOIR=75106S581T;75107S581L
J'ai l'impression qu'il manque la possibilité de A et B en 2e position
pour la Corse ?
vincent
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] bano fantoir
bravo pour la règle mais il vaut mieux moins détecter mais sans positif à mon avis. un "ne rien faire si ;" et si "no" est il possible ? > Le 17 sept. 2022 à 14:28, didier a écrit : > > il y aura des faux postifs dans les cas de plusiers reférence ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] bano fantoir
merci pour le lien wiki
la regle devient
*["ref:FR:FANTOIR"]["ref:FR:FANTOIR"!~/^(no|([1-9][0-9]|0[1-9])([0-
9]{3})([0-9]|[A-Z])([0-
9]{3})([ABCDEFGHJKLMNPRSTUVWXYZ]))$/][inside("FR")] {
throwWarning: "mauvaise référence ref:FR:FANTOIR";
group: tr("validation rules nat_ref in France");
-osmoseItemClassLevel: "9019/9019002/3";
-osmoseTags: list("ref", "highway");
-osmoseAssertNoMatchWithContext: list("way highway=residential
name=impasse ref:FR:FANTOIR=75106S581T", "inside=FR");
}
idem pour ref:FR:FANTOIR:left/right
il y aura des faux postifs dans les cas de plusiers reférence comme
ref:FR:FANTOIR=75106S581T;75107S581L
Le samedi 17 septembre 2022 à 13:20 +0200,
osm.sanspourr...@spamgourmet.com a écrit :
> Bonjour,
>
> ça ne peut pas faire de mal mais tu peux encore te faire rattraper
> par
> la patrouille car toutes les lettres ne sont pas autorisées :
>
> https://github.com/osm-fr/osmose-backend/blob/master/analysers/analyser_osmosis_fantoir.py
>
> Et oui :
>
> https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:FANTOIR
>
> la validité dépend aussi de la nature de l'objet portant le code.
>
> Et pour la dernière lettre, ni I, O ou Q et surtout c'est une clé de
> contrôle : c'est ça qui sert à lutter contre les fautes de frappe (je
> n'ai pas vu l'algo sur
> https://www.collectivites-locales.gouv.fr/files/Comp%C3%A9tences/5.%20am%C3%A9nagement%20de%20mon%20espace/1-cadastre/La%20description%20du%20fichier%20FANTOIR.pdf
> mais je n'ai pas cherché non plus).
>
> Jean-Yvon
>
> Le 17/09/2022 à 11:26, didier - didier2...@free.fr a écrit :
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] bano fantoir
pour osmose cela serait correct ?
*["ref:FR:FANTOIR"]["ref:FR:FANTOIR"!~/^(no|([1-9][0-9]|0[1-9])([0-
9]{3})([0-9]|[A-Z])([0-9]{3})([A-Z]))$/][inside("FR")] {
throwWarning: "mauvaise référence ref:FR:FANTOIR";
group: tr("validation rules nat_ref in France");
-osmoseItemClassLevel: "9019/9019002/3";
-osmoseTags: list("ref", "highway");
-osmoseAssertNoMatchWithContext: list("way highway=residential
name=impasse ref:FR:FANTOIR=75106S581T", "inside=FR");
}
*["ref:FR:FANTOIR:left"]["ref:FR:FANTOIR:left"!~/^(no|([1-9][0-9]|0[1-
9])([0-9]{3})([0-9]|[A-Z])([0-9]{3})([A-Z]))$/][inside("FR")] {
throwWarning: "mauvaise référence ref:FR:FANTOIR";
group: tr("validation rules nat_ref in France");
-osmoseItemClassLevel: "9019/9019002/3";
-osmoseTags: list("ref", "highway");
-osmoseAssertNoMatchWithContext: list("way highway=residential
name=impasse ref:FR:FANTOIR=75106S581T", "inside=FR");
}
*["ref:FR:FANTOIR:right"]["ref:FR:FANTOIR:right"!~/^(no|([1-9][0-
9]|0[1-9])([0-9]{3})([0-9]|[A-Z])([0-9]{3})([A-Z]))$/][inside("FR")] {
throwWarning: "mauvaise référence ref:FR:FANTOIR";
group: tr("validation rules nat_ref in France");
-osmoseItemClassLevel: "9019/9019002/3";
-osmoseTags: list("ref", "highway");
-osmoseAssertNoMatchWithContext: list("way highway=residential
name=impasse ref:FR:FANTOIR=75106S581T", "inside=FR");
}
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] bano fantoir
Bonjour, ça ne peut pas faire de mal mais tu peux encore te faire rattraper par la patrouille car toutes les lettres ne sont pas autorisées : https://github.com/osm-fr/osmose-backend/blob/master/analysers/analyser_osmosis_fantoir.py Et oui : https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:FANTOIR la validité dépend aussi de la nature de l'objet portant le code. Et pour la dernière lettre, ni I, O ou Q et surtout c'est une clé de contrôle : c'est ça qui sert à lutter contre les fautes de frappe (je n'ai pas vu l'algo sur https://www.collectivites-locales.gouv.fr/files/Comp%C3%A9tences/5.%20am%C3%A9nagement%20de%20mon%20espace/1-cadastre/La%20description%20du%20fichier%20FANTOIR.pdf mais je n'ai pas cherché non plus). Jean-Yvon Le 17/09/2022 à 11:26, didier - didier2...@free.fr a écrit : ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] bano fantoir
il y a des références ref:FR:FANTOIR=no
sur des ways et des relations.
C'est une "bonne" valeur ?
Le samedi 17 septembre 2022 à 12:17 +0200, Frédéric Rodrigo a écrit :
> Le 17/09/2022 à 11:26, didier a écrit :
> > Bonjour,
> >
> > comme je fais des erreurs de saisie, j'ai fait une regle josm pour
> > la
> > balise ref:FR:FANTOIR
> >
> > *["ref:FR:FANTOIR"]["ref:FR:FANTOIR"!~/^([1-9][0-9]|0[1-9])([0-
> > 9]{3})([0-9]|[A-Z])([0-9]{3})([A-Z])$/][inside("FR")] {
> > throwWarning: "mauvaise référence ref:FR:FANTOIR";
> > }
> >
> > cela correspond a
> >
> > pour les nodes, ways et relation => *
> > dept de 01 a 99 => ([1-9][0-9]|0[1-9])
> > commune de 000 a 999 => ([0-9]{3})
> > 1 chiffre ou 1 lettre => ([0-9]|[A-Z])
> > (apparement 1 lettre pour les lieux dit)
> > 3 chiffres => ([0-9]{3})
> > 1 lettre => ([A-Z])
> >
> > j'ai vérifié avec josm "en local" cela fait un warning
> >
> > si vous pensez que cela est ok, je pourrais l'intégrer dans la page
> > https://josm.openstreetmap.de/wiki/Rules/FranceSpecificRules
>
> Oui, et ça aussi remonter dans Osmose comme ça.
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] bano fantoir
Le 17/09/2022 à 11:26, didier a écrit :
Bonjour,
comme je fais des erreurs de saisie, j'ai fait une regle josm pour la
balise ref:FR:FANTOIR
*["ref:FR:FANTOIR"]["ref:FR:FANTOIR"!~/^([1-9][0-9]|0[1-9])([0-
9]{3})([0-9]|[A-Z])([0-9]{3})([A-Z])$/][inside("FR")] {
throwWarning: "mauvaise référence ref:FR:FANTOIR";
}
cela correspond a
pour les nodes, ways et relation => *
dept de 01 a 99 => ([1-9][0-9]|0[1-9])
commune de 000 a 999 => ([0-9]{3})
1 chiffre ou 1 lettre => ([0-9]|[A-Z])
(apparement 1 lettre pour les lieux dit)
3 chiffres=> ([0-9]{3})
1 lettre => ([A-Z])
j'ai vérifié avec josm "en local" cela fait un warning
si vous pensez que cela est ok, je pourrais l'intégrer dans la page
https://josm.openstreetmap.de/wiki/Rules/FranceSpecificRules
Oui, et ça aussi remonter dans Osmose comme ça.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] bano fantoir
Bonjour,
comme je fais des erreurs de saisie, j'ai fait une regle josm pour la
balise ref:FR:FANTOIR
*["ref:FR:FANTOIR"]["ref:FR:FANTOIR"!~/^([1-9][0-9]|0[1-9])([0-
9]{3})([0-9]|[A-Z])([0-9]{3})([A-Z])$/][inside("FR")] {
throwWarning: "mauvaise référence ref:FR:FANTOIR";
}
cela correspond a
pour les nodes, ways et relation => *
dept de 01 a 99 => ([1-9][0-9]|0[1-9])
commune de 000 a 999 => ([0-9]{3})
1 chiffre ou 1 lettre => ([0-9]|[A-Z])
(apparement 1 lettre pour les lieux dit)
3 chiffres=> ([0-9]{3})
1 lettre => ([A-Z])
j'ai vérifié avec josm "en local" cela fait un warning
si vous pensez que cela est ok, je pourrais l'intégrer dans la page
https://josm.openstreetmap.de/wiki/Rules/FranceSpecificRules
merci d'avance
didier
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] BANO, Fantoir and Co
Bonjour à tous, Quelques suggestions du jour. Est-il possible de: - faire une synthèse générale des rapprochements Bano au niveau de chaque département, histoire de voir l'avancement de chaque département sur l'ensemble de la France à l'image de ca http://cadastre.openstreetmap.fr/fantoir/stats_dept.html ou un graphique, je ne sais pas - créer une nouvelle page (cadastre.openstreetmap) recensant les différents outils et tableaux de suivi Fantoir/Bano. Il commence à y en avoir beaucoup - sur tile et autre fonds de carte utiles à Bano de renforcer la visibilité de la limite de commune. En blanc c'est pas très visible je trouve. - mettre une zone de texte libre à côté de chaque Fantoir pour précision. Utilité? -crée un nouveau statut erreur Fantoir, je pense aux voies dont l'orthogrpahe est bon, mais le rapprochement ne se fait pas à cause de la limitation du nombre des caractères sur Fantoir ou cf proposition précédente Sinon, quid des nouvelles dénominations de voies sans Fantoir encore crée/attribué. J'ai déjà 4/5 exemples sous le coude. A vos plumes pour échanger ;) Donat ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO FANTOIR : Libellé dans la couche Bano absent de la liste FANTOIR
De: Yves Pratter yves.prat...@gmail.com Je n’ai pas été clair : ce lieu-dit “Amancey” est en fait le nom du village “Amancey”. Ça ressemble donc à une erreur, d’autant plus qu’il n’y a qu’ une seule adresse avec le n°11 ? Oui j'avais bien vu. D'accord sur le fait que cette adresse, seule, est étonnante. Voire louche :) Dans les données brutes, je ne vois rien concernant le nombre d’adresses dans une voie. Fantoir s'arrête aux voies, et ne descend pas aux adresses. L'info du nombre d'adresses par voie n'est pas fournie calculée dans une des sources en tant que telle. On peut juste compter combien d'adresses on récupère, par source et par voie, par nous même. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO FANTOIR : Libellé dans la couche Bano absent de la liste FANTOIR
Bonsoir, Le 07/12/2014 08:44, Yves Pratter a écrit : Il semble s’agir d’une adresse (n° 11 Amancey) avec le nom de la ville : 25015B002M http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#19/47.03626/6.07259 Et rien ici : http://cadastre.openstreetmap.fr/fantoir/#insee=25015 Tu peux voir ici : http://cadastre.openstreetmap.fr/fantoir/liste_brute_fantoir.html#insee=25015 que ce code correspond à un lieu-dit (type_voie = 3), catégorie qui n'est pas encore traitée dans BANO. La situation est en fait un peu mixte : - côté Fantoir, tous les enregistrements (y compris lieux-dits) sont candidats aux rapprochements, dès lors qu'ils ne sont pas périmés (= avec une date d'annulation) - côté OSM les codes Fantoir des tags ref:FR:FANTOIR sont pris en compte, quels qu'ils soient, dès lors qu'ils sont valides en terme de format et situés dans la bonne commune. Les objets sans ce tag ne sont candidats aux rapprochements que s'ils sont dotés des tags name=* et highway=*. Ce qui exclut les place=* et le schéma addr:place. C'est là qu'il y a un peu de boulot... le ticket correspondant : https://github.com/osm-fr/bano/issues/50 Côté listes j'avais dès le départ prévu de consacrer explicitement des onglets à la catégorie 'lieu-dit' de Fantoir, avec la liste des LD rapprochés de nos 'place=*', et celle des non-rapprochés. D'où jusque là l'absence des Fantoirs LD dans les listes, focalisées sur les voies. À suivre donc. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO FANTOIR : Libellé dans la couche Bano absent de la liste FANTOIR
Merci pour les explications et le lien sur la liste brute :) Tu peux voir ici : http://cadastre.openstreetmap.fr/fantoir/liste_brute_fantoir.html#insee=25015 que ce code correspond à un lieu-dit (type_voie = 3), Je n’ai pas été clair : ce lieu-dit “Amancey” est en fait le nom du village “Amancey”. Ça ressemble donc à une erreur, d’autant plus qu’il n’y a qu’une seule adresse avec le n°11 http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#18/47.03650/6.07265 ? Dans les données brutes, je ne vois rien concernant le nombre d’adresses dans une voie. Christian extrait les adresses du cadastre ? Ça colle en superposant BANO et le cadastre : — Yves ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] BANO FANTOIR : Libellé dans la couche Bano absent de la liste FANTOIR
Bonjour, Il semble s’agir d’une adresse (n° 11 Amancey) avec le nom de la ville : 25015B002M http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#19/47.03626/6.07259 http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#19/47.03626/6.07259 Et rien ici : http://cadastre.openstreetmap.fr/fantoir/#insee=25015 http://cadastre.openstreetmap.fr/fantoir/#insee=25015 Bon dimanche, — Yves ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO/FANTOIR : portion de rue sans nom mais avec des adresses rapprochées !?
C'est qu'un bout de Route de Lovagny existait ailleurs dans l'emprise de la commune. Actuellement, les scripts de rapprochement ne sont pas géographiques, donc un bout de rue avec un non concordant sera rapproché même si il est à l'autre bout de la commune que les adresses. Le 28 novembre 2014 08:35, Yves Pratter yves.prat...@gmail.com a écrit : Bonjour, Le filet de BANO aurait-il des (trop gros) trous ? Je suis tombé sur une portion de route sans nom, mais les adresses étaient en bleu, hors elles devraient être en rouge ? -- Yves Route de Lovagny (sans nom jusqu'en version 7) http://www.openstreetmap.org/way/72466644/history 742130460HRTE DE LOVAGNYRoute de LovagnyORG http://www.openstreetmap.org/#map=18/45.90874931/6.04624142714FR http://tile.openstreetmap.fr/?zoom=18lat=45.90874931lon=6.04624142714 BANO http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#18/45.90874931/6.04624142714 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] BANO/FANTOIR : portion de rue sans nom mais avec des adresses rapprochées !?
Actuellement, les scripts de rapprochement ne sont pas géographiques osmose fait cette analyse : http://osmose.openstreetmap.fr/fr/errors/?country=france*item=2060class=9 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO/FANTOIR : portion de rue sans nom mais avec des adresses rapprochées !?
Le 28 nov. 2014 à 11:07, didier2020 didier2...@free.fr a écrit : Actuellement, les scripts de rapprochement ne sont pas géographiques » Merci, ça me rassure :) je croyais avoir effacé le nom par erreur :D Donc si je pige bien, il suffit d’avoir un nom de rue quelque part dans la commune pour obtenir un rapprochement avec FANTOIR… peu importe si la rue est au bon endroit. osmose fait cette analyse : http://osmose.openstreetmap.fr/fr/errors/?country=france*item=2060class=9 Je ne connaissais pas celle-là ; es Franc-Comtois ont fait du bon boulot ;-) Le code a parlé https://github.com/osm-fr/osmose-backend/blob/fa4aab4c5e79b72c1f49e15f111d2781f5983ef0/analysers/analyser_osmosis_relation_associatedStreet.py#L448 : la distance est approximativement de 200 m :D — Yves ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO/FANTOIR : portion de rue sans nom mais avec des adresses rapprochées !?
Le 28 novembre 2014 18:16, Yves Pratter yves.prat...@gmail.com a écrit : Le 28 nov. 2014 à 11:07, didier2020 didier2...@free.fr a écrit : Actuellement, les scripts de rapprochement ne sont pas géographiques Merci, ça me rassure :) je croyais avoir effacé le nom par erreur :D Donc si je pige bien, il suffit d'avoir un nom de rue quelque part dans la commune pour obtenir un rapprochement avec FANTOIR... peu importe si la rue est au bon endroit. Actuellement ou, mais c'est aussi à améliorer... -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] BANO/FANTOIR : portion de rue sans nom mais avec des adresses rapprochées !?
Bonjour, Le filet de BANO aurait-il des (trop gros) trous ? Je suis tombé sur une portion de route sans nom, mais les adresses étaient en bleu, hors elles devraient être en rouge ? — Yves Route de Lovagny (sans nom jusqu’en version 7) http://www.openstreetmap.org/way/72466644/history http://www.openstreetmap.org/way/72466644/history 742130460H RTE DE LOVAGNY Route de LovagnyORG http://www.openstreetmap.org/#map=18/45.90874931/6.04624142714FR http://tile.openstreetmap.fr/?zoom=18lat=45.90874931lon=6.04624142714 BANO http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#18/45.90874931/6.04624142714 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO/FANTOIR : CHE ANC CHEM DE… non rapproché
La dernière modification de ce fichier remonte à 3j donc l’ajout de cette entrée dans le dictionnaire ne semble pas suffire ? La rue est passée en vert ce matin. 742130520Y CHE ANC CHEM DE MOIRY Ancien Chemin de Moiry ORG http://www.openstreetmap.org/#map=18/45.9168101075/6.05271212765 FR http://tile.openstreetmap.fr/?zoom=18lat=45.9168101075lon=6.05271212765 BANO http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#18/45.9168101075/6.05271212765 JOSMID http://www.openstreetmap.org/edit?editor=id#map=18/45.9168101075/6.05271212765 P2 http://www.openstreetmap.org/edit?editor=potlatch2#map=18/45.9168101075/6.05271212765 Mais je constate que plusieurs rues ajoutées ou nommées hier avant la mise à jour de BANO sont encore en gris 742130140K CHE DE CHANTEPOULET -- ORG http://www.openstreetmap.org/#map=18/45.9352066183/6.06615597519 FR http://tile.openstreetmap.fr/?zoom=18lat=45.9352066183lon=6.06615597519 BANO http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#18/45.9352066183/6.06615597519 JOSMID http://www.openstreetmap.org/edit?editor=id#map=18/45.9352066183/6.06615597519 P2 http://www.openstreetmap.org/edit?editor=potlatch2#map=18/45.9352066183/6.06615597519 742130200A CHE DE COMBAVEY -- ORG http://www.openstreetmap.org/#map=18/45.9051767173/6.07298642021 FR http://tile.openstreetmap.fr/?zoom=18lat=45.9051767173lon=6.07298642021 BANO http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#18/45.9051767173/6.07298642021 JOSMID http://www.openstreetmap.org/edit?editor=id#map=18/45.9051767173/6.07298642021 P2 http://www.openstreetmap.org/edit?editor=potlatch2#map=18/45.9051767173/6.07298642021 742130080V CHE DE LA CAFETA-- ORG http://www.openstreetmap.org/#map=18/45.9255191468/6.07391489744 FR http://tile.openstreetmap.fr/?zoom=18lat=45.9255191468lon=6.07391489744 BANO http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#18/45.9255191468/6.07391489744 JOSMID http://www.openstreetmap.org/edit?editor=id#map=18/45.9255191468/6.07391489744 P2 http://www.openstreetmap.org/edit?editor=potlatch2#map=18/45.9255191468/6.07391489744 742130835R CHE DE LA TREILLE -- ORG http://www.openstreetmap.org/#map=18/45.9167829027/6.07847358948 FR http://tile.openstreetmap.fr/?zoom=18lat=45.9167829027lon=6.07847358948 BANO http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#18/45.9167829027/6.07847358948 JOSMID http://www.openstreetmap.org/edit?editor=id#map=18/45.9167829027/6.07847358948 P2 http://www.openstreetmap.org/edit?editor=potlatch2#map=18/45.9167829027/6.07847358948 742130450X CHE DE LETTRAZ -- ORG http://www.openstreetmap.org/#map=18/45.9199057936/6.07214683927 FR http://tile.openstreetmap.fr/?zoom=18lat=45.9199057936lon=6.07214683927 BANO http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#18/45.9199057936/6.07214683927 JOSMID http://www.openstreetmap.org/edit?editor=id#map=18/45.9199057936/6.07214683927 P2 http://www.openstreetmap.org/edit?editor=potlatch2#map=18/45.9199057936/6.07214683927 Peut-être y a-t-il encore un retard dans la mise à jour effective des données OMS ? — Yves___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO/FANTOIR : CHE ANC CHEM DE... non rapproché
Oui, problème de disque saturé sur osm105/layers utilisé par BANO pour récupérer les données OSM récentes. La mise à jour à été suspendue hier vers 14h, donc les contributions faites après ne sont pas encore prises en compte dans BANO. Le 25 novembre 2014 09:37, Yves Pratter yves.prat...@gmail.com a écrit : La dernière modification de ce fichier remonte à 3j donc l'ajout de cette entrée dans le dictionnaire ne semble pas suffire ? La rue est passée en vert ce matin. 742130520YCHE ANC CHEM DE MOIRYAncien Chemin de MoiryORG http://www.openstreetmap.org/#map=18/45.9168101075/6.05271212765FR http://tile.openstreetmap.fr/?zoom=18lat=45.9168101075lon=6.05271212765 BANO http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#18/45.9168101075/6.05271212765 JOSMID http://www.openstreetmap.org/edit?editor=id#map=18/45.9168101075/6.05271212765 P2 http://www.openstreetmap.org/edit?editor=potlatch2#map=18/45.9168101075/6.05271212765 Mais je constate que plusieurs rues ajoutées ou nommées hier avant la mise à jour de BANO sont encore en gris 742130140KCHE DE CHANTEPOULET--ORG http://www.openstreetmap.org/#map=18/45.9352066183/6.06615597519FR http://tile.openstreetmap.fr/?zoom=18lat=45.9352066183lon=6.06615597519 BANO http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#18/45.9352066183/6.06615597519 JOSMID http://www.openstreetmap.org/edit?editor=id#map=18/45.9352066183/6.06615597519 P2 http://www.openstreetmap.org/edit?editor=potlatch2#map=18/45.9352066183/6.06615597519 742130200ACHE DE COMBAVEY--ORG http://www.openstreetmap.org/#map=18/45.9051767173/6.07298642021FR http://tile.openstreetmap.fr/?zoom=18lat=45.9051767173lon=6.07298642021 BANO http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#18/45.9051767173/6.07298642021 JOSMID http://www.openstreetmap.org/edit?editor=id#map=18/45.9051767173/6.07298642021 P2 http://www.openstreetmap.org/edit?editor=potlatch2#map=18/45.9051767173/6.07298642021 742130080VCHE DE LA CAFETA--ORG http://www.openstreetmap.org/#map=18/45.9255191468/6.07391489744FR http://tile.openstreetmap.fr/?zoom=18lat=45.9255191468lon=6.07391489744 BANO http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#18/45.9255191468/6.07391489744 JOSMID http://www.openstreetmap.org/edit?editor=id#map=18/45.9255191468/6.07391489744 P2 http://www.openstreetmap.org/edit?editor=potlatch2#map=18/45.9255191468/6.07391489744 742130835RCHE DE LA TREILLE--ORG http://www.openstreetmap.org/#map=18/45.9167829027/6.07847358948FR http://tile.openstreetmap.fr/?zoom=18lat=45.9167829027lon=6.07847358948 BANO http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#18/45.9167829027/6.07847358948 JOSMID http://www.openstreetmap.org/edit?editor=id#map=18/45.9167829027/6.07847358948 P2 http://www.openstreetmap.org/edit?editor=potlatch2#map=18/45.9167829027/6.07847358948 742130450XCHE DE LETTRAZ--ORG http://www.openstreetmap.org/#map=18/45.9199057936/6.07214683927FR http://tile.openstreetmap.fr/?zoom=18lat=45.9199057936lon=6.07214683927 BANO http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#18/45.9199057936/6.07214683927 JOSMID http://www.openstreetmap.org/edit?editor=id#map=18/45.9199057936/6.07214683927 P2 http://www.openstreetmap.org/edit?editor=potlatch2#map=18/45.9199057936/6.07214683927 Peut-être y a-t-il encore un retard dans la mise à jour effective des données OMS ? -- Yves ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO/FANTOIR : CHE ANC CHEM DE... non rapproché
Le 25/11/2014 12:27, Christian Quest a écrit : Oui, problème de disque saturé sur osm105/layers utilisé par BANO pour récupérer les données OSM récentes. La mise à jour à été suspendue hier vers 14h, donc les contributions faites après ne sont pas encore prises en compte dans BANO. Avec mon informatique balbutiant, ça veut dire plusieurs jours avant reprise ? JB. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO/FANTOIR : CHE ANC CHEM DE... non rapproché
J'espère que ça prendra bien moins. Quelques tables grossissent trop vite à force d'être mises à jour. Des trous se créent et occupent inutilement de l'espace que l'on ne récupère qu'en faisant des manip un peu longues et bloquantes (obligé de suspendre les updates). Je viens par exemple de compacter la table des ways qui est passée de 108Go à 65Go... ça faisait quand même une belle éponge ! Le 25 novembre 2014 15:40, JB jb...@mailoo.org a écrit : Le 25/11/2014 12:27, Christian Quest a écrit : Oui, problème de disque saturé sur osm105/layers utilisé par BANO pour récupérer les données OSM récentes. La mise à jour à été suspendue hier vers 14h, donc les contributions faites après ne sont pas encore prises en compte dans BANO. Avec mon informatique balbutiant, ça veut dire plusieurs jours avant reprise ? JB. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO/FANTOIR : CHE ANC CHEM DE... non rapproché
Le 25 nov. 2014 à 15:53, Christian Quest cqu...@openstreetmap.fr a écrit : Des trous se créent et occupent inutilement de l'espace que l'on ne récupère qu'en faisant des manip un peu longues et bloquantes (obligé de suspendre les updates). Tu utilises VACCUUM de pgsql ? La doc http://www.postgresql.org/docs/8.4/static/sql-vacuum.html indique un mode qui n’est pas bloquant et qui est conseillé de faire régulièrement sur des tables qui grossissent trop vites : Plain VACUUM (without FULL) simply reclaims space and makes it available for re-use. This form of the command can operate in parallel with normal reading and writing of the table, as an exclusive lock is not obtained. — Yves___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] BANO/FANTOIR : CHE ANC CHEM DE… non rapproché
Bonsoir, Le chemin CHE ANC CHEM DE MOIRY http://cadastre.openstreetmap.fr/fantoir/#insee=74213 existant dans OSM (avant le lancement de la m.à.j de Bano) n’est pas rapproché : http://www.openstreetmap.org/way/79258986 http://www.openstreetmap.org/way/79258986 En regardant en diagonal le code, je trouve name = name.replace(Grande Rue Grande Rue, Grande Rue) mais rien concernant ni les CHE ANC CHEM ni les ART ANC RTE. Le problème viendrait de là ? — Yves https://github.com/osm-fr/bano/blob/master/cherche_fantoir_et_osm_highways.py#L222 https://github.com/osm-fr/bano/blob/master/cherche_fantoir_et_osm_highways.py#L222___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO/FANTOIR : CHE ANC CHEM DE… non rapproché
Bonsoir, De: Yves Pratter yves.prat...@gmail.com Le chemin CHE ANC CHEM DE MOIRY existant dans OSM (avant le lancement de la m.à.j de Bano) n’est pas rapproché : http://www.openstreetmap.org/way/79258986 En regardant en diagonal le code, je trouve name = name.replace( Grande Rue Grande Rue , Grande Rue ) mais rien concernant ni les CHE ANC CHEM ni les ART ANC RTE . Le problème viendrait de là ? Non, les substitutions se servent d'une liste de termes, et CHE ANC CHEM n'est pas répertorié. Ça devrait être ici : https://github.com/osm-fr/bano/blob/2af464fe1fe3f652fb8058178b88cd2b2b746a6e/dictionnaires/abrev_type_voie.txt#L27 Si tu peux ouvrir un ticket : https://github.com/osm-fr/bano/issues/new ? merci vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO/FANTOIR : CHE ANC CHEM DE… non rapproché
Non, les substitutions se servent d'une liste de termes, et CHE ANC CHEM n'est pas répertorié. Ben il y est déjà : https://github.com/osm-fr/bano/blob/2af464fe1fe3f652fb8058178b88cd2b2b746a6e/dictionnaires/abrev_type_voie.txt#L28 Si tu peux ouvrir un ticket : https://github.com/osm-fr/bano/issues/new ? Ok — Yves ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO/FANTOIR : CHE ANC CHEM DE… non rapproché
Le 24/11/2014 18:10, Yves Pratter a écrit : Non, les substitutions se servent d'une liste de termes, et CHE ANC CHEM n'est pas répertorié. Ben il y est déjà : https://github.com/osm-fr/bano/blob/2af464fe1fe3f652fb8058178b88cd2b2b746a6e/dictionnaires/abrev_type_voie.txt#L28 Non, tu indiques CHEMIN ANC CHE là. Et le manquant est CHE ANC CHEM, ce qui est différent (on ne parle pas du sens mais de la stricte succession de lettres). Si tu peux ouvrir un ticket : https://github.com/osm-fr/bano/issues/new ? Ok Merci. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO/FANTOIR : CHE ANC CHEM DE… non rapproché
Non, tu indiques CHEMIN ANC CHE là. Oups, c’était à la ligne 27 pas la 28 ;D La dernière modification de ce fichier remonte à 3j donc l’ajout de cette entrée dans le dictionnaire ne semble pas suffire ? Et le manquant est CHE ANC CHEM, ce qui est différent (on ne parle pas du sens mais de la stricte succession de lettres). ça me fait penser à l’effet Stroop http://fr.wikipedia.org/wiki/Effet_Stroop#Exemple dans les tests psychotechniques ;D — Yves ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] BANO-FANTOIR : Terrasse vs Traverse à Marseille
Bonjour à tous, A Marseille nous avons de nombreuses Traverses. Or sur la carte de rapprochement des sources, Traverse a l'air d'être transformé automatiquement en Terrasse. Exemple : http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#17/43.31369/5.46615 Et de fait, quand je regarde la page du rapprochement FANTOIR / OSM, je vois l'abréviation TSSE : http://cadastre.openstreetmap.fr/fantoir/#insee=13212 Le terrain et le cadastre, eux, donnent bien des Traverses et non des Terrasses. Comment corriger ça ? C'est un problème du FANTOIR non ? Charles. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO-FANTOIR : Terrasse vs Traverse à Marseille
Bonjour, Il faut ajouter le code Fantoir sur les voies en question. Par exemple, pour la Traverse de la Malvina, il faut ajouter le tag ref:FR:FANTOIR=132125623A Stéphane Le mercredi 19 novembre 2014 09:47:02, Charles Nepote a écrit : Bonjour à tous, A Marseille nous avons de nombreuses Traverses. Or sur la carte de rapprochement des sources, Traverse a l'air d'être transformé automatiquement en Terrasse. Exemple : http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#17/43.31369/5.46615 Et de fait, quand je regarde la page du rapprochement FANTOIR / OSM, je vois l'abréviation TSSE : http://cadastre.openstreetmap.fr/fantoir/#insee=13212 Le terrain et le cadastre, eux, donnent bien des Traverses et non des Terrasses. Comment corriger ça ? C'est un problème du FANTOIR non ? Charles. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO-FANTOIR : Terrasse vs Traverse à Marseille
Bonjour, De: Charles Nepote char...@nepote.org A Marseille nous avons de nombreuses Traverses. Or sur la carte de rapprochement des sources, Traverse a l'air d'être transformé automatiquement en Terrasse. Exemple : http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#17/43.31369/5.46615 Et de fait, quand je regarde la page du rapprochement FANTOIR / OSM, je vois l'abréviation TSSE : http://cadastre.openstreetmap.fr/fantoir/#insee=13212 Le terrain et le cadastre, eux, donnent bien des Traverses et non des Terrasses. Comment corriger ça ? C'est un problème du FANTOIR non ? Sur le principe Fantoir connaît bien les deux types, terrasse (TSSE) et traverse (TRA) qui sont répertoriés pour les traitements de rapprochement : https://github.com/osm-fr/bano/blob/9cb5ba5d171c7a0c5ca93f2b6d2af59a8c42f446/dictionnaires/abrev_type_voie.txt#L222 et https://github.com/osm-fr/bano/blob/9cb5ba5d171c7a0c5ca93f2b6d2af59a8c42f446/dictionnaires/abrev_type_voie.txt#L226 Si par corriger tu entends dégommer du rouge sur la carte, la seule possibilité est de renseigner le code Fantoir directement sur les ways avec le tag ref:FR:FANTOIR (ou sur la relation associatedStreet correspondante quand elle existe). Pour le plus long terme, je dois rajouter sur les pages de rapprochement OSM/FANTOIR un moyen de qualifier un code Fantoir en fonction d'une anomalie qui lui est associée (cf https://lists.openstreetmap.org/pipermail/talk-fr/2014-October/072638.html). Ça permettra de garder la mémoire de ces divergences. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO-FANTOIR : Terrasse vs Traverse à Marseille
Le 19/11/2014 10:16, Vincent de Château-Thierry a écrit : Bonjour, De: Charles Nepote char...@nepote.org A Marseille nous avons de nombreuses Traverses. Or sur la carte de rapprochement des sources, Traverse a l'air d'être transformé automatiquement en Terrasse. Exemple : http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#17/43.31369/5.46615 Et de fait, quand je regarde la page du rapprochement FANTOIR / OSM, je vois l'abréviation TSSE : http://cadastre.openstreetmap.fr/fantoir/#insee=13212 Le terrain et le cadastre, eux, donnent bien des Traverses et non des Terrasses. Comment corriger ça ? C'est un problème du FANTOIR non ? Sur le principe Fantoir connaît bien les deux types, terrasse (TSSE) et traverse (TRA) qui sont répertoriés pour les traitements de rapprochement : https://github.com/osm-fr/bano/blob/9cb5ba5d171c7a0c5ca93f2b6d2af59a8c42f446/dictionnaires/abrev_type_voie.txt#L222 et https://github.com/osm-fr/bano/blob/9cb5ba5d171c7a0c5ca93f2b6d2af59a8c42f446/dictionnaires/abrev_type_voie.txt#L226 Si par corriger tu entends dégommer du rouge sur la carte, la seule possibilité est de renseigner le code Fantoir directement sur les ways avec le tag ref:FR:FANTOIR (ou sur la relation associatedStreet correspondante quand elle existe). Pour le plus long terme, je dois rajouter sur les pages de rapprochement OSM/FANTOIR un moyen de qualifier un code Fantoir en fonction d'une anomalie qui lui est associée (cf https://lists.openstreetmap.org/pipermail/talk-fr/2014-October/072638.html). Ça permettra de garder la mémoire de ces divergences. Merci Vincent. Oui c'est le long terme qui m'intéresse. Dégommer du rouge n'a pas de sens car c'est reculer pour mieux sauter dans ce cas. Il y a un moment il faudra un feedback aux agents qui complètent le FANTOIR et il nous faut donc garder la mémoire de la divergence. En attendant la mise en oeuvre de ton excellente proposition (que j'avais loupée) je préfère ne rien rapprocher du tout et laisser les avertissements. Vous avez déjà des contacts avec la DGFip pour savoir comment ils bossent sur ces données (comment il les collectent, comment il les corrigent) ? Je peux me renseigner via Etalab mais comme Christian est déjà dans la place je suppose qu'il a toute latitude aussi ;-) Je pense que c'est très important de documenter un peu ce genre de cas : les cas de co-production / co-correction entre acteurs publics et communautés pourraient se multiplier au bénéfice de tous. Il faut des exemples solides pour convaincre plus d'acteurs. Charles. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO-FANTOIR : Terrasse vs Traverse à Marseille
2014-11-19 11:08 GMT+01:00 Charles Nepote char...@nepote.org: En attendant la mise en oeuvre de ton excellente proposition (que j'avais loupée) je préfère ne rien rapprocher du tout et laisser les avertissements. Je ne pense pas que ce soit une bonne idée. A terme, la base adresse unitifée devra identifier les divergences sur les noms de voies (ou abréviations) entres les divers bases nationales (IGN, la poste, cadastre, etc). Le moyen le plus facile pour comparer ces noms sera d'abord d'utiliser l'identifiant unique qu'est le code fantoir. En l'ajoutant dans OSM, tu valides le fait que le nom dans OSM est le nom correct. Aux autres ensuite de s'adapter. Et en leur fournissant le code fantoir depuis OSM, tu facilites la tâche de rapprochement. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO-FANTOIR : Terrasse vs Traverse à Marseille
Le 19 novembre 2014 11:08, Charles Nepote char...@nepote.org a écrit : Merci Vincent. Oui c'est le long terme qui m'intéresse. Dégommer du rouge n'a pas de sens car c'est reculer pour mieux sauter dans ce cas. Il y a un moment il faudra un feedback aux agents qui complètent le FANTOIR et il nous faut donc garder la mémoire de la divergence. En attendant la mise en oeuvre de ton excellente proposition (que j'avais loupée) je préfère ne rien rapprocher du tout et laisser les avertissements. Vous avez déjà des contacts avec la DGFip pour savoir comment ils bossent sur ces données (comment il les collectent, comment il les corrigent) ? Je peux me renseigner via Etalab mais comme Christian est déjà dans la place je suppose qu'il a toute latitude aussi ;-) Maintenant qu'on a avancé avec l'IGN et La Poste, je vais retourner voir mes voisins de bureau de la DGFiP (étage au dessus, au bout du couloir) ;) Mieux comprendre le FANTOIR, sa constitution, voir comment on peut créer un vrai lien avec la BAN... voilà les enjeux futurs. Je pense que c'est très important de documenter un peu ce genre de cas : les cas de co-production / co-correction entre acteurs publics et communautés pourraient se multiplier au bénéfice de tous. Il faut des exemples solides pour convaincre plus d'acteurs. Rajouter les ref:FR:FANTOIR permet aux scripts de faire les rapprochements et aussi de détecter les différences et donc de les remonter comme telles. J'ai par exemple remonté près d'un millier de planches cadastrales raster à la projection incorrecte à la DGFiP avec un grand merci de leur part. Je pense que pour FANTOIR une remise au propre ne pourra pas faire de mal. Le coût de la non qualité est élevé ! -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO-FANTOIR : Terrasse vs Traverse à Marseille
Le 19/11/2014 11:28, Pieren a écrit : 2014-11-19 11:08 GMT+01:00 Charles Nepote char...@nepote.org: En attendant la mise en oeuvre de ton excellente proposition (que j'avais loupée) je préfère ne rien rapprocher du tout et laisser les avertissements. Je ne pense pas que ce soit une bonne idée. A terme, la base adresse unitifée devra identifier les divergences sur les noms de voies (ou abréviations) entres les divers bases nationales (IGN, la poste, cadastre, etc). Le moyen le plus facile pour comparer ces noms sera d'abord d'utiliser l'identifiant unique qu'est le code fantoir. En l'ajoutant dans OSM, tu valides le fait que le nom dans OSM est le nom correct. Oui ça valide *implicitement* que le nom OSM est correct mais sans certitude : un mappeur pourrait vouloir attacher un code FANTOIR à une rue en dehors de toutes considération de véracité. Dire implicitement qu'un libellé FANTOIR est incorrect en rapprochant via le code ne dit pas explicitement pourquoi il y a une erreur et où est l'erreur. Le moment venu ne faudra-t-il pas refaire le travail d'explication ? On pourrait mettre l'explication dans le champ note= ? Aux autres ensuite de s'adapter. Et en leur fournissant le code fantoir depuis OSM, tu facilites la tâche de rapprochement. Je comprends bien mais je me dis que tant qu'à passer du temps sur un bug autant aller jusqu'au bout. Je me disais qu'il valait mieux commencer par traiter ceux qui ne posent pas de problème. Les autres vous fonctionnez comme Pieren sur ce sujet ? Si c'est le cas je m'incline sans problème (c'est aussi très plaisant de nettoyer du rouge ;-) Charles. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO-FANTOIR : Terrasse vs Traverse à Marseille
Ces problèmes de Terrasses et Traverses sont dues à des dizaines d'années d'errances, notamment liées à la norme postale qui si vous la lisez bien ne norme rien du tout...Comment le pourrait-elle d'ailleurs compte tenu des contraintes drastiques qu'elle s'impose (longueur restreinte des champs texte). En soit ce n'est pas grave puisque en soit une norme n'est pas un référentiel. Les problèmes sont apparus lorsque les référentiels ou apparentés ont voulu eux-même remplir cette norme postale... L'idée même d'utiliser des abréviations au lieu de noms en clairs est l'une des pires catastrophes qui puisse les affecter. Et à ma connaissance (RGE, Fantoir, RIL Insee) pour ceux que je connais, ont tous ce travers. Par rapport à ces référentiels OSM et ses produits dérivés (BANO) auront à terme une réelle supériorité. Le Mercredi 19 novembre 2014 12h01, Christian Quest cqu...@openstreetmap.fr a écrit : Le 19 novembre 2014 11:08, Charles Nepote char...@nepote.org a écrit : Merci Vincent. Oui c'est le long terme qui m'intéresse. Dégommer du rouge n'a pas de sens car c'est reculer pour mieux sauter dans ce cas. Il y a un moment il faudra un feedback aux agents qui complètent le FANTOIR et il nous faut donc garder la mémoire de la divergence. En attendant la mise en oeuvre de ton excellente proposition (que j'avais loupée) je préfère ne rien rapprocher du tout et laisser les avertissements. Vous avez déjà des contacts avec la DGFip pour savoir comment ils bossent sur ces données (comment il les collectent, comment il les corrigent) ? Je peux me renseigner via Etalab mais comme Christian est déjà dans la place je suppose qu'il a toute latitude aussi ;-) Maintenant qu'on a avancé avec l'IGN et La Poste, je vais retourner voir mes voisins de bureau de la DGFiP (étage au dessus, au bout du couloir) ;) Mieux comprendre le FANTOIR, sa constitution, voir comment on peut créer un vrai lien avec la BAN... voilà les enjeux futurs. Je pense que c'est très important de documenter un peu ce genre de cas : les cas de co-production / co-correction entre acteurs publics et communautés pourraient se multiplier au bénéfice de tous. Il faut des exemples solides pour convaincre plus d'acteurs. Rajouter les ref:FR:FANTOIR permet aux scripts de faire les rapprochements et aussi de détecter les différences et donc de les remonter comme telles. J'ai par exemple remonté près d'un millier de planches cadastrales raster à la projection incorrecte à la DGFiP avec un grand merci de leur part. Je pense que pour FANTOIR une remise au propre ne pourra pas faire de mal. Le coût de la non qualité est élevé ! -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO/FANTOIR : deux orthographes pour une voie
Ajouter un nom clairement erroné (cas de nos flamands roses) dans un des multiples tags name me semble une mauvaise idée. Laisser du rouge sur le calque BANO ne pose pas de problème, on pourra y revenir plus tard. Comme le dit Vincent, une note permet de ne pas refaire les même recherches (infructueuses) pour tenter de résoudre le problème. Il ne faut pas perdre de vue l'objectif initial: améliorer et compléter les données OSM. Ajouter des infos plus ou moins erronées juste pour dégommer du rouge dans le rendu BANO ne va pas dans ce sens et c'est donc à éviter. Le 19 septembre 2014 22:51, Jérôme Seigneuret jseigneuret-...@yahoo.fr a écrit : Ok j'en prends bonne note! Dans ce cas pouvons nous formaliser une méthode pour que les contributeurs puissent faire une requête sur la base du note ou d'un fixme? Quelle serait la règle à appliquer? Le 19 septembre 2014 22:14, Vincent de Château-Thierry osm.v...@free.fr a écrit : Bonsoir, Le 19/09/2014 20:12, Jérôme Seigneuret a écrit : Il me semble plus pertinent de mettre une balise alt_name http://wiki.openstreetmap.org/wiki/FR:Key:alt_name sur la rue en question et de faire une vérification par le code du soft en cas de non correspondance cette balise si cela n'est pas déjà le cas. Il y a une priorité sur les noms à prendre en compte il me semble: 1. name 2. official_name 3. int_name 4. nat_name 5. name:fr 6. reg_name 7. loc_name 8. old_name 9. alt_name [] (boucle avec séparateur ; si plusieurs nom) 10. short_name C'est plus propre et plus compréhensible surtout si dernière on laisse une note en expliquant que c'est pour faire une correspondance de nom entre BANO et FANTOIR. Vous en pensez quoi? Actuellement les traitements de rapprochement des noms ne considèrent que le tag name=*, il y a donc une marge de progression de ce côté là. Mais à l'inverse, ajouter un alt_name uniquement sur la foi de Fantoir, pour moi c'est se tromper d'objectif. Le alt_name devrait être issu d'une observation de terrain. Si rien ne le justifie sur place, je ne rajoute pas de alt_name. C'est dit ici régulièrement, le fait de laisser du rouge sur le calque BANO n'est pas problématique. Après, laisser une note sur des objets OSM pour éviter une perte de temps par d'autres contributeurs, ça pourquoi pas. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO/FANTOIR : deux orthographes pour une voie
Bonjour, Il me semble plus pertinent de mettre une balise alt_name http://wiki.openstreetmap.org/wiki/FR:Key:alt_name sur la rue en question et de faire une vérification par le code du soft en cas de non correspondance cette balise si cela n'est pas déjà le cas. Il y a une priorité sur les noms à prendre en compte il me semble: 1. name 2. official_name 3. int_name 4. nat_name 5. name:fr 6. reg_name 7. loc_name 8. old_name 9. alt_name [] (boucle avec séparateur ; si plusieurs nom) 10. short_name C'est plus propre et plus compréhensible surtout si dernière on laisse une note en expliquant que c'est pour faire une correspondance de nom entre BANO et FANTOIR. Vous en pensez quoi? Le 17 septembre 2014 12:11, rainerU ra...@sfr.fr a écrit : Am 17.09.2014 11:51, schrieb Christian Quest: Il faudrait pour ces cas que les 2 codes FANTOIR soient rattachés à la voie en question. On ne s'est pas encore mis d'accord sur la façon de procéder... donc laisse en l'état et si c'est toujours visible sur le rendu BANO et bien cela ne gêne pas ;) Ok. Ça me gêne juste un peu pour celui qui passera après moi et doit refaire les mêmes vérifications pour savoir si c'est rue ou avenue. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO/FANTOIR : deux orthographes pour une voie
Bonsoir, Le 19/09/2014 20:12, Jérôme Seigneuret a écrit : Il me semble plus pertinent de mettre une balise alt_name http://wiki.openstreetmap.org/wiki/FR:Key:alt_name sur la rue en question et de faire une vérification par le code du soft en cas de non correspondance cette balise si cela n'est pas déjà le cas. Il y a une priorité sur les noms à prendre en compte il me semble: 1. name 2. official_name 3. int_name 4. nat_name 5. name:fr 6. reg_name 7. loc_name 8. old_name 9. alt_name [] (boucle avec séparateur ; si plusieurs nom) 10. short_name C'est plus propre et plus compréhensible surtout si dernière on laisse une note en expliquant que c'est pour faire une correspondance de nom entre BANO et FANTOIR. Vous en pensez quoi? Actuellement les traitements de rapprochement des noms ne considèrent que le tag name=*, il y a donc une marge de progression de ce côté là. Mais à l'inverse, ajouter un alt_name uniquement sur la foi de Fantoir, pour moi c'est se tromper d'objectif. Le alt_name devrait être issu d'une observation de terrain. Si rien ne le justifie sur place, je ne rajoute pas de alt_name. C'est dit ici régulièrement, le fait de laisser du rouge sur le calque BANO n'est pas problématique. Après, laisser une note sur des objets OSM pour éviter une perte de temps par d'autres contributeurs, ça pourquoi pas. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] BANO/FANTOIR : deux orthographes pour une voie
Bonjour, La question a du être discuté ici mais je ne trouve pas de solution dans les archives ni dans le wiki. Je tombe souvent sur des voies qui ont deux codes Fantoir avec deux orthographes dont une n'est pas correcte, par exemple : - type de voie erroné, par ex. 661364856X RUE DES TAMARIS et 661364855W AVENUE DES TAMARIS. Sur le terrain c'est bien Avenue. - Fautes d'orthographe évidente: 660120073M IMP DES FLAMANTS ROSES et 6600120071K IMP DES FLAMANDS ROSES Comment traiter ces voies pour qu'ils n’apparaissent plus dans le rendu Bano? Peut on mettre deux codes Fantoir? Rainer ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO/FANTOIR : deux orthographes pour une voie
Il s'agit clairement d'erreurs dans FANTOIR. Flamnds - Flamants ! Il faudrait pour ces cas que les 2 codes FANTOIR soient rattachés à la voie en question. On ne s'est pas encore mis d'accord sur la façon de procéder... donc laisse en l'état et si c'est toujours visible sur le rendu BANO et bien cela ne gêne pas ;) Le 17 septembre 2014 10:53, rainerU ra...@sfr.fr a écrit : Bonjour, La question a du être discuté ici mais je ne trouve pas de solution dans les archives ni dans le wiki. Je tombe souvent sur des voies qui ont deux codes Fantoir avec deux orthographes dont une n'est pas correcte, par exemple : - type de voie erroné, par ex. 661364856X RUE DES TAMARIS et 661364855W AVENUE DES TAMARIS. Sur le terrain c'est bien Avenue. - Fautes d'orthographe évidente: 660120073M IMP DES FLAMANTS ROSES et 6600120071K IMP DES FLAMANDS ROSES Comment traiter ces voies pour qu'ils n'apparaissent plus dans le rendu Bano? Peut on mettre deux codes Fantoir? Rainer ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
