Une relation sert à regrouper un ensemble de ways connectés ensembles : - Les ways isolément ne représentent alors que des lignes et pas une surface, ils peuvent donc avoir les attributs/tags d'une barrière. - En revanche la relation ignore les attribits des ways membres, et possède ses propres tags pour mentionner ce que désigne la surface. - Toute surface fermée représentable par un way fermé peut être transformée en relation, afin de découper ses ways (et dans ce cas ils ne se ferment plus isolément et ne peuvent pas représenter une surface.
Tout dans ton message indique ton incompréhension. Regarde le wiki documentaire au sujet des relations de type=multipolygones (les type=boundary utilisés pour définir la surface d'une région par ses frontières)sont un cas particulier de multipolygone. ===== NOTES ANNEXES ==== Les relations OSM peuvent avoir d'autres usages, quand elles servent à regrouper des ways qui ne se ferment volontairement pas dans la relation : - les rivières par exemple (type=waterway), ou les routages de lignes de transport (type=route) - les "type=multilinestring" aussi (pour représenter un morceau de frontière commune entre deux régions), expérimental. Elles ne représentent aucune surface puisqu'elles ne sont normalement pas fermées, et n'ont donc pas de côté interne ni externe (inner/outer) comme les relations de type=boundary. Par défaut toutes les relations qui ont des ways qui se ferment représentent une surface, sauf justement les rivières (avec leurs ways membres de rôle "main_stream" par défaut, ou "side_stream", au contraire des ways membres de rôle "riverbank" qu'on peut y mettre aussi), et les rues/routes/chemins/pistes (highway=*) pour lesquels on doit encore utiliser area=yes dans la relation si on veut représenter leur surface et non le contour (exemple : les places piétonnes), et les voies ferrées (railway=*) pour lesquelles il n'y a aucun usage d'area=yes actuellement défini.. Par défaut aussi, toutes les mêmes relations qui ont des ways qui ne se ferment pas ne représentent que des lignes (continues ou pas). Toutes les relations de type=boundary (également celles de type=land_area qui ne réprésentent que la partie émergée d'une région, peu utilisée actuellement en France mais très utilisées dans les pays pour lesquelles les frontières administratives incluent le domaine maritime) devraient se fermer, de même que toutes les relations de type=multipolygone (par exemple les landuse=* ou natural=*). Le 15 octobre 2012 14:54, <te...@free.fr> a écrit : > Salut à tous, > > Je comprends qu'il est plus simple et moins encombrant pour la base de > données de mêler le tag barrier=* avec la surface utilisée comme parking, > mais ça reste quelque peu incohérent pour moi, car on mélange les sémantiques > pour un même objet qui, une fois est interprété comme un way, une autre fois > est interprété comme une area (quelle est la valeur implicite de la clé non > fournie "area" ?). C'est comme mélanger un disque et un cercle : l'un est > plein, l'autre n'est que périphérique. > > Comment voulez-vous par la suite attribuer des propriétés à l'un sans que > l'autre ne soit concerné ? Par exemple electrified=yes : est-ce que la > surface du parking est électrifiée ? Si on doit placer un tag généraliste > comme, disons un hypothétique color=*, à qui celui-ci s'appliquerait-il ? > > Sans aller jusqu'aux surfaces, il a déjà été conclu que les railway=* et les > highway=* devaient être sur des ways différents, justement parce que les > confusions peuvent survenir dans les tags. > > Dans un autre ordre d'idées, certains tags ont besoin d'un area=yes pour > exprimer une surface plutôt qu'un way : citons railway=platform, mais aussi > tous les highway=*. Alors, tous les tags qui y sont accolés devront aussi > être interprétés avec area=yes. > > De mon point de vue, dans notre base de données géographique (nous ne nous > limitons pas aux cartes il me semble, même s'il s'agit du principal > objectif), on devrait décrire des objets avec leurs propriétés : > - quelle est la nature de cet objet (route, building, barrière, étendue > d'eau, etc.) avec l'aide éventuelle de plusieurs tags ; > - quelles sont les propriétés de cet objet (en termes d'accès, de propriété, > de forme, d'altitude, etc.) avec autant de tags qu'on veut. > C'est simple et logique. > > Une barrière n'est pas un parking, une barrière n'est pas une sorte de > parking, et un parking n'est pas une sorte de barrière. Un parking peut être > entouré d'une barrière, mais dans ce cas on utilise un tag approprié. Si on > mélange les objets et leurs propriétés, on perd une importante logique > descriptive pour en faire un inventaire à la Prévert, où seule une > interprétation méticuleuse des éléments (triés "à la main") permet de > comprendre ce qu'il en est. > > > Teuxe > > PS. Je n'ai rien compris quant à l'utilisation de relations pour taguer un > parking entouré d'une barrière. _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
