Re: [OSM-talk-fr] parking entouré d'une barrière
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. - Mail original - De: Philippe Verdy verd...@wanadoo.fr À: Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé: Vendredi 12 Octobre 2012 10:59:29 Objet: Re: [OSM-talk-fr]parking entouré d'une barrière Le 11 octobre 2012 14:17, te...@free.fr a écrit : On peut se dire que le way fermé (area) représente une surface qui sert de parking ; à l'opposé, la barrière, même si elle couvre tout le périmètre du parking, n'en reste pas moins un linéaire et n'est pas une surface : n'étant pas de même nature, on ne peut pas associer les deux au même objet. Pas dans un même way, mais la surface fermer peut devenir une relation avec se attributs propres, mais dont les membres sont les ways linéaires ayant leurs propres tags. Ce qui évite de superposer les ways ouverts des clôtures et barrières et un way fermé dessus, voire aussi de dupliquer les noeuds ou de les intercaler le long du même tracé quasi superposé sur une grande longueur (où les traits ne cessent de se recouper aléatoirement alors que les tracés n'ont pas de raison partioculière de s'écarter l'un de l'autre). Donc on transforme dans ce cas un way fermé en multipolygone (c'est le multipolygone qui portera les attributs de la surface, plus le way fermé inclus comme membre du multipolygone) avant de le découper, et on fusionne les chemins linéaires communs : il ne reste alors que le chemin linéaire et non fermé de la cloture, et celui de la barrière, les deux utilisés en membres du multipolygone pour la surface fermée du parking. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] parking entouré d'une barrière
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
Re: [OSM-talk-fr] parking entouré d'une barrière
Salut Philippe, 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. C'est plus clair, merci. Dans ce cas, on n'a pas de way fermé (aucun doute way/area) mais des ways unis par une relation, relation qui porte la propriété formée par l'ensemble. Le type multipolygon sert à ça, j'étais au courant. 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.. Alors il y a contradiction avec http://wiki.openstreetmap.org/wiki/Way : par défaut, un way fermé n'est pas une area, sauf si area=yes est fourni. Certaines clés impliquent area=yes, cette page cite leisure=* et amenity=*, on peut aussi citer landuse=*, building=*, etc. (waterway=* ?) ; par contre il est dommage de trouver autant d'exceptions, surtout qu'elles sont listées nulle part. Et ça fait autant d'exceptions à intégrer dans les programmes qui utilisent ces données. 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=*). Note : devraient : on peut avoir de telles relations non fermées dans la base de données, tant que personne n'aura corrigé l'erreur reportée par OsmOse. On pourra constater sur la France de nombreux landuse blanchis au rendu par des multipolygones cassés. Pour ces larges surfaces, le multipolygon est nécessaire ; pour un petit parking, je ne suis pas convaincu. Bref tout cela ne répond pas à la question du cumul des objets : peut-on logiquement représenter deux objets réels _différents_ dans un même objet OSM (node/way/relation, qui peuvent être considérés comme des groupes de tags) ? Pour ma part, non, car : - on casse une logique sémantique, - et le risque de rencontrer des incompatibilités grandit avec le nombre de combinaisons possibles. (Les bons concepteurs vous parleront de l'adage KISS : http://fr.wikipedia.org/wiki/Principe_KISS) Teuxe ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] parking entouré d'une barrière
Le 15 octobre 2012 17:29, te...@free.fr a écrit : Salut Philippe, 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. C'est plus clair, merci. Dans ce cas, on n'a pas de way fermé (aucun doute way/area) mais des ways unis par une relation, relation qui porte la propriété formée par l'ensemble. Le type multipolygon sert à ça, j'étais au courant. 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.. Alors il y a contradiction avec http://wiki.openstreetmap.org/wiki/Way : par défaut, un way fermé n'est pas une area, sauf si area=yes est fourni. Non, par défaut un way fermé est une surface, sauf pour les highway=*; waterway=* (sauf riverbank), et railway=* qui par défaut sont filaires (et qui justifient alors qu'on mette area=yes dans les très cas rares où il faut changer l'interprétation par défaut de ces éléments comme du filaire) Par exemple tous les way fermés de landuse=*, de riverbank, de natural=* (y compris les coastlines), de boundary, land_area, buildings... sont des surfaces (même si une bordure peut leur être dessinée aussi) et il n'y a même pas besoin de préciser area=yes (et encore moins area=no que je n'ai encore jamais vu justifié dans aucun élément). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] parking entouré d'une barrière
2012/10/15 Philippe Verdy verd...@wanadoo.fr: Non, par défaut un way fermé est une surface, sauf pour les highway=*; waterway=* (sauf riverbank), et railway=* qui par défaut sont filaires (et qui justifient alors qu'on mette area=yes dans les très cas rares où il faut changer l'interprétation par défaut de ces éléments comme du filaire) Euh... un waterway fermé avec area=yes ? Il faudrait me donner un exemple concret, même très rare. Pour railway, pareil. Il y avait un cas, celui du railway/highway=platform mais je me suis beaucoup battu pour faire admettre sur le wiki que ça n'était justifié que pour satisfaire Mapnik. Sinon, c'est toujours une surface. (dans le cas d'une plateforme en boucle, elle dessert plusieurs lignes et nécessite plusieurs sections). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] parking entouré d'une barrière
Le 15 octobre 2012 21:53, Pieren pier...@gmail.com a écrit : 2012/10/15 Philippe Verdy verd...@wanadoo.fr: Non, par défaut un way fermé est une surface, sauf pour les highway=*; waterway=* (sauf riverbank), et railway=* qui par défaut sont filaires (et qui justifient alors qu'on mette area=yes dans les très cas rares où il faut changer l'interprétation par défaut de ces éléments comme du filaire) Euh... un waterway fermé avec area=yes ? Il faudrait me donner un exemple concret, même très rare. Ce que je veux dire c'est que des waterways fermés ne sont pas rares (on en trouve autour des champs) mais ca n 'est pas pour ça qu'il faut les prendre pour des surfaces. L'exception ce sont les waterway=riverbank, qui devraient être fermés (ou dans une relation fermée) et qui sont remplis par défaut (pas besoin de area=yes pour eux, et aucun cas où on aura besin de area=no). Mais justement avec les riverbanks on n'a plus besoin d'autre chose pour les waterways donnant une surface. sinon c'est du water=lake ou équivalent pas du waterway. Pour railway, pareil. Il y avait un cas, celui du railway/highway=platform un rail sur une surface... h... même si tu parles des plateformes tournantes, ce n'est qu'une intersection de rails entre les directions qui peuvent être prises, la surface plateforme elle-même n'est pas ferrée, il y a un rail linaire posé dessus.. Donc pour moi le dernier cas pratique qui reste pour justifier un area=yes c'est la place piétonne (qu'on ne devrait pas marquer comme highway=footway mais comme landuse=*), et ne ne vois pas dans quel cas on a besoin de area=no. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] parking entouré d'une barrière
Le 11 octobre 2012 14:17, te...@free.fr a écrit : On peut se dire que le way fermé (area) représente une surface qui sert de parking ; à l'opposé, la barrière, même si elle couvre tout le périmètre du parking, n'en reste pas moins un linéaire et n'est pas une surface : n'étant pas de même nature, on ne peut pas associer les deux au même objet. Pas dans un même way, mais la surface fermer peut devenir une relation avec se attributs propres, mais dont les membres sont les ways linéaires ayant leurs propres tags. Ce qui évite de superposer les ways ouverts des clôtures et barrières et un way fermé dessus, voire aussi de dupliquer les noeuds ou de les intercaler le long du même tracé quasi superposé sur une grande longueur (où les traits ne cessent de se recouper aléatoirement alors que les tracés n'ont pas de raison partioculière de s'écarter l'un de l'autre). Donc on transforme dans ce cas un way fermé en multipolygone (c'est le multipolygone qui portera les attributs de la surface, plus le way fermé inclus comme membre du multipolygone) avant de le découper, et on fusionne les chemins linéaires communs : il ne reste alors que le chemin linéaire et non fermé de la cloture, et celui de la barrière, les deux utilisés en membres du multipolygone pour la surface fermée du parking. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] parking entouré d'une barrière
Le 11 octobre 2012 14:18, Jean-Francois Nifenecker jean-francois.nifenec...@laposte.net a écrit : Une seule surface suffit. Celle-ci comporte alors les tags amenity=parking et barrier=* Au point d'entrée/sortie, un tag barrier=* Solution possible aussi si la barrière d'entrée n'est pas trop longue, mais on peut vouloir en détailler la longueur sur un segment. D'autre part sur les surfaces fermées on a souvent une partie fermée par une barrière et le reste fermé par un mur ou par un bâtiment : le pourtour n'est donc pas un seul trait unique continu et fermé. C'est en fait le même problème avec les plages (surface fermée) limitée sur un bord par la ligne de côte (linéaire). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] parking entouré d'une barrière
Le 11/10/2012 14:03, Francescu GAROBY a écrit : Bonjour, En tagguant des parkings, délimités par des grillages et dont l'entrée et la sortie sont régies par des barrières , m'est venue la question suivante : vous parait-il correct de rajouter un tag barrier=fence (et barrier=lift_gate aux points d'entrée/sortie), sur le way délimitant le parking, et passant à l'emplacement du grillage, plutôt que de tracer une way pour le grillage+ une surface (donc une way) pour délimiter la surface du parking ? Une seule surface suffit. Celle-ci comporte alors les tags amenity=parking et barrier=* Au point d'entrée/sortie, un tag barrier=* -- Jean-Francois Nifenecker, Bordeaux ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] parking entouré d'une barrière
2 réponses en 2 minutes : merci pour la réactivité ! Manque de chance, elles sont contradictoires ! :-D Francescu Le 11 octobre 2012 14:18, Jean-Francois Nifenecker jean-francois.nifenec...@laposte.net a écrit : Le 11/10/2012 14:03, Francescu GAROBY a écrit : Bonjour, En tagguant des parkings, délimités par des grillages et dont l'entrée et la sortie sont régies par des barrières , m'est venue la question suivante : vous parait-il correct de rajouter un tag barrier=fence (et barrier=lift_gate aux points d'entrée/sortie), sur le way délimitant le parking, et passant à l'emplacement du grillage, plutôt que de tracer une way pour le grillage+ une surface (donc une way) pour délimiter la surface du parking ? Une seule surface suffit. Celle-ci comporte alors les tags amenity=parking et barrier=* Au point d'entrée/sortie, un tag barrier=* -- Jean-Francois Nifenecker, Bordeaux __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] parking entouré d'une barrière
Les contradictions permettent de lever des loups et de réfléchir ensemble à la meilleure technique à adopter. Merci d'avoir ouvert le sujet ;) Teuxe - Mail original - De: Francescu GAROBY windu...@gmail.com À: Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé: Jeudi 11 Octobre 2012 14:20:49 Objet: Re: [OSM-talk-fr]parking entouré d'une barrière 2 réponses en 2 minutes : merci pour la réactivité ! Manque de chance, elles sont contradictoires ! :-D Francescu Le 11 octobre 2012 14:18, Jean-Francois Nifenecker jean-francois.nifenec...@laposte.net a écrit : Le 11/10/2012 14:03, Francescu GAROBY a écrit : Bonjour, En tagguant des parkings, délimités par des grillages et dont l'entrée et la sortie sont régies par des barrières , m'est venue la question suivante : vous parait-il correct de rajouter un tag barrier=fence (et barrier=lift_gate aux points d'entrée/sortie), sur le way délimitant le parking, et passant à l'emplacement du grillage, plutôt que de tracer une way pour le grillage+ une surface (donc une way) pour délimiter la surface du parking ? Une seule surface suffit. Celle-ci comporte alors les tags amenity=parking et barrier=* Au point d'entrée/sortie, un tag barrier=* -- Jean-Francois Nifenecker, Bordeaux __ _ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap. org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] parking entouré d'une barrière
2012/10/11 Francescu GAROBY windu...@gmail.com: Manque de chance, elles sont contradictoires ! :-D Elles sont différentes. Mais les deux solutions sont correctes. Sauf que tracer deux ways qui se superposent exactement n'est pas pratique. Il y a un gros risque que les contributeurs peu habitués n'en voit qu'un seul. A toi de peser les pour et les contre. Moi, je suis partisan du moindre effort donc un seul way ;-) Y en a qui vont sûrement te proposer une 3e solution : utiliser des relations ! Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] parking entouré d'une barrière
Deux ways superposés: bof bof bof Deux ways séparés: on rentre dans le micro-mapping, pourquoi pas, mais est-ce bien utile ? Un seul way avec amenity=parking + barrier=fence me semble suffisant dans bien des cas + les nodes pour les entrées bien sûr... sinon les algo de routage penseront que le parking est inaccessible. Le relation... je trouve que ça relève du TOC (Trouble Obsessionnel Cartographique) pour un tel cas. Le 11 octobre 2012 14:50, Pieren pier...@gmail.com a écrit : 2012/10/11 Francescu GAROBY windu...@gmail.com: Manque de chance, elles sont contradictoires ! :-D Elles sont différentes. Mais les deux solutions sont correctes. Sauf que tracer deux ways qui se superposent exactement n'est pas pratique. Il y a un gros risque que les contributeurs peu habitués n'en voit qu'un seul. A toi de peser les pour et les contre. Moi, je suis partisan du moindre effort donc un seul way ;-) Y en a qui vont sûrement te proposer une 3e solution : utiliser des relations ! Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] parking entouré d'une barrière
Je suis aussi partisan pour un seul way avec les tags : http://www.openstreetmap.org/browse/way/134138153 Le tag parking fait référence à la surface et le tag barrier pour le linéaire donc pas de soucis. Le 11 octobre 2012 16:40, Christian Quest cqu...@openstreetmap.fr a écrit : Deux ways superposés: bof bof bof Deux ways séparés: on rentre dans le micro-mapping, pourquoi pas, mais est-ce bien utile ? Un seul way avec amenity=parking + barrier=fence me semble suffisant dans bien des cas + les nodes pour les entrées bien sûr... sinon les algo de routage penseront que le parking est inaccessible. Le relation... je trouve que ça relève du TOC (Trouble Obsessionnel Cartographique) pour un tel cas. Le 11 octobre 2012 14:50, Pieren pier...@gmail.com a écrit : 2012/10/11 Francescu GAROBY windu...@gmail.com: Manque de chance, elles sont contradictoires ! :-D Elles sont différentes. Mais les deux solutions sont correctes. Sauf que tracer deux ways qui se superposent exactement n'est pas pratique. Il y a un gros risque que les contributeurs peu habitués n'en voit qu'un seul. A toi de peser les pour et les contre. Moi, je suis partisan du moindre effort donc un seul way ;-) Y en a qui vont sûrement te proposer une 3e solution : utiliser des relations ! Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] parking entouré d'une barrière
J'ai finalement retenu cette solution. Merci à tous Francescu Le 11 octobre 2012 17:47, Etienne Trimaille etienne.trimai...@gmail.com a écrit : Je suis aussi partisan pour un seul way avec les tags : http://www.openstreetmap.org/browse/way/134138153 Le tag parking fait référence à la surface et le tag barrier pour le linéaire donc pas de soucis. Le 11 octobre 2012 16:40, Christian Quest cqu...@openstreetmap.fr a écrit : Deux ways superposés: bof bof bof Deux ways séparés: on rentre dans le micro-mapping, pourquoi pas, mais est-ce bien utile ? Un seul way avec amenity=parking + barrier=fence me semble suffisant dans bien des cas + les nodes pour les entrées bien sûr... sinon les algo de routage penseront que le parking est inaccessible. Le relation... je trouve que ça relève du TOC (Trouble Obsessionnel Cartographique) pour un tel cas. Le 11 octobre 2012 14:50, Pieren pier...@gmail.com a écrit : 2012/10/11 Francescu GAROBY windu...@gmail.com: Manque de chance, elles sont contradictoires ! :-D Elles sont différentes. Mais les deux solutions sont correctes. Sauf que tracer deux ways qui se superposent exactement n'est pas pratique. Il y a un gros risque que les contributeurs peu habitués n'en voit qu'un seul. A toi de peser les pour et les contre. Moi, je suis partisan du moindre effort donc un seul way ;-) Y en a qui vont sûrement te proposer une 3e solution : utiliser des relations ! Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
