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

[g.d]

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à...

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

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,
ou
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),

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...


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...

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... :-)

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
---


Le 18 nov. 08 à 20:55, Denis a écrit :

>
> Jérôme BLUM a écrit :
>> Bonsoir,
>>
>> Bon alors, la plupart des erreurs de boundaries en Île-de-France,  
>> c'est
>> de moi :o)
>> http://tools.geofabrik.de/osmi/? 
>> view=boundaries&baselayer=Mapnik&opacity=0.30&lon=2.16638&lat=48.7543 
>> 1&zoom=11&overlays=coastline,boundary_relations_1,boundary_relations_ 
>> 2,boundary_relations_3,boundary_relations_4,boundary_relations_5,boun 
>> dary_ways_1,boundary_ways_2,boundary_ways_3,boundary_ways_4,boundary_ 
>> ways_5,boundary_ways_with_unknown_admlvl,non_simple_boundary_ways
>>
>> Le truc, c'est que je note les admin_level au niveau des  
>> relations, et
>> pas au niveau des ways directement, car un way peut-être utilisé par
>> plusieurs relations avec des admin_level différents. C'est le cas par
>> exemple lorsqu'un way correspond à la limite d'une commune, mais  
>> aussi
>> d'un département (voire d'une région). Les ways sont donc juste  
>> tagués
>> boundary=administrative, le reste étant mis dans les relations.
>>
>> En gros, j'utilise ce qui est décrit dans cette page :
>> http://wiki.openstreetmap.org/wiki/Relations/Proposed/Boundaries
>>
>> Si ça vous va pas, vous savez maintenant sur qui taper !
>>
>> a+
>> Jérôme
>
> Merci Jérôme de te dénoncer (nan je déconne, on aurait finit par te
> retrouver ;-). En fait, CQFD : les objets immatériels ont besoin d'une
> méthodologie pérenne : ton raisonnement tient la route. Un autre  
> est de
> dire : on tague l'objet le plus précis le plus complètement  
> (normalement
> la commune) et les autres objets "supra-communaux" surchargent (à la
> manière java) les infos : admin_level=x, name=y, etc.
> Dans un raisonnement tautologique, cela s'applique aussi au niveau
> communal, mais il reste un way qui n'a plus de sens en soi à part le
> fait de dire (ce que tu as fait) qu'il soit une limite administrative.
> Je ne souhaite pas lancer le débat ici et maintenant, mais une des
> questions est de déterminer s'il faut privilégier uniquement les
> relations pour décrire les classes d'objets immatériels ou s'il n'est
> pas nécessaire que la brique de base soit porteuse de suffisamment
> d'informations pour elle-même.
> Personnellement, je voyais la relation "commune" comme étant
> l'ordonnancement des ways (dans le sens trigonométrique ?) constituant
> la ban communal à partir des limites commune X/commune Y.
> A l'assaut du wiki !!
>
> Denis
>
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>