La remarque vaut pour le pays ou la ville; cependant il y a des exceptions pour les codes postaux, notamment dans les villes qui en ont plusieurs (et toujours pas de publiciation officielle de leur délimitation par la poste, on en a juste une idée approximative, avec aussi des exceptions sur les rues qui longent les frontières communales ou les recoupe plusieurs fois...) et les codes postaux "spéciaux" (CEDEX et groupements de boites aux lettres ou autres modes de distribution: pour pas mal de POI il est justifié de préciser le code postal quand il est ambigu et pas résolu par le géocodage).
donc en gros oui, mais dans le détail on ne peut pas exclure leur besoin. Et à moins d'avoir créé des relations associatedStreet, répéter addr:street=* sur les noeuds d'adresse (eux-mêmes différents des adresses des POI) est souvent la seule façon de lever les ambiguités dans les zones ubaines denses. Le lun. 7 sept. 2020 à 09:14, Éric Gillet <e+talkfr2...@linuxw.info> a écrit : > Le 06/09/2020 à 22:23, Romain MEHUT a écrit : > > Quand j'ai supprimé les polygones boundary=urban, il m'est arrivé de faire > quelques corrections annexes comme de retirer des tags addr:country, > addr:city en particulier sur les relations des radars de vitesse. > > Un contributeur m'a contacté car il utilise ces tags pour contrôler leur > présence via la requête suivante : > > Vous validez ma méthode et vous êtes d'accord pour retirer les tags addr: ? > > Je suis entièrement d'accord > <https://www.openstreetmap.org/changeset/90163011>, il y a de nombreuses > façon de géocoder ce genre d'objets, mais mettre les tags en dur sur chaque > ne me semble pas la bonne non plus. > _______________________________________________ > 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
