[OSM-talk-fr] Rue sans nom et relation de type "associatedStreet" et nom dans la relation

[Philippe Verdy]

Le 28 décembre 2013 21:44, Christian Quest <cquest at openstreetmap.fr> a
écrit :

> La relation c'est pour les adresses, mais le nom doit quand même figurer
> sur le highway=*
>

C'est bien dommage car les highways en eux-mêmes devraient aussi pouvoir
être modélisés en tant qu'ensemble de "routes" (le sens en anglais)
comprenant un ou plusieurs chemins (les voies possibles dans chaque sens
pour un type de transport donné (y compris les cheminements piétons), et
les équipements attachés à la voirie.

Les adresses en elles-mêmes ne font pas partie de la voirie puisqu'elles
concernent les parcelles voisines le plus souvent (hormi les voies privées
qui traversent les propriétés), mais au plan postal, on doit mentionner des
points en bordure de ces parcelles à la frontière entre voirie publique et
parcelles privées, ou parfois aussi entre deux parcelles privées sans
voirie publique (juste un droit de passage).

De fait les adresses postales ne correspondent pas géométriquement aux
voiries, ce sont des ensembles de noeuds liés à un même nom de voie d'accès
mais pas toujours reliés directement à cette voie. Et contrairement à la
voirie, les voies d'adresses n'ont pas de sens de circulation, c'est un
"cheminement" à part indépendant des moyens de transport, et théoriquement
représentant des surfaces mais sans délimitation très précise: si on se
fonde sur l'emplacement des boites à lettre c'est très vague car ces boites
ne sont pas toujours sur la parcelle utilisant l'adresse ni meˆme en
bordure de celle-ci.

Bref les adresses sont des surfaces mais trop souvent sans frontière
précise. la poste se contente d'utiliser les points le longs d'un parcours
de distribution, et sinon utilise les numéros pour savoir dans quelle boite
mettre le courrier, et ne va à la porte du domicile (en empruntant les
droits de passage privés) que pour les recommandés et remises en main
propre du destinataire (si elle ne peut pas le faire, elle laisse juste
l'avis de passage dans la boite numérotée).

Les adresses cependant ne constituent pas un pavage complet du territoire :
il y a de nombreux trous sans adresse car les parcelles même privées n'ont
pas de résident. Et du fait d'utilisation parcellaire des numéros, il n'y a
pas tellement d'autre moyen que d'admettre des relations "associatedStreet"
qui peuvent couvrir des adresses couvrant pourtant des voiries différentes.

Pour moi "associatedStreet" fait partie du schéma postal (avec aussi les
codes postaux dont une partie seulement est géographique). Les noms n'ont
pas de correspondance 1-à-1 avec les voiries (très souvent plusieurs
voiries sont regroupées dans une seule "rue" postale, et des fragments de
voiries tombent dans une autre "rue" postale, par exemple les places
traversées par une même route: au niveau postal, la rue perd localement sa
numérotation et n'est plus mentionnée, la place prenant sa propre
numérotation et son nom). Les tags de ces relations sont donc ceux du
schéma des addresses (addr:*=*) et n'ont pas d'obligation à être couplés
directement à la voirie.

On est donc bien obligé de nommer à part les "highway=*" des relations
"associatedStreet". Mais je ne vois cependant pas pourquoi on ne peut pas
assembler les fragments composant un même "highway" dans une relation de
type "route" (ou même de type "highway", si les tags "highway=*" sont
consistants sur un ensemble de fragments, sans tenir compte des
restrictions d'accès, limites de vitesse, carrefours traversés, changement
de nombre de voie ou de sens de circulation, etc.) pour éviter la
redondance des noms (y compris les noms alternatifs ou en plusieurs
langues), ou des numéro de références de voirie.

On peut donc imaginer un schéma similaire à:

(1) relation de type "route" pour chaque sens de circulation ou
embranchement dans le cas de petites branches attachée au même highway, ou
pour chaque voie de service. Ces routes peuvent être attachées en tant que
membre à un highway et/ou à un ou plusieurs réseaux de transport (qui
peuvent désigner l'ensemble sous un nom particulier différent et sous un
numéro de référence spécifique). C'est une représentation filaire (non
surfacique) et orientée. Parmi les chemins membres (orientés) on peut
toujours détailler des restrictions, des limites de vitesse différentes de
celle par défaut dans la relation.

(2) relation de type "highway" dont les membres sont des routes, des aires
de stationnement, et peut-être des équipements comme les feux, carrefours
et voies de jonction ou voies latérales de service (en somme une relation
"highway" est vu un peu comme un "route_master" sauf qu'ici il n'est pas
lié à un mode de transport ni un réseau de transport particulier, mais
attaché plutôt à un territoire traversé afin qu'on puisse par exemple
dresser une liste des rues d'une commune, avec un seul objet par rue
référençant le reste pour les détails). La relation désigne l'ensemble de
la voirie gérée par une même entité locale, mais pas les propriétés qui la
bordent, et pas forcément toutes les adresses postales qui y sont situées.

- a) Éventuellement cette dernière relation "highway" pourrait être
modélisée *aussi* de façon optionnelle comme surface (toute l'emprise
territoriale d'une autoroute, y compris ses aires de repos et de service et
stations de péage) avec des contours externes (chemins membres de rôle
"outer"/vide et "inner"), même si on y attache le filaire des membres de
type "route" (sous un autre rôle "route", que ces membres soient des
relations ou des chemins, ou des chemins fermés en surface comme une zone
piétonne). Il n'y a pas d'orientation significative de ce type de relation
"highway", ou des noeuds d'interconnexion ou points de passage obligé.

