Re: [OSM-talk-fr] SeFaireConnaitre et le problème des adresses

[Romain MEHUT]

Il s'agit des tags contact:housenumber et contact:street

Romain

Le 27 juillet 2017 à 11:34, marc marc  a écrit :

> contact:addr m'a l'air d'être une rustine parce que la variété
> d'encodage des adresses rend le système bancal.
> Dupliquer les infos en préfixant avec contact ne change rien.
> Il y a à peine 47 occurrences mondiale pour contact:addr:housenumber
> L'administration n'attribue pas une adresse à un café, à un magasin ou
> une boite aux lettre.
> Elle attribue l'adresse à une parcelle/bâtiment.
> La notion de parcelle n'est pas crée dans osm et parfois imprécis sur le
> terrain.
> Je persiste donc à penser que l'adresse devrait se trouver sur le
> bâtiment ou sur son entrée.
> c'est d'ailleurs la seule façon d'éviter les erreurs de devinettes quand
> les bâtiments ne sont pas en rang d'ognon en bord de rue.
> Je pense qu'on devrait ouvrir un chantier pour finaliser la doc.
> Parce qu'une carte qui laisse autant d'incertitude dans les adresses, je
> trouve que c'est problématique. surtout pour les cas aussi simple qu'une
> adresse par bâtiment.
>
> Une fois l'adresse du bâtiment définit sans ambiguïté, il suffit de
> mettre le poi dans le bâtiment. l'inclusion de l'un dans l'autre suffit
> à décrire parfaitement son adresse.
>
> Quand magasins qui ont une adresse de correspondance différente de
> l'adresse du bâtiment, n'est-ce pas souvent le cas de chaîne ?
> Dans un précédent message, plusieurs pensent qu'il ne faut pas mettre le
> site web d'un poi lorsque celui-ci concerne la chaîne.
> par cohérence, ne faut-il la même chose pour les adresses ?
> le problème étant qu'en l'absence de relation pour grouper tous ces
> magasins, on a aucun objet sur qui mettre les infos de la chaîne.
> La question est ouverte et d'ici là cela me semble la seul vrai
> utilisation de contact:addr:housenumber et assimilées
>
> Bonne chance pour donner une ligne directrice à SeFaireConnaitre
> quand on a presque autant de nuance d'avis que de personne
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] SeFaireConnaitre et le problème des adresses

[marc marc]

contact:addr m'a l'air d'être une rustine parce que la variété 
d'encodage des adresses rend le système bancal.
Dupliquer les infos en préfixant avec contact ne change rien.
Il y a à peine 47 occurrences mondiale pour contact:addr:housenumber
L'administration n'attribue pas une adresse à un café, à un magasin ou 
une boite aux lettre.
Elle attribue l'adresse à une parcelle/bâtiment.
La notion de parcelle n'est pas crée dans osm et parfois imprécis sur le 
terrain.
Je persiste donc à penser que l'adresse devrait se trouver sur le 
bâtiment ou sur son entrée.
c'est d'ailleurs la seule façon d'éviter les erreurs de devinettes quand 
les bâtiments ne sont pas en rang d'ognon en bord de rue.
Je pense qu'on devrait ouvrir un chantier pour finaliser la doc.
Parce qu'une carte qui laisse autant d'incertitude dans les adresses, je 
trouve que c'est problématique. surtout pour les cas aussi simple qu'une 
adresse par bâtiment.

Une fois l'adresse du bâtiment définit sans ambiguïté, il suffit de 
mettre le poi dans le bâtiment. l'inclusion de l'un dans l'autre suffit 
à décrire parfaitement son adresse.

Quand magasins qui ont une adresse de correspondance différente de 
l'adresse du bâtiment, n'est-ce pas souvent le cas de chaîne ?
Dans un précédent message, plusieurs pensent qu'il ne faut pas mettre le 
site web d'un poi lorsque celui-ci concerne la chaîne.
par cohérence, ne faut-il la même chose pour les adresses ?
le problème étant qu'en l'absence de relation pour grouper tous ces 
magasins, on a aucun objet sur qui mettre les infos de la chaîne.
La question est ouverte et d'ici là cela me semble la seul vrai 
utilisation de contact:addr:housenumber et assimilées

Bonne chance pour donner une ligne directrice à SeFaireConnaitre
quand on a presque autant de nuance d'avis que de personne

Le 27. 07. 17 à 10:51, Philippe Verdy a écrit :
> "contact:*" n'est pas nécessairement "à" l'adresse du point, ce qui est 
> indiqué est une adresse de contact postal qui peut être complètement 
> ailleurs et même pas géolocalisée (par exemple une boite postale ou un 
> CEDEX), ou l'adresse d'un service tiers de gestion de relations client, 
> ou l'adresse du siège social gérant tout une série d'établissements.
> On aura donc besoin de "contact:*" et "addr:*". Je suis juste d'accord 
> sur le fait que "addr:*" doit être géolocalisé au POI, et ne désigner 
> alors qu'un unique établissement.
> 
> Le 27 juillet 2017 à 08:26, Christian Quest  > a écrit :
> 
> Oui, pas très malin comme remarque...
> 
> Le problème pour moi est plutôt indiquer l'adresse d'un POI avec
> addr:* plutôt que contact:* car le POI n'est pas "l'adresse", mais à
> l'adresse...
> 
> On a du coup des positions d'adresses souvent peu homogènes
> lorsqu'on abuse des addr:*
> 
> Ensuite ça s'aggrave quand on doublonne en un vrai point définissant
> l'adresse et un addr:* rajouté à un POI proche.
> 
> Dans les scripts BANO, il y a un traitement spécifique lorsqu'on a
> de multiples addr:* pour une même adresse, pour éliminer ceux qui
> potentiellement devraient être un contact:*, en regardant si il y a
> d'autres tags (shop, etc)... mais c'est un pis aller.
> 
> 
> 
> Le 26 juillet 2017 à 20:34, lenny.libre  > a écrit :
> 
> Par contre dans les remarques qui leur sont faites, je ne vois
> pas pourquoi on devrait supprimer le addr:street, c'est nouveau ?
> 
> Le commentaire : "Le positionnement géographique permet de
> savoir que le "2" fait référence à la Place de la Nuit du 6 Août
> 1944".
> Un addr:street=Place de la Nuit du 6 Août 1944 serait donc
> inutile. Si vous ne comprenez pas, allez sur place et regardez
> les numéros de rue : y figurent juste un nombre, sans nom de rue. "
> 
> me parait un brin radical, car ce n'est pas toujours le cas, on
> met la rue en tant que addr:street ou relation
> 
> :https://wiki.openstreetmap.org/wiki/WikiProject_France/Tracer_des_b%C3%A2timents#Ajout_des_adresses
> 
> 
> 
> Dans le cas que tu as cité, il faisait partie d'une relation
> (donc on pouvait supprimer le addr:street) mais s'il n'y a pas
> de relation, il ne faut pas le supprimer.
> 
> Maintenant SeFaireConnaitre supprime les addr:street même quand
> il n'y a pas de relation
> https://www.openstreetmap.org/node/507550316#map=19/44.63221/-1.14615
> 
> 
> 
> 
> En autre, s'ils mettent des contact:phone, contact:fax ils
> pourraient mettre contact:housenumber, ...
> 
> https://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Bremen_Schema
> 
>