[OSM-talk-fr] Adresses...

[Jérôme Seigneuret]

Bonjour,


En effet l'adressage marche comme un arbre. Suivant le niveau de finesse,
l'adresse peut être déclinée sur beaucoup d'objet de type variable.



Les entrées, les portails, les bâtiments, sont des informations
importantes. Le schéma n'est pas trivial! Et les besoins pour accéder à une
adresse ne l'est pas non plus




   - le schéma le plus simple est le placer l'adresse au portail (mais il
   peut y en avoir plusieurs
   - le deuxième au bâtiment
   - le troisième à l'entrée
   - le 4ème dans le tronçon de voirie ou rapporté au tronçon
   - et il y en a d'autre.



Les besoins de précision ne sont pas les même pour tout le monde. Il serait
même utile d'avoir des doubles infos avec l'adresse au point d'accès et
l'accès au point de livraison.

C'est la notion aussi des cedex pour les pros. Il y a l'adresse d'accès et
l'adresse courrier. Il me semble que cette notion a été abordé lors des
discutions sur l'usage de contact:housenumber



Si l'on prend une logique purement spatiale sans avoir à répéter l'adresse
sur des objets, cette adresse devrait être soit sur un polygone soit sur
une relation.



L'adressage est un élément complexe désignant un ensemble d'éléments. D'où
cette discussion sans fin avec des cas toujours plus farfelus. (Sans
compter que certaines villes ce sont mises à vouloir faire de l'adressage
pour les éléments public de la ville > devenu inutile avec les GPS et algo
de rapprochement)





La notion de parcelle dans le document m'inquiète car la parcelle peut être
à cheval pour plusieurs bâtiments, numéro d'adresse etc. Dans ce cas c'est
un découpage particulier qui est cohérent comme celui des code postaux
(hors Cedex car c'est sur le site de tri postal), celui des villes et les
rues. Bonjour la finesse des données... Donc pour moi une parcelle postale
ne doit exister que si un point n'est pas suffisant pour définir une
adresse. C'est le cas pour certains niveau comme pour les ZA etc les
Résidences et d'autres à lister.



Si l'on part du principe parcellaire qui évolue... l'adressage évoluera en
parallèle dans 90% des cas. Surtout si l'adressage est métrique
(déplacement d'entrée = nouveau numéro)



Arf! Je vois rue sans adresse et un 99999... C'est de la gestion de base à
papa! Soit on ne mais rien 'NULL' soit on ajoute un élément permettant de
définir l’inexistence réel d'information mais pas une valeur aberrante.
Bref l’inexistence est une valeur en soit. Sinon il vaut mieux mettre un
commentaire exploitable et normalisé.



Le “15 rue des Mimosas” montre bien l'exemple dans l'adressage multiple
même si actuellement Osmose retourne des alertes pour l'ensemble à cas de
multiplicité.



Coté date de mise à jour... ça dépends aussi dans quel sens la mise à jour
est effectuée. Dans ce cas il manque aussi la source de la mise à jour et
le créateur initiale pour comparaison.



Il faut intégrer plus de cas dans ce document. Ces cas sont assez valable
pour des particuliers mais un peu moins sur des pro ou sur des ZI ZA ... de
lieu-dit car ils sont tagués au format point dans beaucoup trop de cas.

À noter que certaines ZI n'ont pas de nom de rue ni de numéro de voie.

Quant au zonage réel des ZI ou ZAC, si l'on se base sur le landuse on se
retrouve sur des problématiques de découpages à causes des activités
humaines de la dite zones. En clair le nom est plus lié à un découpage du
même type que les parcs et les communes ce qui permettrait également de les
exploiter dans l'adressage.



Coté lieu-dit, les voies sont dans certains systèmes une partie intégrante
du nom du linéaire. Cela simplifie le routing. Ce n'est pas le cas dans OSM
et c'est la même chose pour le nom des résidences.

Les résidences sont nommées de manière variable (au bâtiment, au landuse,
sur un place et parfois réellement sur la voie car la commune a mis un
panneau de voirie pour la résidence)



Cordialement,

Jérôme Seigneuret
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20170118/6a27021d/attachment.htm>