[OSM-talk-fr] Limites administratives sur la carte OSM Inspector

[Denis]

g.d a écrit :
> Il me semble,
> qu'avec cette nouvelle approche par 'relations',
> 
> on rentrerait dans une nouvelle ère à taguer les propriétés d'un objet,
> fondamentalement différente de ce qu'on fait jusque-là...

Disons que les relations commencent à prendre leur place et je crois que 
c'est une bonne pratique et un challenge pour les moteurs de rendu et 
autres applications connexes.

> 
> Par extension,
> ce système de 'relations' devrait s'appliquer
> à toute propriété non-physique de tous éléments... (?)

Ce serait logique.

> 
> Si on voulait être conséquents,
> les "tags traditionnels" resteraient réservés aux propriétés physiques
> (classification, largeur, état de la voie, nombre de voies...),
> 
> là où les autres attributs plutôt virtuels, non-physiques,
> (name, ref, int_ref d'une voie,
> la voie à laquelle appartient l'adresse/n° d'une maison,
> ou la ligne de métro à laquelle appartient une station,
> devraient faire objet d'une 'relation' ?
> 
> (Voire
> une buvette ferait partie d'une relation débits de boisson lic III,
> un bar ferait partie d'une relation débits de boisson lic IV,
> où tous deux feraient partie de la relation restauration ?
> Et ne "reste" dans le node que ce qui n'est pas pris en compte par  
> une relation,
> ici le tag "name : "Chez Bidule" ?)
> ---
> 
> Le principe me va,
> de regrouper plusieurs ways en une "unité supérieure",
> comme plusieurs morcaux de limites communales
> en une limite de département,
> puis en frontière nationale
> (la logique de Jérôme me paraît correcte),

Oui. Plus précisément et concernant le cas particulier des limites 
communales, on peut voir cohabiter des tags, au niveau way, comme 
left:city=a, right:city:b, right:department=c, etc. et, dans le même 
temps, avoir des relations "commune" avec les tags name=x ou des 
relations departements avec name=y. L'information peut paraître 
redondante, mais pas tant que cela, sauf à disposer d'outils qui 
permettent de retrouver la topologie de l'objet.
> 
> ou de regrouper plusieurs tronçons de ways en une "route européenne E  
> machin",
> "RCEA",
> ou "route des châteaux" ou "route Jacques Cœur",
> qui eux-mêmes pourraient être dans une relation parcours touristique.
> 
> ok, même si ça fera du travail en sus,
> et obligera à huiler des aiguillages rouillées du cerveau...

C'est aussi par ces relations que se créera de la plus value par rapport 
à un simple dessin de ce que chacun a vu dans son coin. A terme, cela 
devrait engendrer moins de travail : taguer un itinéraire européen un 
seule fois (en listant l'ensemble de ses composantes) est moins coûteux 
que de taguer l'ensemble des ways, et moins source d'erreurs (hors to 
graphe).
> 
> 
> mais alors OU est la notion de regroupement en unités supérieures
> dans la "Relation:restriction", pourtant dans les "established uses" ?
> Ça revient à artificiellement introduire une unité qui n'a pas  
> d'existence,
> pour ensuite dire, qu'elle n'existe pas,
> ça me paraît absurde...

pas sûr d'avoir compris ta pensée.
Pour moi, l'avenir de la relation est aussi dans la factorisation des 
descriptions. C'est plus simple d'écrire : 4x2 plutôt que 2+2+2+2. 
Aujourd'hui on n'est pas assuré que les outils d'exploitation de la base 
en donnent comme seul résultat possible 8. C'est un chantier en cours.
Pour les restrictions, les relations sont utiles aussi (no-left-turn) 
car on met aussi de la logique de circulation et donc forcément des 
liens entre les objets de base.
> 
> Je suis réfractaire à des fonctionnements
> qui nécessitent un élément virtuel extérieur.
> Oui, je me sers de tels artifices en mathématiques,
> mais je regarde l'usage de ces "parachutes" comme une déclaration  
> d'échec,
> comme quoi je n'ai pas réussi à faire face avec mes outils 'propres'.
> ---
> 
> Je n'ai rien contre les 'relations',
> mais que cela soit
> a) conséquent et partout,
> b) simple et compréhensible,
> c) expliqué sur le wiki, en mots simples.
> (et si possible d), des "presets" en cascade pour ça, dans josm... :-)

d'accord pour [a-d]. OSM n'est pas gravé dans le marbre (ou le grès des 
Vosges), laissons-le poursuivre sa maturation.

> 
> Dans l'attente d'éclaircissement
> où s'arrête le tag sur node et way,
> et où au juste commence la 'relation',
> je continue à l'ancienne.
> 
> Gerhard

Denis