pour tester le rapport; j'ai juste essayé sur une correction sur une seule voie avant de voir si le rapport se mettait à jour. Mais on dirait qu'il faut encore attendre je ne sais co,bien de temps pour voie la moindre modification à la liste; sqns doute le délai de remontée de la base OSM.ORG à la base .FR. Cette iste ne semble pas longue avec 149 codes détectés encore (148 en tenant compte de ma modif invisible; ou moins s'il y en a d'autres). Bref ça peut être fait très rapidement; mais j'attends de voir.
Question: ce rapport tient-il compte des codes FANTOIR formés du code commune, suivi de 0000 et de la lettre rivoli, utilisé par endroit pour prolonger voiries privées (essentiellement des voies de service dqns des entreprises ou centres commerciaux) où l'accès public reste toléré et n'est pas réellement fermé par des portails ? Ces voies sont nommées par endroit du même nom que la voirie publique auxquelles elles sont connectées et ont aussi des noeuds d'adresse associés; mais comme on ne peut as mettre ce code FANTOIR privé dans la relation associatedStreet pour la voie publique (qui utilise un vrai code voie non nul), il y a des relations séparées (les codes FANTOIR ne sont pas tous sur les chemins, parfois il y en a trop quand ils sont très découpés, c'est la relation associatedStreet qui les porte; et on les met rarement sur les noeuds; sauf en hqbitat dispersé pour les lieux-dits et tous petits hameaux autour d'une ferme; les adresses ne pouvant être atteintes que par une voie privée avec droit de passage pour les résidents). Est-ce que ce rapport considère en erreur les codes écrits simplement en minuscules (il ne semble pas que la casse soit réellement signifiante pour la lettre du code rivoli ou les départements de Corse). Le rapport tient-il compte aussi des codes des communes associées (différent de celui de la commune de regroupement de la fusion-association; et qu'on trouve aussi dans les codes des principales divisions cadastrales avant la lettre et le numéro code de la zone pour les communes rattachées) ? (il semble que oui puisqu'on a dans le FANTOIR un code "type de commune". Enfin tient-il compte des segments de voies qui ont 2 codes FANTOIR distincts quand la rue sert de frontière séparant deux communes (normalement pour ça il faut deux relations, une put chaque commune; chacune avec son code FANTOIR, même si la rue a le même nom des deux côtés; ce qui n'est pas non pus toujours le cas, et le même numéro de référence, ce qui n'est pas toujours le cas non plus pour de nombreux chemins ruraux). Ces relations distinctes ont de l'intérêt pour répartir les noeuds d'adresse propre à chaque commune selon le côté, et pour leur assigner aussi le bon code postal (on a de nombreux cas dans la base où le chemin mentionne un code postal ou la commune avec un tag addr:* alors que ce n'est bon que d'un seul côté; les deux relations référencent alors le même segment de chemin OSM et par souci de clarté entre les deux relations il serait bon que le nom indiqué pour la relation dans name=* ne soit pas juste le nom de la rue quand c'est le même des deux côtés, mais qu'il soit suffixé par le nom de la commune. La relation associatedStreet fait le tri en indiquant addr:city et addr:postalcode effectif appicable aux noeuds d'adresse membres). Dernier problème : de nombreux commerces et entreprises qui sont tagués dans OSM par uniquement par un noeud doivent se partager le même numéro et la même rue et même le même nom de batiment (cas des immeubles de bureaux). Comment mentionner leur adresse de "contact" autrement que par des tags addr:* qui pourtant mentionnent une adresse différente de celle de la position physique du noeud ? Ne faudrait-il pas alors utiliser "contact:*=*" au lieu de "addr:*=*" ? Ce qui permet alors de placer plusieurs noeuds distincts groupés autour du noeud d'adresse principal; même si pour chacun d'eux il faut aussi les mêmes valeurs "addr:*" pour pouvoir tous les associer à la même rue "associatedStreet" relative aux adresses physiques, plus des tags diférents pour les noms des établissements, et la typologie des services qu'ils rendent. Mais alors doit-on inclure ces noeuds groupés dans la relation associatedStreet pour qu'ils restent associés à la bonne rue physique et que le rapprochement BANO ne tente pas de les grouper selon les adresses de contact indiquées si elles le sont par les tags "addr;*" et non contact:" ? (note: les adresses de contact sont plus libres que les rues physiques du FANTOIR, puisqu'on y trouvera notamment des CEDEX, des adresses en poste restante ou boites postales, ou l'adresse d'un autre établissement ou même d'une autre société gérant le courrier telles que des sociétés de domiciliation et de secrétariat; ou des assos d'entreprises, ou bien encore l'adresse personnelle de son gérant ou administrateur légal; le nom du contact étant alors différent du nom du lieu à l'emplacement du noeud ou polygone physique ainsi marqué). Le 26 janvier 2015 15:49, Vincent de Château-Thierry <[email protected]> a écrit : > > > De: "Frédéric Rodrigo" <[email protected]> > > > > Pas tout a fait. Les codes FANTOIR ne sont rendu public via le > > FANTOIR > > annuellement, mais les communes le reçoivent avant et peuvent le > > diffuser. > > Oui il ne faut pas l'exclure. Mais le sondage que j'ai pu faire sur les > ~150 codes remontés jusque là montre une majorité de cas où la différence > entre un code connu de Fantoir et le code connu d'OSM est sur 1 caractère : > un 8 compris comme un 3 ou le contraire, etc. Donc plutôt sur des codes pas > forcément tous neufs, et entrés à la main en relisant le calque BANO, par > ex. > Après, si on ne parvient pas à tout corriger, avec le Fantoir actuel > (millésime 2014), ça n'est pas un souci. Ça donnera l'étendue des codes > dont tu parles, plus récents. > > vincent > > _______________________________________________ > Talk-fr mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/talk-fr >
_______________________________________________ Talk-fr mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-fr
