[OSM-talk-fr] Relations en boucle

[sylvain letuffe]

Le mercredi 26 mai 2010 11:48:05, Vincent Pottier a écrit :

> Bon C'est très expérimental, ça n'est pas un accident. Et JOSM n'a pas
> levé d'alerte tout au moins pas ma version.

Il indique une alerte quand une relation contient deux fois le même membre, ou 
qu'elle se contient elle-même, mais ça doit être plus dur quand la chaine 
circulaire dépasse 2 relations, sans doute car JOSM n'a pas tout télécharger.

Reste que l'API le permet, ça vaut le coup de réfléchir ensemble dans quel cas 
ça peut être utile, dans quel cas il vaudrait mieux pas, etc.

 
>   sly  :
> > Mouef, je ne vois pas pourquoi les attributs n'iraient pas directement
> > dans la relation 11980

Je m'aperçois que j'ai (nous?) avons répondu un peu sêchement alors que la 
logique expérimentale de l'essai répond à une logique et un besoin qui est 
loin d'être trivialement répondu par un "hé l'autre, hé l'es trop con, c'est 
pas comme ça c'est comme ça" . Bref, désolé pour mon ton inoportun.

> Le fait de mettre les définitions dans un objet propre permet la
> souscription à ces règles par plusieurs autres objets :
> http://www.mail-archive.com/talk@openstreetmap.org/msg29820.html
> Je suis sur qu'il y a des schémas-types

Il est clair pour moi, comme l'a résumé pieren sur le lien cité, qu'il est 
insensé de taguer 100 mille fois maxspeed=truc alors que la vitesse autorisé 
et le défaut du pays. (Comment ça, j'ai changé de discours en 1 an ?)
La question c'est "comment que c'est le mieux"

> zones A, B et C qui peuvent être tagguées (ou liées par url à un xml ou
> vCal quelconque) une seule fois. 

De ce que j'ai pû comprendre pour l'instant, la technique était de documenter 
sur le wiki les "par défaut" des différents pays, et chaque logiciel se 
démerdait. J'ai ensuite vu une discussion qui n'a pas abouti consistant à crée 
un fichier xml de "documentation" de la base pour indiquer tout les par 
défauts.

Et je découvre une idée maintenant qui consiste à utiliser les relations comme 
stockage de méta-données au sein même de la base. Je dirais, why not, 
question: y'a une doc qui explique ça sur le wiki ?


> Pieren :
> > Moi je pense que la bidirection est inutile.
> 
> L'objectif est double :
> Indiquer dans un objet qu'il souscrit à une (des) liste(s) de définitions.
> Ne pas laisser une relation sans membre : ça aurait réagit tout autant
> que pour la boucle et elle aurait couru le risque d'être détruite comme
> un point isolé.
Et si on lui donne comme membre la relation qui contient les géométries ? mais 
que elle ne la contienne pas ?
Un logiciel de reconstruction pyramidal pourrait toujours tourner sans mal, 
sans deviner laquelles/lesquelles il doit ignorer et être appliqué 
indifférement sur les deux et marcher ?


 
> De plus, à la création, il me semblait plus logique de crée une relation
> "definition" comme membre de "France" (côté pyramidal) plutôt que
> l'inverse, ce qui eut pu dérouter plus d'un (dont moi). Mais le rôle
> "apply_to" (peut-être à changer en "subscriber" ou autre mot clef
> similaire) permet peut-être de lever l'ambiguïté.

J'aime bien le apply_to, mais qui soit le rôle de la relation qui contient les 
géométries (11980) dans la relation des méta données (


> Enfin,
> http://www.openstreetmap.org/api/0.6/relation/N
> ne chargent pas les définitions et ne contient aucune indication de
> celles-ci si elles ne sont données comme membre. 

Tadam ! l'api est super bien faite :

http://www.openstreetmap.org/api/0.6/relation/11980/relations


> Je rappelle que c'est expérimental et que vos remarques sont bien-venues

Le concept est super, l'idée me plait, désolé d'avoir répondu un peu sèchement 
avant
--
sly