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
>
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藍️
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";
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
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");
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:
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 :
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
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
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
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
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,
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
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
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 :
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
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
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
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
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
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
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
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
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
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
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,
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
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 :
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
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
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
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
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
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 :
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
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
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
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
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
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
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
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
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
43 matches
Mail list logo
