Le mer. 1 juil. 2020 à 20:06, <osm.sanspourr...@spamgourmet.com> a écrit :
> J'ai vérifié : il existe une réalisation de ce formatage en PHP, donc si > vous pensez que c'est intéressant un petit +1 sur > > https://github.com/osm-search/Nominatim/issues/213#issuecomment-652466541 > > Je vois une scorie d'une ancienne version anglaise qui est présente sur la > page FR:Key:place <https://wiki.openstreetmap.org/wiki/FR:Key:place> : > postal_code <https://wiki.openstreetmap.org/wiki/Key:postal_code> Text [image: > nœud] <https://wiki.openstreetmap.org/wiki/FR:N%C5%93ud> [image: chemin] > <https://wiki.openstreetmap.org/wiki/FR:Chemin> [image: zone] > <https://wiki.openstreetmap.org/wiki/FR:Zone> Code postal. (Lui préférer > addr:postcode <https://wiki.openstreetmap.org/wiki/Key:addr:postcode>=*) > > Or la pratique en France (sauf par Philippe !) c'est d'utiliser comme > ailleurs dans le monde postal_code > <https://wiki.openstreetmap.org/wiki/Key:postal_code> sur les communes et > et de réserver les addr:* aux adresses. > C'est une pseudo-règle qui n'existe pas en France: les communes n'ont elles-même pas de code postal propre puisqu'elles se les partage à plusieurs (très souvent) et peuvent aussi en avoir plusieurs (pour les communes importantes ou dans le territoire n'est pas entièrement desservi par la poste sur la base des limites territoriales (exemple des propriétés frontalières qui ne sont desservies que depuis une rue/route d'une autre commune, la connexion entre les deux étant par des chemins privés). L'association aussi des rues avec les communes c'est le code FANTOIR et là aussi une même rue peut avoir plusieurs codes FANTOIR pour la même section, ou des codes différents pour des sections différentes. quand la rue transite par plusieurs communes ou oscille de l'une à l'autre. Chaque FANTOIR comporte son nom propre attribué par la commune correspondante, mais on ne le retrouve pas toujours comme nom sur le terrain car la voie publique peut même ne pas avoir du tout d'intersection sur la commune concernée, même si elle est l'unique accès public aux propriétés concernées qui sont sur l'autre commune. De fait les points d'adresse ne sont pas simples à associer aux rues. Les codes postaux en revanche suivent la topologie des voies publiques pour des raisons de facilité de distribution postale, sans tenir compte des limites territoriales adminsitratives (et donc pas non plus du FANTOIR. Alors que faire; on a deux tags historiques issus de propositions différentes toutes apprrouvées ou massivement utilisées "de facto": postal_code=* (qui est ue redondance introduite de façon très mal faite comme tag "informatif" mais souvent faux pour les communes. Il ne marche pas) et addr:postcode=* qui lui a été étudié spécifiquemetn pour les adresses du shcéma général des adresses (totalement indépendant du découpage administratif, comme c'est bien le cas en France, mais aussi chez la pluaprt de nos voisins, y compris en Allemagne où le schéma dit de Karksruhe a été défini et approuvé, utilisé aussi en Belgique et ailleurs). Il a fallu du temps pour qu'en France on se mette aussi à avoir des relations "boundary" pour les zones postales (comme cela a été fait bien avant en Allemagne et Belgique). Mais maintenant c'est en place. La question est plutôt: doit-on garder encore mention des codes postaux dans les relations communales ? A mon vis non, c'est une redondance qui marche mal et en fait est devenu plus gênant qu'utile. Quel tag utiliser en revanche pour les relations "boundary" des zones postales: la logique voudrait qu'on y mette aussi les tags "addr:*" du schéma de Karlsruhe. Mais pour l'isntant aucune décision d'unification n'a eu lieu. Je n'ai pas de préférence pour une solution ou une autre. On trouve les deux tags en France (issus de diférents imports ou différents contibuteurs individuels), les deux tags sont à considérer comme équivalents et ne devraient pas être différents s'ils sont renseignés simultanément. S'ils sont identiques, Un d'eux est redondants mais il y a aussi des tags liés comme "source:addr:postcode" ou "source:postal_code" qui doivent "matcher" le tag correspondant: si on supprime un tag "redondant" en laissant le mauvais "source=*", on a des warnings sur une sources d'un tag inexistant. Il faut juste être cohérent. J'ai juste pris le décision de minimiser l'impact des changements tout en réduisant le nombre de "warnings" de validation (car quand on en a trop, on ne voit pas les autres plus importants que ceux-là qui sont somme toutes mineurs). Je n'ai pas pris de décision d'unification. La seule chose calire est qu'on a des tags "addr:*:=*" pour les **noeuds** POI; mais que souvent on n'y rensigne pas grand chose, à peine un numéro parfois un nom de rue, mais toujours pas de décision pour éliminer les autres champs. En particulier la solution des relations "associatedStreet" n'est toujours pas prise, et n'est utilisée "en masse" mais partiellement qu'en France. Ailleurs, les "associatedStreet" sont très critiquées (notamment en Allemagne qui préfère encore mettre des noueds POI contenant tous les champs, quitte à introduire beaucoup de redondance entre les noeuds, le groupement se faisant alors par des filtres de sélection ; l'Allemagne tient à son schéma de Karlsruhe pour tout ce qui touche les adresses et ne pas avoir à gérer les relations entre objets liés et pouvoir gérer chaque noeud comme une entité isolée modifiable séparément; il y a du pour et du contre, c'est une question de point de vue mais aussi cela dépend des outils disponibles actuellement pour gérer la cohérence, et de la disponibilité de ceux qui les utilisent ou les maintiennent En France on utilise beaucoup Osmose, l'Allemagne, les USA, le Royaume-Uni lui préfère un autre outil de veille qualité ; il a fallu du temps pour qu'Osmose soit bien considéré par OSM au plan mondial, alors que c'est le premier et seul outil à avoir eu une couverture mondiale avec le plus d'options pour gérer l'intégration des sources, offrir des alternatives, garder le contrôle et la supervision humaine et qu'Osmose ne se contente pas d'une seule analyse masi en fournit toute une série qui permet de pouvoir trancher entre plusieurs options possibles avec le minimum d'impact ; Osmose n'a été intégré dans iD que très récemment, mais avant les préférences d'un OSM-admin britannique valaient pour tout, même si les choix faits été très fortement britto-centrés et un peu trop favorisés par les contributeurs allemands et même aussi aux USA alors que le modèle britannique ne s'y appliquait pas bien non plus ; je ne parle pas du reste du monde, en particulier l'Asie, même en Inde).
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