- b) Ces relations devraient exister pour grouper tous les fragments
relevant de la même collectivité ou autorité ou propriété ; si la voirie
est divisée en plusieurs secteurs (par exemple, voies centrales au
département, trottoirs et stationnement à la commune, contre-allées dans le
domaine privé, site propre pour bus ou métro à la communauté
d'agglomération...) on pourrait avoir plusieurs relations avec les
références appropriées.

(3) Ensuite la relation de type "highway" peut être l'unique membre de rôle
"street" dans une relation de type "associatedStreet" (dont les autres
membres sont les noeuds d'adresses portant le même nom que le highway
sélectionné). La relation "associatedStreet" peut aussi avoir un membre
"city" désignant la relation administrative de la commune (peut importe
d'ailleurs le niveau administratif ou le type de ville ou village ou
arrondissement municipal ou si c'est un quartier de ville ou un petit
archipel ou une île au sein d'une commune) ainsi qu'un membre "postcode"
désignant la relation codant géographiquement la surface désignée par le
code postal (mais les noeuds d'adresse peuvent utiliser d'autres codes
postaux non géographiques).

(4) Les relations de codes postaux peuvent aussi utiliser des pseudos codes
postaux de regroupement des codes postaux géographiques et des cedex, pour
indiquer dans un membre le "bureau distributeur". Ces relations de codes
postaux ont leur propre hiérarchie indépendante de l'administration
territoriale et des collectivités locales (et il peut y en avoir plusieurs
en parallèle selon l'opérateur, La Poste, Fedex, France Express, SNCF,
réseaux de portage de presse et publicité, avec chacun des codes de routage
spécifique ou pseudo-codes postaux plus ou moins géographiques, etc...).
Encore aujourd'hui quand on indique un code postal en France, on
sous-entend l'opérateur La Poste mais cela devrait être indiqué maintenant
plus spécifiquement car il n'y a plus de monopole.

Conclusion:

On ne peut pas toujours tout mettre dans la même relation mais cela ne
signifie pas qu'on puisse faire des regroupements de ways pour éviter de
tout mélanger dans un même chemin highway (avec parfois des ambiguités ou
conflits, et trop souvent beaucoup de redondance). La redondance des noms
est significative tout de même et c'est dommage de ne pas utiliser les
relations pour ça.
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20131229/7d9ff496/attachment.htm>