Re: [OSM-talk-fr] Héritage et relation
J'ai discuté avec lui, il en ressort que ces relations ont été créées pour coller aux besoins d'un outil osm2mp [2]. Idem que les autres : oui il y a doublon. Mais je ne suis pas sûr que le problème soit juste osm2mp, mais d'une cohérence wiki et de savoir ce que l'on veut représenter Ces relations ont pour lui 2 intérêts : - délimiter une zone d'habitation pour par exemple impacter la vitesse des ways (en ville, on roule à 50 km/h, etc) A mon avis, ça part mal déjà, les deux ne sont pas nécessairement confondues. Je lui ai répondu que dans le premier cas, le besoin correspondait à une notion de landuse=residential Je ne suis pas d'accord, landuse=residential, si j'ai bien compris le wiki et ce qu'il veut, a une portée plus réduite que ce qu'il semble vouloir représenter. (un cimetière, un parc, des magasins ne sont pas dans un landuse=residential, alors que lui semble vouloir une zone qui englobe tout ça) à mon avis, son choix place=city sur la surface est la bonne solution, c'est juste qu'il n'y a pas de raison d'en créer 2 je pense. , qui plus est mal représentée par la notion de limite administrative. Pour le second point, dans le cas de la France, les relations en admin_level=8 sont la maille de base de l'adressage +1 avec toi. Sauf que le bonhomme souhaite peut-être un truc qui marche world wide, et sa démarche peut alors se comprendre, sans quoi avant d'avoir un adressage qui marche il faudra 256 règles spécifiques. Bref, je trouve que cette idée de place=* sur une surface est une très bonne idée pour rendre quelque chose de cohérent mondialement, (quitte à ajouter d'autres spécificités de pays) mais à condition que l'on soit d'accord sur ce que ça veut dire. Et le wiki ne dit nulle part qu'un place=* sur une surface doit être compris comme une surface d'adressage, mais plutôt comme un lieu habité qui porte un nom. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Héritage et relation
De : sly (sylvain letuffe) Je lui ai répondu que dans le premier cas, le besoin correspondait à une notion de landuse=residential Je ne suis pas d'accord, landuse=residential, si j'ai bien compris le wiki et ce qu'il veut, a une portée plus réduite que ce qu'il semble vouloir représenter. (un cimetière, un parc, des magasins ne sont pas dans un landuse=residential, alors que lui semble vouloir une zone qui englobe tout ça) Oui, j'ai fait un peu court mais c'est bien la notion que tu décris. Mon residential se rapproche plus de celui d'une zone bâtie un peu large, plus proche de Corine que d'OSM en terme de détail des usages. à mon avis, son choix place=city sur la surface est la bonne solution, c'est juste qu'il n'y a pas de raison d'en créer 2 je pense. , qui plus est mal représentée par la notion de limite administrative. Pour le second point, dans le cas de la France, les relations en admin_level=8 sont la maille de base de l'adressage +1 avec toi. Sauf que le bonhomme souhaite peut-être un truc qui marche world wide, et sa démarche peut alors se comprendre, sans quoi avant d'avoir un adressage qui marche il faudra 256 règles spécifiques. Tu mets le doigt sur _la_ difficulté. Un moteur d'adressage multi-pays, c'est potentiellement autant de cas à gérer que de pays couverts. Plaquer un même schéma partout ne rime pas à grand chose. Et faire rentrer dans un même moule les limites admin niveau 8 de France, les limites postales US, les zones (je ne sais même pas comment les nommer, tiens) de découpage UK, c'est un joli casse-tête. En créant ses multipolygon place=*, il gère à la marge son problème, mais pas forcément par le bon bout. Bref, je trouve que cette idée de place=* sur une surface est une très bonne idée pour rendre quelque chose de cohérent mondialement, (quitte à ajouter d'autres spécificités de pays) mais à condition que l'on soit d'accord sur ce que ça veut dire. Et le wiki ne dit nulle part qu'un place=* sur une surface doit être compris comme une surface d'adressage, mais plutôt comme un lieu habité qui porte un nom. Je n'ai pas non plus de souci avec sa modélisation, c'est juste que les arguments qu'il m'a donné quant à l'usage montrent qu'il n'a pas cherché à comprendre le problème. Raison pour laquelle je ne supprimerai pas ces objets, au passage : à lui de les enlever, à mon sens, si ça peut témoigner d'un changement dans son approche des données. vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Héritage et relation
Tu mets le doigt sur _la_ difficulté. Un moteur d'adressage multi-pays, c'est potentiellement autant de cas à gérer que de pays couverts. Plaquer un même schéma partout ne rime pas à grand chose. Là, je suis un poil plus optimiste que toi ;-) Certes, espérer tout gérer n'est peut-être qu'une utopie, mais si on arrive à gérer 98% des pays, la donnée n'en sera que plus facilement utilisable ! J'imagine un tag : adressing_zone=yes qui aurait pour sens de dire qu'un point situé au n°2 de la rue X aura comme adresse complète : 2 rue de X $addr:postalcode $name $addr:autre_bidule $(surface admin_level=2 dans lequel le point se trouve) Permettrait sans doute de couvrir un paquet de cas, et son implémentation en France sera relativement simple puisqu'il suffirait de rajouter adressing_zone=yes à (presque) toutes les communes puisse que en france, les deux sont confondues dans presque tous les cas (cf l'éternel problème du code postal des communes tordues qu'il faudra alors rediviser avec une adressing zone séparée) Raison pour laquelle je ne supprimerai pas ces objets, au passage : à lui de les enlever Pas sûr qu'il le fasse, à un moment il faut sortir le bâton et dire tu le fais ou je le fais ? -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Héritage et relation
De : sly (sylvain letuffe) Tu mets le doigt sur _la_ difficulté. Un moteur d'adressage multi-pays, c'est potentiellement autant de cas à gérer que de pays couverts. Plaquer un même schéma partout ne rime pas à grand chose. Là, je suis un poil plus optimiste que toi ;-) Certes, espérer tout gérer n'est peut-être qu'une utopie, mais si on arrive à gérer 98% des pays, la donnée n'en sera que plus facilement utilisable ! J'imagine un tag : adressing_zone=yes qui aurait pour sens de dire qu'un point situé au n°2 de la rue X aura comme adresse complète : 2 rue de X $addr:postalcode $name $addr:autre_bidule $(surface admin_level=2 dans lequel le point se trouve) La difficulté, c'est, en grande partie, d'aller piocher pays par pays les nuances de modélisation OSM et surtout les pratiques locales d'adressage. En gros, savoir répondre à la question : dans le pays xxx, quand je suis à l'endroit yyy, quel est le texte à écrire sur une enveloppe pour qu'un courrier me parvienne ? Si on sait proposer une thématique dédiée, au moyen par exemple du tag que tu proposes, alors oui, ça simplifie grandement. Il restera forcément quelques contorsions pour tout prévoir (comme par exemple ce schéma [1]) mais on aura avancé néanmoins. À mijoter :-) vincent [1] : http://lists.openstreetmap.org/pipermail/talk-fr/2012-March/042152.html Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Héritage et relation
Le 6 juin 2012 16:04, Vincent de Chateau-Thierry v...@laposte.net a écrit : Tu mets le doigt sur _la_ difficulté. Un moteur d'adressage multi-pays, c'est potentiellement autant de cas à gérer que de pays couverts. Plaquer un même schéma partout ne rime pas à grand chose. Et faire rentrer dans un même moule les limites admin niveau 8 de France, les limites postales US, les zones (je ne sais même pas comment les nommer, tiens) de découpage UK, c'est un joli casse-tête. En créant ses multipolygon place=*, il gère à la marge son problème, mais pas forcément par le bon bout. Mouais... mais franchement qu'est-ce qu'il y a comme tag spécifique dans ces doublons que n'apporte pas les relations originales ? l n'y a aucun moyen dans ce qu'il a mis de faire la différence, même concernant l'usage qu'il veut en faire. La question ne se pose donc pas, ces doublons sont inutiles même pour son usage et la façon doit il le conçoit puisqu'il se retrouvera forcément aussi à devoir analyser ces doublons et à en éliminer un sans aucun critère discriminant. On peur les enlever sans problème même s'il ne fait rien. A mon avis c'est juste qu'il n'a pas vérifié que les relations en question n'existaient pas déjà et qu'il les a importées en masse. Il a même introduit une difficulté à sa propre analyse. Bref on garde les relations qui ont l'ID le plus petit et qui correspond à l'usage le plus ancien pour minimiser l'impact, on élimine ces doublons sans problème. Surtout si en plus il ne fournit aucune justification pour leur existence, ni aucun tag spécifique ni aucun membre spécifique qui n'est pas **déjà** dans les relations d'origine. Ces doublons compliquent les choses pour strictement aucun bénéfice à quelque niveau d'analyse que ce soit. A mon avis il n'était même pas conscient de créer ces doublons et n'a pas filtré ses imports pour vérifier ce qui était déjà dans la base, et n'a pas cherché du tout. La seule chose qu'il doit changer c'est sa table locale de correspondance des identifiants dans sa propre base. Strictement aucun tag n'est à changer puisque les relations d'origine ont déjà tous les tags qu'il a dupliqués (partiellement, mais fidèlement sans même changer leurs valeurs) dans les nouvelles relations qu'il a ajoutées. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Héritage et relation
2012/5/24 Balaitous balait...@mailoo.org: Il n’empêche que la représentation des routes est très orienté voie de circulation. Un candidat pour le FR:Fortunes ? Pieren ;-) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Héritage et relation
2012/5/25 Balaitous balait...@mailoo.org: Côté wiki il ne me parait pas à jour. Par quel processus une relation passe du stade de proposé à officiel ? Sur la base des statistiques d'utilisation ? Quand j'aurais plus de temps, j'irais faire un tour de ce côté là aussi. On manque de statistiques sur les relations. Sur taginfo, on peut en voir celles des tags (comme http://taginfo.openstreetmap.org/keys/type#values) mais impossible de voir celles sur les rôles (admin_centre par exemple). Il n'y a pas de processus clair pour passer à un stade officiel, pas plus que pour les tags. Le processus du vote est bien documenté mais est fortement contesté. Parfois la proposition se transforme en officiel suite à une gueulante sur une liste ou un forum (ça a été le cas pour les relations). Certaines relations posent encore problème comme le type=boundary que les allemands ont tenté de remplacer par type=multipolygon pour leur similitude géométrique alors que de nombreux pays ont choisi de conserver le type boundary pour des raisons de sémantique (du coup, les allemands discutent régulièrement sur un retour en arrière). Pour ma part hier j'ai ajouté 2 ou 3 routes, dès qu'elles sont coupées en 2 je les encapsules dans une street, et je ne met plus le nom dans tous les tronçons. Aux éditeurs de se débrouiller comme cela m'a été dit dans certaines réponses. Il faut faire attention à ne pas tomber dans l'excès. Certaines personnes apprécient tellement la modélisation par relation qu'ils veulent en mettre partout alors que de nombreux retours sur les listes, forums, exposés montrent qu'un large public bloque sur cette notion. De plus, ce type de modélisation pose aussi de nouveaux problèmes (comme les héritages multiples). De telle sorte qu'il est envisagé dans le futur de remplacer la relation multipolygon par un nouveau type d'élément dans le futur (voir les discussions sur l'API 0.7). La priorité absolue reste une modélisation simple pour que cela reste abordable et simple, pour les logiciels mais surtout pour les contributeurs d'un jour. Effectivement, quand les gens aurons fait l'expérience de modifier 10 ou 20 tag pour ajouter UNE ref sur UNE rue, il trouverons plus d’intérêt aux relations. Par exemple, qu'est ce que tu mets dans ta relation street ? highway et cycleway semblent évidents. Et quid des adresses utilisant associatedStreet ? et les boites postales ou les bancs publics que certains considèrent comme faisant partie de la rue ? où se trouve la limite de ce que tu mets dans cette relation ? et les rues qui sont à sens unique, c'est oneway=yes sur la relation ? et celles dont seul une section est à sens unique ? on remet le oneway=yes sur le way ? etc Je pense que je vais en laisser trainer quelques une dans la base (avec un tag comment expliquant le pourquoi) Les explications de ce type sont de préférence à mettre sur le wiki. Bon mapping quand même, Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Héritage et relation
Le 5 juin 2012 13:04, Pieren pier...@gmail.com a écrit : Certaines relations posent encore problème comme le type=boundary que les allemands ont tenté de remplacer par type=multipolygon pour leur similitude géométrique alors que de nombreux pays ont choisi de conserver le type boundary pour des raisons de sémantique (du coup, les allemands discutent régulièrement sur un retour en arrière). Là dessus ils vont se casser le nez avec les frontières floues. La sémantique des frontières peut indiquer une zone tampon (buffer en terminologie OpenGIS) dans laquelle on ne sait pas trop où passe la frontière. Le rendu des frontières par des surfaces lisses et parfaitement jointives et non superposées pose alors problème. Certains voudront aussi que les territoires revendiqués par deux pays limitrophes soient inclus *dans* les frontières des deux pays, pour contenter tout le monde. Ou voudront ne prendre en compte que le seul statut administratif du pays qui a le seul le contrôle effectif du territoire (sécurité publique, secours d'urgence, et collecte des impôts et taxes inclus), ou selon le droit de vote ou de nationalité ou de résidence accordé aux résidents dans ces zones (exemple à Chypre). (à charge ensuite pour le moteur de rendu d'afficher cette zone d'une autre couleur, ou par des hachures bicolores, ou par une transition lissée de couleurs dans cette zone tampon, solution possible dans les zones inhabitées comme des déserts). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Héritage et relation
Bonsoir, Le 05/06/2012 13:04, Pieren a écrit : Certaines relations posent encore problème comme le type=boundary que les allemands ont tenté de remplacer par type=multipolygon pour leur similitude géométrique alors que de nombreux pays ont choisi de conserver le type boundary pour des raisons de sémantique (du coup, les allemands discutent régulièrement sur un retour en arrière). Pour info, on trouve en IDF une petite trentaine de relations type=multipolygon qui reprennent way pour way les membres de relations type=boundary+admin_level=8. C'est par exemple le cas de Paris : - boundary : http://www.openstreetmap.org/browse/relation/7444 - multipolygon : http://www.openstreetmap.org/browse/relation/2117063 ou encore Versailles : - boundary : http://www.openstreetmap.org/browse/relation/30295 - multipolygon : http://www.openstreetmap.org/browse/relation/2117101 Toutes datent du 05/04 dernier, initiées par un unique contributeur [1]. J'ai discuté avec lui, il en ressort que ces relations ont été créées pour coller aux besoins d'un outil osm2mp [2]. Ces relations ont pour lui 2 intérêts : - délimiter une zone d'habitation pour par exemple impacter la vitesse des ways (en ville, on roule à 50 km/h, etc) - permettre l'adressage. Je lui ai répondu que dans le premier cas, le besoin correspondait à une notion de landuse=residential, qui plus est mal représentée par la notion de limite administrative. Pour le second point, dans le cas de la France, les relations en admin_level=8 sont la maille de base de l'adressage, je lui ai cité l'exemple de l'usage qu'en fait Nominatim. Je lui ai demandé de supprimer ce que je considère comme des doublons sans valeur ajoutée. Pas vraiment d'effet jusque là (et je doute fort qu'il se passe quoi que ce soit). vincent [1] : http://www.openstreetmap.org/user/Dinamik [2] : http://wiki.openstreetmap.org/wiki/Osm2mp ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Héritage et relation
Le 5 juin 2012 21:34, Vincent de Chateau-Thierry v...@laposte.net a écrit : Le 05/06/2012 13:04, Pieren a écrit : Certaines relations posent encore problème comme le type=boundary que les allemands ont tenté de remplacer par type=multipolygon pour leur similitude géométrique alors que de nombreux pays ont choisi de conserver le type boundary pour des raisons de sémantique (du coup, les allemands discutent régulièrement sur un retour en arrière). Pour info, on trouve en IDF une petite trentaine de relations type=multipolygon qui reprennent way pour way les membres de relations type=boundary+admin_level=8. C'est par exemple le cas de Paris : - boundary : http://www.openstreetmap.org/browse/relation/7444 - multipolygon : http://www.openstreetmap.org/browse/relation/2117063 La seconde relation plus récente est clairement un doublon inutile sans aucun tag discriminant destiné à compléter la couverture d'une collection de zones ou a préciser un rôle alternatif incompatible avec un tag existant dans la première relation. Elle ne facilite même pas l'édition d'une zone complexe par des limites simplifiées. Les ways sont totalement identiques, ils sont juste ordonnées dans l'autre sens (le sens horaire, pas celui recommandé qui facilite/accélère le travail lors de toute conversion du schéma OSM en schéma OpenGIS) ou encore Versailles : - boundary : http://www.openstreetmap.org/browse/relation/30295 - multipolygon : http://www.openstreetmap.org/browse/relation/2117101 Même remarque. La seconde relation plus récente est un doublon qui n'ajoute rien. Toutes datent du 05/04 dernier, initiées par un unique contributeur [1]. J'ai discuté avec lui, il en ressort que ces relations ont été créées pour coller aux besoins d'un outil osm2mp [2]. Ces relations ont pour lui 2 intérêts : - délimiter une zone d'habitation pour par exemple impacter la vitesse des ways (en ville, on roule à 50 km/h, etc) Et rien du tout dans les doublons qu'il a créé qui soit différent dans les relations originales plus complètes. La surface délimitée est exactement la même quel que soit l'usage qu'il veut en faire. - permettre l'adressage. Idem. Doublons non nécessaires. Il n'a montré aucun tag spécifique utile pour ce qu'il veut faire. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Héritage et relation
2012/6/5 Vincent de Chateau-Thierry v...@laposte.net: Je lui ai demandé de supprimer ce que je considère comme des doublons sans valeur ajoutée. Pas vraiment d'effet jusque là (et je doute fort qu'il se passe quoi que ce soit). Bah, si c'est clairement des doublons et qu'il ne réagit pas : supprime les toi-même. Ce logiciel Osm2mp serait bien le premier dont j'entends parler qui ne serait pas capable de traiter les relations boundary de la même façon que les multipolygon (et inversement). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Héritage et relation
Le 25 mai 2012 16:53, sly (sylvain letuffe) li...@letuffe.org a écrit : Côté wiki il ne me parait pas à jour. C'est souvent le cas, sur certaines pages soit il est en avance dans le sens où il propose de tagguer tel truc de tel manière alors que ça n'est pas encore utilisé dans la base. A l'inverse des pratiques existent qui ne sont pas ou mal documentées, et là, il est préférable de venir compléter le wiki (tout le monde le peux), et indiquer par des pages que voilà ce qui se fait à tel endroit, pour tel et tel raison avec tel et tel avantage sur telle autre méthode qui lui ressemble et en parler sur la liste anglaise tagging pour présenter son existence aux autres, en discuter et l'améliorer et espérer que son usage va se démocratiser pour qu'elle finisse par obtenir le droit de figurer dans la liste des Established Relations : http://wiki.openstreetmap.org/wiki/Types_of_relation Le wiki mentionne une relation de type boundary=civil sans aucune documentation (la page liée à cette valeur n'est qu'un stub affichant le titre et rien d'autre. Certains ont tenté d'obetnir des explications de celui qui a ajouté ça dans la page wiki, et dans les sous-pages sur cette valeur, et c'est resté lettre morte. Je ne suis pas loin de demander la suppression de ces pages puisque leur auteur n'a pas répondu depuis longtemps. On a vu récemment disparaître du wiki boundary=electoral puisque cela a été réuni dans boundary=political (alors qu'il aurait plutôt fallu faire l'inverse, la notion de frontière politique n'ayant aucun sens au niveau électoral, sauf au niveau 2 des pays, tels que discutés et reconnus à l'ONU, et dans les traités internationaux, et la description du tag et l'usage qui en est fait est bien que ce sont des frontières électorales !). Pourtant il reste encore des frontières contenant boundary=electoral... On aurait mieux fait de dire que les deux valeurs étaient synonymes, décrire les deux dans la même page (par une redirection) en recommandant une migration vers une autre valeur (qui aurait du être electoral) afin d'assurer une bonne compréhension par tout le monde et une transition vers la valeur recommandée. Mais voilà : le retrait du wiki n'a pas été discuté non plus, pas plus que les ajouts n'avaient été correctement documentés par leur initiateur qui n'a pas pris l'effort minimum d'expliquer aux autres ce qu'il entendait avec une valeur différerente ! On se demande s'il existe réellement une communauté OSM au sens large (mondial) si chacun fait selon ses préférences, et personne ne réponds aux demandes d'explications, ni n'expose les limites raisonnables d'utilisation de certains codes (par exemple une limite territoriale où la valeur a un sens démontré, l'usage pour le reste du monde restant à étudier). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Héritage et relation
On jeudi 24 mai 2012, Balaitous wrote: Bonjour, Bonjour, Pour mon premier message, je voudrais poser une question que je me pose depuis un moment. Est-ce que les tags d'une relation sont héréditaires ? En d'autre terme lorsque je mets un tag dans une relation celui-ci est-il transmis aux enfants de la relation (lorsque ceux-ci ne redéfinissent pas le tag en question) ? Il n'y a pas une mais plusieurs réponses à ta question, principalement car l'éco-système OSM (la base, les utilisations, les éditeurs, le wiki) sont très souples et disons, un peu anarchique parfois et pas toujours cohérent et pas imposé par quoi que ce soit. (Je ne commenterais pas les défauts et avantages) Donc la réponse à ta question va dépendre de quelle partie de cet éco-système elle concerne. Dans la base OSM (celle qu'on édite avec JOSM/potlatch/...) il n'y a pas de notion d'hérédité, une relation a ses tags, un way les siens, un noeud les sien, et rien n'est recopié nulle part de manière automatique. Exemple, si tu places le tag landuse=forest sur une relation multipolygon, ce tag ne se retrouvera pas sur les ways membres de la relation. L'hérédité, si elle existe quelque part, sera dans la manière d'utiliser les données OSM, c'est à dire les logiciels de rendu, l'impression d'une carte, ... Et ça, c'est laissé complètement libre à celui qui veut se servir des données OSM, et donc au logiciel qu'il va utiliser pour s'occuper de la conversion du format .osm vers un format exploitable pour son besoin. Le logiciel osm2pgsql par exemple qui est célèbre car étant utilisé par la majorité des rendus sous forme de carte des données OSM (dont le rendu proposé en page d'accueil du site www.osm.org) dispose de quelque traitement de l'hérédité au niveau de certaines relations seulement (type=route, type=boundary et type=multipolygon) et pour certains tags seulement défini dans par liste blanche ou noire Il n'y a rien de systématique donc, et tout est fait au cas par cas, selon le besoin et le logiciel utilisé. Et enfin, il y a le wiki, qui va décrire l'utilisation de relation, et pour lesquelles il va (ou non) explicitement indiquer que toute utilisation de cette relation devrait considérer l'hérédité. Mais le wiki n'est qu'une description, la décision finale revenant à l'utilisation qui sera faite des dites relations et qui dépendra, certes de la description faite du wiki, mais aussi de la manière réél et majoritaire dont les contributeurs OSM auront rentré dans la base de donnée Exemple, si 1% seulement des routes nationales de france disposent d'une relation avec nom+ref alors que tout le reste c'est de la réplication des tags sur chacun des composants, alors je suppose que quelqu'un souhaitant faire un rendu des routes nationales de france va simplement laisser tomber l'hérédité car ça ne gérera que trop peu de cas. A l'inverse, si ce chiffre passe à 99% ça va commencer à intéresser du monde, et les choses évoluerons. Tout ça est donc un salmigondi s'entre-influençant fait de la manière d'éditer, du nombre d'utilisation qui en est faite, de documentation wiki qui en parle et du support plus au moins aisé/influencé par les éditeurs OSM. Une sorte de progression anarchique par essai/erreur qui entraîne sans doute de la perte de temps, de création d'algorithme plus compliqué mais aussi de plus de flexibilité. Mon pronostic c'est qu'on devrait ré-avancer vers la normalisation (factorisation des tags par les relations) et la multiplication des relations dans l'avenir car le découpage des routes, des cours d'eau, des frontières de manière quasi-arbitraire (restriction de vitesse, pont, tunnel, chevauchement) augmenterons et avec eux la difficulté d'éditer, donc un besoin grandissant d'outil pour les gérer. Plus généralement, depuis quelques temps que je m'intéresse à OSM, je trouve un manque de séparation des aspects géométriques (point, ligne, ...) et sémantiques. Cela risque de poser d'importants problèmes de cohérence pour le nommage des routes, de plus en plus fragmentées. Beaucoup en sont conscient, et des solutions arrivent petit à petit qui tente de garder la compatibilité (les relations sont l'exemple le plus typique) sinon les réflexions depuis quelques années pour gérer d'une manière unique et cohérente les surface : http://wiki.openstreetmap.org/wiki/The_Future_of_Areas Mais il est devenu presque impensable de dire : bon, on casse tout et on repart de zéro avec les géométries d'un coté, la sémantique de l'autre. En gros, généraliser les relations, faire du multipolygon un élément géométrique à part entière. J'en suis partisan, d'autres voudraient l'abandonner et le substituer par un nouvel objet area au même niveau que way, node et relation qui reprendrait grosso modo l'idée du multipolygon mais imposerait des contraintes d'intégrité -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org
Re: [OSM-talk-fr] Héritage et relation
Merci pour ces réponses qui me permettent d'y voir un peu plus clair. Le vendredi 25 mai 2012 à 14:39 +0200, sly (sylvain letuffe) a écrit : On jeudi 24 mai 2012, Balaitous wrote: Bonjour, Bonjour, Pour mon premier message, je voudrais poser une question que je me pose depuis un moment. Est-ce que les tags d'une relation sont héréditaires ? En d'autre terme lorsque je mets un tag dans une relation celui-ci est-il transmis aux enfants de la relation (lorsque ceux-ci ne redéfinissent pas le tag en question) ? Il n'y a pas une mais plusieurs réponses à ta question, principalement car l'éco-système OSM (la base, les utilisations, les éditeurs, le wiki) sont très souples et disons, un peu anarchique parfois et pas toujours cohérent et pas imposé par quoi que ce soit. (Je ne commenterais pas les défauts et avantages) Donc la réponse à ta question va dépendre de quelle partie de cet éco-système elle concerne. Dans la base OSM (celle qu'on édite avec JOSM/potlatch/...) il n'y a pas de notion d'hérédité, une relation a ses tags, un way les siens, un noeud les sien, et rien n'est recopié nulle part de manière automatique. Exemple, si tu places le tag landuse=forest sur une relation multipolygon, ce tag ne se retrouvera pas sur les ways membres de la relation. L'hérédité, si elle existe quelque part, sera dans la manière d'utiliser les données OSM, c'est à dire les logiciels de rendu, l'impression d'une carte, ... Et ça, c'est laissé complètement libre à celui qui veut se servir des données OSM, et donc au logiciel qu'il va utiliser pour s'occuper de la conversion du format .osm vers un format exploitable pour son besoin. Le logiciel osm2pgsql par exemple qui est célèbre car étant utilisé par la majorité des rendus sous forme de carte des données OSM (dont le rendu proposé en page d'accueil du site www.osm.org) dispose de quelque traitement de l'hérédité au niveau de certaines relations seulement (type=route, type=boundary et type=multipolygon) et pour certains tags seulement défini dans par liste blanche ou noire Il n'y a rien de systématique donc, et tout est fait au cas par cas, selon le besoin et le logiciel utilisé. Et enfin, il y a le wiki, qui va décrire l'utilisation de relation, et pour lesquelles il va (ou non) explicitement indiquer que toute utilisation de cette relation devrait considérer l'hérédité. Mais le wiki n'est qu'une description, la décision finale revenant à l'utilisation qui sera faite des dites relations et qui dépendra, certes de la description faite du wiki, mais aussi de la manière réél et majoritaire dont les contributeurs OSM auront rentré dans la base de donnée Côté wiki il ne me parait pas à jour. Par quel processus une relation passe du stade de proposé à officiel ? Sur la base des statistiques d'utilisation ? Quand j'aurais plus de temps, j'irais faire un tour de ce côté là aussi. Exemple, si 1% seulement des routes nationales de france disposent d'une relation avec nom+ref alors que tout le reste c'est de la réplication des tags sur chacun des composants, alors je suppose que quelqu'un souhaitant faire un rendu des routes nationales de france va simplement laisser tomber l'hérédité car ça ne gérera que trop peu de cas. A l'inverse, si ce chiffre passe à 99% ça va commencer à intéresser du monde, et les choses évoluerons. Pour le projet qui m'intéresse, je compte pourtant m’appuyer sur les relations quand elles existent, et faire de l'empirique ailleurs (2 ways avec un certain nombres d'attribut communs = 1 route) (2 ways // avec même catégorie de route = probablement 1 route a chaussée séparée) Pour ma part hier j'ai ajouté 2 ou 3 routes, dès qu'elles sont coupées en 2 je les encapsules dans une street, et je ne met plus le nom dans tous les tronçons. Aux éditeurs de se débrouiller comme cela m'a été dit dans certaines réponses. Tout ça est donc un salmigondi s'entre-influençant fait de la manière d'éditer, du nombre d'utilisation qui en est faite, de documentation wiki qui en parle et du support plus au moins aisé/influencé par les éditeurs OSM. Une sorte de progression anarchique par essai/erreur qui entraîne sans doute de la perte de temps, de création d'algorithme plus compliqué mais aussi de plus de flexibilité. Mon pronostic c'est qu'on devrait ré-avancer vers la normalisation (factorisation des tags par les relations) et la multiplication des relations dans l'avenir car le découpage des routes, des cours d'eau, des frontières de manière quasi-arbitraire (restriction de vitesse, pont, tunnel, chevauchement) augmenterons et avec eux la difficulté d'éditer, donc un besoin grandissant d'outil pour les gérer. Effectivement, quand les gens aurons fait l'expérience de modifier 10 ou 20 tag pour ajouter UNE ref sur UNE rue, il trouverons plus d’intérêt aux relations. Plus généralement, depuis quelques temps que je m'intéresse à OSM, je trouve un
Re: [OSM-talk-fr] Héritage et relation
Côté wiki il ne me parait pas à jour. C'est souvent le cas, sur certaines pages soit il est en avance dans le sens où il propose de tagguer tel truc de tel manière alors que ça n'est pas encore utilisé dans la base. Soit des gens finirons par l'utiliser de cette manière car elle ressort comme mieux, soit cette page tombera dans l'oubli. A l'inverse des pratiques existent qui ne sont pas ou mal documentées, et là, il est préférable de venir compléter le wiki (tout le monde le peux), et indiquer par des pages que voilà ce qui se fait à tel endroit, pour tel et tel raison avec tel et tel avantage sur telle autre méthode qui lui ressemble et en parler sur la liste anglaise tagging pour présenter son existence aux autres, en discuter et l'améliorer et espérer que son usage va se démocratiser pour qu'elle finisse par obtenir le droit de figurer dans la liste des Established Relations : http://wiki.openstreetmap.org/wiki/Types_of_relation Ce qui d'ailleurs et un peu fumeux car la notion de Established Relations est bien vague, et certains ne lui reconnaissent pas de valeur. Mais on peut dire que des relations très utilisées par les contributeurs et très utilisées par les consommateurs sont en bonne voie pour figurer dans cette liste. Par quel processus une relation passe du stade de proposé à officiel ? J'ai envie de dire aucun ;-) Contrairement a beaucoup d'autres tags pour lequel une procédure de discussion+vote a lieu, aucune relation, à ma connaissance, n'est passée par un tel système, sans doute car beaucoup trouve cette méthode de validation comme merdique. Sur la base des statistiques d'utilisation ? y'a pas mal de ça. Plus une relation est utilisée, plus elle a de chance de finir dans la liste des Established Relations En même temps, c'est un wiki, donc n'importe qui peut ajouter à la liste, tout comme n'importe qui peut l'enlever ensuite Je pense que je vais en laisser trainer quelques une dans la base (avec un tag comment expliquant le pourquoi) C'est à mon avis la bonne solution, et je le fais régulièrement, voire en laisser beaucoup dans la base -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Héritage et relation
Le mercredi 23 mai 2012 à 23:16 -0500, Balaitous a écrit : Bonjour, Pour mon premier message, je voudrais poser une question que je me pose depuis un moment. Bonjour, et bienvenu sur la liste donc ! Est-ce que les tags d'une relation sont héréditaires ? En d'autre terme lorsque je mets un tag dans une relation celui-ci est-il transmis aux enfants de la relation (lorsque ceux-ci ne redéfinissent pas le tag en question) ? Non, il n'y a pas de notion d'héritage dans une relation OSM. Il faudrait plutôt voir les relations OSM comme une agrégation : l'objet décrit par une relation OSM est complexe et il peut être décrit en arrangeant ensemble plusieurs autres objets (qui peuvent continuer à avoir leur existence propre). Plus généralement, depuis quelques temps que je m'intéresse à OSM, je trouve un manque de séparation des aspects géométriques (point, ligne, ...) et sémantiques. Cela risque de poser d'importants problèmes de cohérence pour le nommage des routes, de plus en plus fragmentées. Je ne sais pas où en sont les discutions, mais il me semble qu'il faudrait aller vers un système de tag par regroupements récursifs des éléments, et héritage des tags. (Il me semble avoir vu qq chose dans ce sens pour la prochaine API) Je n'ai pas non plus le courage de suivre et de participer à ces discussions :) Effectivement, si on veut être très rigoureux (notamment si on aime bien le principe de normalisation relationnelle), on peut considérer que Tout est relation. Par exemple, les multiples tronçons d'une route sont des ways non-taggés qu'on inclut dans une relations portant le name= et le highway=. C'est une position cohérente d'un point de vue intellectuel, je l'ai déjà lu ou entendu. Mais ça rend l'édition bien plus compliqué. C'est pourquoi, en pratique, on continue à répéter les tags sur les multiples tronçons d'une même rue. Le pragmatisme et la dé-normalisation sont dans l'air du temps ! En gros, généraliser les relations, faire du multipolygon un élément géométrique à part entière. Le multipolygon n'est pas un élément géométrique à part entière ? Ça dépend comment tu lis et utilises la base, non ? Pour les routes cela permettrait de clarifier les aspects : * de voirie * d'entité géographiques * d'entité administrative (no de voirie, axe européen, ...) * d'entité logique (axe de transport en commun, ...) Il y a déjà des choses, et c'est d'ailleurs le point de départ de ma question, c'est en voulant regrouper des routes que je me suis dis que c'était totalement inutile s'il n'y avait pas héritage du nom de la référence, ... Ça marche même sans héritage. En fait, si tu utilises une relation pour faire ça, l'objet représentant la rue est ta relation. Les ways membres ne sont pas une rue mais de simples tronçons isolés, ils sont donc différents par nature et il n'y a pas de raison qu'ils héritent systématiquement des mêmes tags. Cela dit, encore une fois, cette pratique complique l'édition et risque de dérouter plus d'un contributeur. Il faut garder à l'esprit qu'OSM doit rester accessible au plus grand nombre. Cordialement -- Gilles Bassière - Web/GIS software engineer http://gbassiere.free.fr/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Héritage et relation
Bonjour, Le jeudi 24 mai 2012 09:36:53 Gilles Bassière a écrit : Effectivement, si on veut être très rigoureux (notamment si on aime bien le principe de normalisation relationnelle), on peut considérer que Tout est relation. Par exemple, les multiples tronçons d'une route sont des ways non-taggés qu'on inclut dans une relations portant le name= et le highway=. C'est une position cohérente d'un point de vue intellectuel, je l'ai déjà lu ou entendu. Mais ça rend l'édition bien plus compliqué. C'est pourquoi, en pratique, on continue à répéter les tags sur les multiples tronçons d'une même rue. Le pragmatisme et la dé-normalisation sont dans l'air du temps ! Oui, nous sommes certains à y rêver :-) Que c'est moche d'avoir tous ces tags répétés. Comme c'est parfois hasardeux de modifier les attributs d'une voie sans en oublier un morceau … (bon ok, on s'en sort au pire en faisant une recherche). Mais effectivement, tant que nous n'avons pas des éditeurs qui permettent de gérer cela simplement, on ne peut pas y passer. -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Héritage et relation
Le 24/05/2012 10:10, Nicolas Dumoulin a écrit : Bonjour, Le jeudi 24 mai 2012 09:36:53 Gilles Bassière a écrit : Effectivement, si on veut être très rigoureux (notamment si on aime bien le principe de normalisation relationnelle), on peut considérer que Tout est relation. Par exemple, les multiples tronçons d'une route sont des ways non-taggés qu'on inclut dans une relations portant le name= et le highway=. C'est une position cohérente d'un point de vue intellectuel, je l'ai déjà lu ou entendu. Mais ça rend l'édition bien plus compliqué. C'est pourquoi, en pratique, on continue à répéter les tags sur les multiples tronçons d'une même rue. Le pragmatisme et la dé-normalisation sont dans l'air du temps ! Oui, nous sommes certains à y rêver :-) Que c'est moche d'avoir tous ces tags répétés. Comme c'est parfois hasardeux de modifier les attributs d'une voie sans en oublier un morceau … (bon ok, on s'en sort au pire en faisant une recherche). Mais effectivement, tant que nous n'avons pas des éditeurs qui permettent de gérer cela simplement, on ne peut pas y passer. Ça n'est pas qu'une question d'éditeurs, mais de modèle de donnée. OpenStreetMap n'est pas tout à fait une base de données à objets, ou plus exactement, c'est une base de donnée à objets [1], mais on ne sait pas exactement ce que sont ces objets. L'exemple de la route est typique. Si le formalisme d'OSM était rigide, toutes les routes seraient contruites sur le même modèle : - soient des ways simples comportant tout l'information : sémantique et géométrie (c'est le modèle de départ d'OSM) - soient des relations portant la sémantique et des ways pour la géométrie et on aurait une couche ORM pour récupérer les données et les présenter comme objets. Pour des raisons historiques et pratiques, les deux modèles sont mélangés dans la base de donnée. - Pour l'avenue Machin, tronçonnées pour les sens interdits, les pistes cyclables, les relations de bus, les adresses postales, les Y à l'abord d'un rond-point...Le modèle relation+ways s'impose. - Mais pour le chemin des choux qui mène dans la garrigue, le seul way suffit avec le nom, le ref et la géométrie. Quand on veut obtenir un objet Rue Machin, on risque donc de récupérer une collection : la relation globale et les tronçons. Plus les associatedStreet et autres exotismes... Le flou sur la représentation de l'objet Rue Machin est une difficulté, pour l'édition, le traitement... mais aussi une souplesse pour la créativité. Les éditeurs essaient de tenir compte de ce flou, laissant à l'humain de déterminer s'il doit traiter une relation ou un way simple. Ce que savent bien faire les machines, c'est de repérer que tel way, c'est du highway=tertiary et d'en tenir compte pour du routage. Par contre de déterminer ce qu'est l'Avenue des Champs-Élysées [3], avec ses chaussées séparées, son rond-point au milieu, ses trottoirs, ses adresses, ses passages pour piétons, ses jardins et bassins, ses arrêts du bus et stations de métro, son serial-killer tunnel [4]... du surfacique, du linéaire, des interruptions, des associations... Pas simple... Pourtant, les logiciels de routage s'en débrouillent, mapnik aussi. Les représentations ne sont pas encore assez avancées pour qu'un modèle d'objets et interfaces (ou duck-typing) : linéaire pour le routage, surfacique pour la cartographie, associations pour les POIs... émerge et qu'une couche ORM se construise pour les éditeurs. On y vient avec les APIs, notamment XAPI [5]. Ça viendra... patience [1] http://fr.wikipedia.org/wiki/Base_de_donn%C3%A9es_orient%C3%A9e_objet [2] http://fr.wikipedia.org/wiki/Mapping_objet-relationnel [3] http://osm.org/go/0BPIIMGO4- [4] http://www.2m40.com [5] http://taginfo.openstreetmap.org/tags/name=Avenue des Champs-Élysées http://overpass-api.de/api/xapi_meta?*[name%3DAvenue+des+Champs-%C3%89lys%C3%A9es] -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Héritage et relation
Le 24 mai 2012 06:16, Balaitous balait...@mailoo.org a écrit : Bonjour, Pour mon premier message, je voudrais poser une question que je me pose depuis un moment. Est-ce que les tags d'une relation sont héréditaires ? En d'autre terme lorsque je mets un tag dans une relation celui-ci est-il transmis aux enfants de la relation (lorsque ceux-ci ne redéfinissent pas le tag en question) ? Plus généralement, depuis quelques temps que je m'intéresse à OSM, je trouve un manque de séparation des aspects géométriques (point, ligne, ...) et sémantiques. Cela risque de poser d'importants problèmes de cohérence pour le nommage des routes, de plus en plus fragmentées. Je ne sais pas où en sont les discutions, mais il me semble qu'il faudrait aller vers un système de tag par regroupements récursifs des éléments, et héritage des tags. (Il me semble avoir vu qq chose dans ce sens pour la prochaine API) En gros, généraliser les relations, faire du multipolygon un élément géométrique à part entière. Pour les routes cela permettrait de clarifier les aspects : * de voirie * d'entité géographiques * d'entité administrative (no de voirie, axe européen, ...) * d'entité logique (axe de transport en commun, ...) Il y a déjà des choses, et c'est d'ailleurs le point de départ de ma question, c'est en voulant regrouper des routes que je me suis dis que c'était totalement inutile s'il n'y avait pas héritage du nom de la référence, ... Bonjour, troll!-- comme ça c'est clair -- http://wiki.openstreetmap.org/wiki/FR:Relations/Relations_are_not_Categories Par extension, je ne comprends pas que l'on regroupe dans une relation des voies qui possèdent le même nom, le tag name est fait pour ça ! /troll A+ -- Marc Sibert m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Héritage et relation
Le jeudi 24 mai 2012 14:47:47 Marc SIBERT a écrit : Par extension, je ne comprends pas que l'on regroupe dans une relation des voies qui possèdent le même nom, le tag name est fait pour ça ! Ça n'a effectivement pas de sens. Si on regroupe dans une relation les chemins (ways) qui représente une même voie, l'étiquette « name » se doit d'être sur la relation et non sur les chemins. -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Héritage et relation
Le jeudi 24 mai 2012 à 14:47 +0200, Marc SIBERT a écrit : Le 24 mai 2012 06:16, Balaitous balait...@mailoo.org a écrit : Bonjour, Pour mon premier message, je voudrais poser une question que je me pose depuis un moment. Est-ce que les tags d'une relation sont héréditaires ? En d'autre terme lorsque je mets un tag dans une relation celui-ci est-il transmis aux enfants de la relation (lorsque ceux-ci ne redéfinissent pas le tag en question) ? Plus généralement, depuis quelques temps que je m'intéresse à OSM, je trouve un manque de séparation des aspects géométriques (point, ligne, ...) et sémantiques. Cela risque de poser d'importants problèmes de cohérence pour le nommage des routes, de plus en plus fragmentées. Je ne sais pas où en sont les discutions, mais il me semble qu'il faudrait aller vers un système de tag par regroupements récursifs des éléments, et héritage des tags. (Il me semble avoir vu qq chose dans ce sens pour la prochaine API) En gros, généraliser les relations, faire du multipolygon un élément géométrique à part entière. Pour les routes cela permettrait de clarifier les aspects : * de voirie * d'entité géographiques * d'entité administrative (no de voirie, axe européen, ...) * d'entité logique (axe de transport en commun, ...) Il y a déjà des choses, et c'est d'ailleurs le point de départ de ma question, c'est en voulant regrouper des routes que je me suis dis que c'était totalement inutile s'il n'y avait pas héritage du nom de la référence, ... Bonjour, troll!-- comme ça c'est clair -- http://wiki.openstreetmap.org/wiki/FR:Relations/Relations_are_not_Categories Par extension, je ne comprends pas que l'on regroupe dans une relation des voies qui possèdent le même nom, le tag name est fait pour ça ! /troll A+ -- Marc Sibert Bah, on est pas vendredi ! En plus ton non-argument tient même pas la route. Tu l'appuies sur une page dans laquelle il est dit explicitement : On les utilise aussi pour grouper des tronçons d'une route, par exemple : ces 15 chemins forment mis bout à bout une route du nom de truc. Un bon trolleur doit soigner ses trolls, sinon c'est pas drôle. Cordialement -- Gilles Bassière - Web/GIS software engineer http://gbassiere.free.fr/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Héritage et relation
Merci pour vos réponse. Donc si je comprend bien en dehors du myltipolygon, pas d'héritage des tags. (Je ne sais pas si c'est officiel pour le multipolygon, mais quand je l'utilise je ne tag pas les ways correspondantes, et ça a l'air de marcher). En fait, le point de départ de ma réflexion, c'est qu'après avoir contribué un peu à l'édition, j'aimerais bien avoir une carte papier! Et je compte dans les mois qui viennent essayer de faire une telle carte, échelle visé 1:25000 et 1:10. Le système existant est très orienté navigation routière. Effectivement les besoins ne sont pas les mêmes en rase campagne, où la règle un trait = une route fonctionne assez bien, et tant qu'une route n'est pas trop segmenté, la gestion manuelle de la cohérence fonctionne assez bien. En ville ou sur les grands axes routiers par contre la segmentation est beaucoup plus forte, et question simplicité d'édition, le système actuel n'est pas satisfaisant, rajouter une modifier une ref ou un nom sur une route partagée en 10 ou 2 segments à de quoi décourager plus d'un utilisateur! Le principe d'un projet tel qu'OSM est de fonctionner par petites évolutions avec compatibilité ascendante. Le principe d'héritage des tags me parait entrer dans cette catégorie. Au niveau de l'édition cela peut se gérer assez facilement si un peu comme ce qui est fait pour les relations, lors de la sélection d'un élément JOSM affiche les groupes dont il fait partie, et si JOSM propose lors du découpage d'un segment de regrouper les tags existant en créant un nouveau groupe. L’existence de la relation type=route montre qu'il y a un besoin, mais son utilité est bien faible sans l'héritage des tags. ps: Je n'ai pas le niveau en anglais pour pouvoir participer aux discutions en anglais re ps: Quel est le tag pour ajouter un commentaire ? Je veux dire par la un court texte explicatif destiné aux contributeurs futurs. J'utilise comment=* car je n'ai rien trouvé dans la doc. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Héritage et relation
Bonjour, troll!-- comme ça c'est clair -- http://wiki.openstreetmap.org/wiki/FR:Relations/Relations_are_not_Categories Par extension, je ne comprends pas que l'on regroupe dans une relation des voies qui possèdent le même nom, le tag name est fait pour ça ! /troll Ça n'était pas vraiment le sens de mon mail, et bien que je ne sois pas particulièrement partisan de regrouper toutes les banques d'un même opérateur dans une grande catégorie, des questions comme ça doivent se poser. Est-ce que OSM doit seulement rester un jouet avancé de décalcomanie pour adultes ? Ça restera certainement l'utilisation pour la majorité des contributeurs (et c'est aussi utile), mais si 5% des contributeurs pouvaient contribuer à donner plus sens ça serait bien également. C'est dans le sens que la valeur ajouté réside. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Héritage et relation
Le 24/05/2012 16:36, Balaitous a écrit : L’existence de la relation type=route montre qu'il y a un besoin, mais son utilité est bien faible sans l'héritage des tags. Attention : la relation type=route [1] est un piège pour les francophones. Elle ne désigne pas une route, mais un itinéraire : de bus, de voiture, de randonnée... L'équivalent d'une route serait une relation type=street. [1] http://taginfo.openstreetmap.org/tags/type=route http://wiki.openstreetmap.org/wiki/FR:Relation:route [2] http://taginfo.openstreetmap.org/tags/type=street http://wiki.openstreetmap.org/wiki/Relations/Proposed/Street -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Héritage et relation
Le 24/05/2012 17:07, Vincent Pottier a écrit : Attention : la relation type=route [1] est un piège pour les francophones. Elle ne désigne pas une route, mais un itinéraire : de bus, de voiture, de randonnée... Bonsoir, On appelle cela un 'faux-ami' (fosami). Et c'est ce que tous les profs de langues cherchent en premiers dans les traductions de leurs élèves! Cela montre que le sens de la phrase n'a pas été compris! Amitiés -- Yannick VOYEAUD Nul n'a droit au superflu tant que chacun n'a pas son nécessaire (Camille JOUFFRAY 1841-1924, maire de Vienne) http://www.voyeaud.org Créateur CimGenWeb: http://www.francegenweb.org/cimgenweb/ Journées du Logiciel Libre: http://jdll.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Héritage et relation
Le jeudi 24 mai 2012 à 09:36 -0500, Balaitous a écrit : Merci pour vos réponse. Donc si je comprend bien en dehors du myltipolygon, pas d'héritage des tags. (Je ne sais pas si c'est officiel pour le multipolygon, mais quand je l'utilise je ne tag pas les ways correspondantes, et ça a l'air de marcher). Je pense que c'est l'éditeur ou le rendu qui t'induit en erreur. Si tu prend un bâtiment avec un cour intérieure par exemple, il y aura deux chemins membres d'une relation de type multipolygon. Le seul objet OSM qui représente le bâtiment est la relation. Les deux chemin *ne sont pas* des bâtiments. Ils peuvent éventuellement porter des tags propres pour représenter un *autre* objet. En fait, le point de départ de ma réflexion, c'est qu'après avoir contribué un peu à l'édition, j'aimerais bien avoir une carte papier! Et je compte dans les mois qui viennent essayer de faire une telle carte, échelle visé 1:25000 et 1:10. L'exploitation envisagée de la base de données ne doit en aucun cas commander la manière dont on l'édite. Autrement dit : on ne taggue pas pour le rendu (ou pour quoi que ce soit d'autre). Si par exemple tu veux faire une carte du bâti, tu pourras avoir 2 tables après import de la base : une table du bâti polygone (way) et une table du bâti multipolygone (relation). C'est *après l'import* que tu devras faire un post-traitement pour mettre ça au propre dans une seule table. Pareil pour fusionner les tronçons de routes qui n'aurait pas été groupé dans une relation (ST_LineMerge est ton ami). Le système existant est très orienté navigation routière. Dans OSM, il y a aussi de l'occupation des sols, des chemins de randonnées, des POI, des balises de navigation maritime, des ... Les outils de modélisation OSM sont simples et souples et c'est pour ça que la base est aussi riche :) Effectivement les besoins ne sont pas les mêmes en rase campagne, où la règle un trait = une route fonctionne assez bien, et tant qu'une route n'est pas trop segmenté, la gestion manuelle de la cohérence fonctionne assez bien. En ville ou sur les grands axes routiers par contre la segmentation est beaucoup plus forte, et question simplicité d'édition, le système actuel n'est pas satisfaisant, rajouter une modifier une ref ou un nom sur une route partagée en 10 ou 2 segments à de quoi décourager plus d'un utilisateur! Rien ne t'empêche de créer une relation pour cette voie et ainsi factoriser les tags. Je ne l'ai jamais vu mais ça n'est ni impossible ni interdit. Le principe d'un projet tel qu'OSM est de fonctionner par petites évolutions avec compatibilité ascendante. Le principe d'héritage des tags me parait entrer dans cette catégorie. Au niveau de l'édition cela peut se gérer assez facilement si un peu comme ce qui est fait pour les relations, lors de la sélection d'un élément JOSM affiche les groupes dont il fait partie, et si JOSM propose lors du découpage d'un segment de regrouper les tags existant en créant un nouveau groupe. L’existence de la relation type=route montre qu'il y a un besoin, mais son utilité est bien faible sans l'héritage des tags. En fait, je pense qu'on ne se comprends pas bien. J'entends héritage au sens de la modélisation objet qui implique l'existence de classes. Dit simplement l'héritage correspond à une relation est-un entre deux concepts : la classe Écureuil hérite de Mammifère qui hérite de Animal car un écureuil *est un* mammifère et un mammifère *est un* animal. Dans ce que tu décris, je ne vois pas de relation est un ni de classes. Je vois seulement de la factorisation de tags. C'est bien de ça que tu veux parler ? Si oui, alors les relations te permettent déjà de faire ça. Les possibilité d'amélioration se situent alors : - D'une part au niveau des éditeurs, comme tu le suggères, qui pourraient proposer de créer une relation quand plusieurs objets OSM sont manifestement des parties d'un même objet physique. Libre à toi de proposer un patch implémentant ceci. - D'autre part au niveau des contributeurs qu'il faudra convaincre ou rassurer. En effet, beaucoup sont réticents à utiliser les relations (les nouveaux et les occasionnels en particulier). J'espère que tu ne manque ni de courage ni de pédagogie pour cette tâche :p Si j'interprète mal ce que tu appelles héritage, peux-tu donner des cas d'utilisation pour clarifier ? Désolé pour la longueur de la réponse et merci d'avoir lu jusqu'ici ! Cordialement -- Gilles Bassière - Web/GIS software engineer http://gbassiere.free.fr/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Héritage et relation
Le jeudi 24 mai 2012 à 18:59 +0200, Gilles Bassière a écrit : Le jeudi 24 mai 2012 à 09:36 -0500, Balaitous a écrit : Merci pour vos réponse. Donc si je comprend bien en dehors du myltipolygon, pas d'héritage des tags. (Je ne sais pas si c'est officiel pour le multipolygon, mais quand je l'utilise je ne tag pas les ways correspondantes, et ça a l'air de marcher). Je pense que c'est l'éditeur ou le rendu qui t'induit en erreur. Si tu prend un bâtiment avec un cour intérieure par exemple, il y aura deux chemins membres d'une relation de type multipolygon. Le seul objet OSM qui représente le bâtiment est la relation. Les deux chemin *ne sont pas* des bâtiments. Ils peuvent éventuellement porter des tags propres pour représenter un *autre* objet. En fait, le point de départ de ma réflexion, c'est qu'après avoir contribué un peu à l'édition, j'aimerais bien avoir une carte papier! Et je compte dans les mois qui viennent essayer de faire une telle carte, échelle visé 1:25000 et 1:10. L'exploitation envisagée de la base de données ne doit en aucun cas commander la manière dont on l'édite. Autrement dit : on ne taggue pas pour le rendu (ou pour quoi que ce soit d'autre). Entièrement d'accord. Le point de départ est effectivement l'élaboration d'une carte, mais les questions sont plus générales. La question que je me suis posé est quand deux way highway=* sont parallèles (pas évident à détecter, mais c'est possible algorithmiquement) s'agit-il des deux chaussées d'une même route ou non ? Cette information n'est pas spécifique à un rendu particulier, c'est une question d'échelle de représentation (et pas uniquement graphique) de l'information. Les relations existent, mais il y a un gros travail de standardisation à faire. Sur le wiki, je voie que des propositions de 2008 restent aujourd'hui des propositions! et le nombre de relation officiellement reconnues ne dépasse pas 6! Assez limité pour décrire de l'information de grande échelle. Pour les routes street ? associatedstreet ? collected way ? Si par exemple tu veux faire une carte du bâti, tu pourras avoir 2 tables après import de la base : une table du bâti polygone (way) et une table du bâti multipolygone (relation). C'est *après l'import* que tu devras faire un post-traitement pour mettre ça au propre dans une seule table. Pareil pour fusionner les tronçons de routes qui n'aurait pas été groupé dans une relation (ST_LineMerge est ton ami). Le système existant est très orienté navigation routière. Dans OSM, il y a aussi de l'occupation des sols, des chemins de randonnées, des POI, des balises de navigation maritime, des ... Il n’empêche que la représentation des routes est très orienté voie de circulation. Les outils de modélisation OSM sont simples et souples et c'est pour ça que la base est aussi riche :) Effectivement les besoins ne sont pas les mêmes en rase campagne, où la règle un trait = une route fonctionne assez bien, et tant qu'une route n'est pas trop segmenté, la gestion manuelle de la cohérence fonctionne assez bien. En ville ou sur les grands axes routiers par contre la segmentation est beaucoup plus forte, et question simplicité d'édition, le système actuel n'est pas satisfaisant, rajouter une modifier une ref ou un nom sur une route partagée en 10 ou 2 segments à de quoi décourager plus d'un utilisateur! Rien ne t'empêche de créer une relation pour cette voie et ainsi factoriser les tags. Je ne l'ai jamais vu mais ça n'est ni impossible ni interdit. Le problème est que la factorisation des tags n'est pas reconnue (exception du multipolygon), il me semble que la plupart des moteurs de rendu fonctionnent au niveau trait. Le principe d'un projet tel qu'OSM est de fonctionner par petites évolutions avec compatibilité ascendante. Le principe d'héritage des tags me parait entrer dans cette catégorie. Au niveau de l'édition cela peut se gérer assez facilement si un peu comme ce qui est fait pour les relations, lors de la sélection d'un élément JOSM affiche les groupes dont il fait partie, et si JOSM propose lors du découpage d'un segment de regrouper les tags existant en créant un nouveau groupe. L’existence de la relation type=route montre qu'il y a un besoin, mais son utilité est bien faible sans l'héritage des tags. En fait, je pense qu'on ne se comprends pas bien. J'entends héritage au sens de la modélisation objet qui implique l'existence de classes. Dit simplement l'héritage correspond à une relation est-un entre deux concepts : la classe Écureuil hérite de Mammifère qui hérite de Animal car un écureuil *est un* mammifère et un mammifère *est un* animal. Effectivement c'est bien de cette notion de factorisation des tags dont je veux parler. Et je constate que c'est une question que d'autres se posent puisque j'ai découvert une proposition de relation genre collected tag. Dans ce que tu décris, je ne vois pas de relation
