Re: [OSM-talk-fr] Nom commun à plusieurs polygones
2012/8/22 Philippe Verdy verd...@wanadoo.fr: C'est pour tant ce qu'il faut faire. Le nom commun pour l'ensemble des polygone va dans la relation multipolygone. Le tag 'name' n'est qu'une partie du problème. Les deux polygones ont des tags communs (name, landuse) et différents (wood). Alors qu'un des caractères de l'objet est décrit par un tag composé (landuse+wood). Si on met uniquement name dans la relation, on perd le lien direct entre le nom et les typages landuse. Si on met aussi le tag commun landuse dans la relation, on perd le lien direct entre landuse et wood. On ne peut pas mettre wood dans la relation puisqu'il est différent pour chaque polygone. Perso, je dirais que la relation de type multipolygon est bien adapté pour grouper des polygones de même nature (tous les tags identiques) mais pas dans les autres cas, surtout pour les tags composés. Logiquement, on pourrait dire que les tags communs sont mis dans la relation et que les parties plus spécifiques se mettent dans les polygones eux-même. Aux logiciels ensuite de reconstruire l'ensemble du typage en additionnant les tags de la relation avec ceux de chaque polygone. Mais je ne crois pas que ce soit formalisé quelque part et je doute qu'aucun logiciel procède de cette façon. Je pense que ce problème mériterait une réflexion au niveau international , sur la liste tagging par exemple. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nom commun à plusieurs polygones
Philippe Verdy a écrit : Le 21 août 2012 21:38, Plop76 vaujani...@free.fr a écrit : Bonjour, En essayant de nommer un bois qui est représenté par deux polygônes adjacents avec des tags incompatibles (http://www.openstreetmap.org/browse/way/177031065 et http://www.openstreetmap.org/browse/way/177031066), je vois que Mapnik affiche deux fois le nom, ce qui me semble inutile. Est-ce la façon correcte de tagguer (en laissant se débrouiller les logiciels de rendu) ? J'ai pensé à faire un multipolygon avec le tag name dessus, mais cela ne respecterait pas le wiki qui dit que si la relation multipolygon a des tags, ceux des polygones extérieurs doivent être ignorés. C'est pour tant ce qu'il faut faire. Le nom commun pour l'ensemble des polygone va dans la relation multipolygone. Et tu fais une mauvaise interprétation de ce que dit le wiki : ce qu'il faut lire c'est que si les polygones adjascents peuvent avoir leur propre nom, cela ne veut pas dire qu'ils le perdent parce qu'un mutlipolygone qui les inclut en porte un autre. Ce que cela signifie c'est que le multipolygone, s'il definit un nom adopte ce nom pour l'ensemble qu'il représente, indépendamment des noms qui peuvent être définis pour ses composantes. En revanche si les composantes portent le même nom que l'ensemble, le nom donné aux composantes est inutile, souvent, mais pas toujours (par exemple une ville et un canton portent chacun un nom même s'il est identique dans le champ name (mais les autres tags indiquent que ce sont en fait des objets différents par nature, bien qu'homonymes : la ville ne perd pas son nom parce qu'un canton homonyme prend le même nom). Quand je lis : «There is more than one outer way: The relation has tags Use the relation tagging. Ignore anything on the ways.» Je comprends que si je mets le nom dans la relation, les tags wood des composantes vont être ignorés par exemple (Ça changerait rien avec Mapnik de toute façon...) En fait ignore anything on the ways voudrait dire d'ignorer tout ce qui est incohérent avec les tags sur la relation ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] [forum-osm-fr]Un de plus !
Le message suivant de : ## Bonjour à toutes et tous, Nouveau venu sur votre forum d'entraide, c'est avec plaisir que je trouve un forum en français. Je débute avec openstreetmap, et je suis surpris des possibilités et du travail déjà effectué, du beau boulot! Bernard A+ a été posté sur le forum http://forum.openstreetmap.fr/viewforum.php?f=10 Une réponse par mail sur l'adresse d'expédition n'arrivera nulle part Une réponse à la liste ne sera pas transmise au forum, ce qui n'empêche pas une concertation sur la liste avant de recopier la/les meilleurs réponses sur le forum. Notez qu'il n'est pas necessaire d'avoir un compte sur le forum pour répondre. -- Les questions sur ce robot de transfert forum-liste peuvent être posées à sylvainaletuffe.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Ligne électrique enterrée
Bonjour, Je n'arrive pas à trouver l'info pour tagguer une ligne à très haute tension enterrée. Comme pour les cours d'eau [1], je pensais ajouter 'tunnel=yes' et 'layer=-1'. J'a bon ? Samy [1] http://wiki.openstreetmap.org/wiki/FR:Tag:waterway%3Dstream ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Ligne électrique enterrée
Le 22/08/2012 10:34, Samy Mezani a écrit : Bonjour, Je n'arrive pas à trouver l'info pour tagguer une ligne à très haute tension enterrée. Comme pour les cours d'eau [1], je pensais ajouter 'tunnel=yes' et 'layer=-1'. J'a bon ? Samy [1] http://wiki.openstreetmap.org/wiki/FR:Tag:waterway%3Dstream http://wiki.openstreetmap.org/wiki/Key:power En tout cas c'est ce que propose le wiki : tunnel=yes Use this if the line is underground. (disputed, see also location=underground) Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Ligne électrique enterrée
Samy Mezani a écrit : Bonjour, Je n'arrive pas à trouver l'info pour tagguer une ligne à très haute tension enterrée. Comme pour les cours d'eau [1], je pensais ajouter 'tunnel=yes' et 'layer=-1'. J'a bon ? Samy [1] http://wiki.openstreetmap.org/wiki/FR:Tag:waterway%3Dstream Il y a les tags power=cable et power=underground_cable (cf. http://wiki.openstreetmap.org/wiki/Power_lines) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] [forum-osm-fr]Live GPS
Le message suivant de : ## Bonjour à toutes et tous, Nouveau sur le forum, et nouvel utilisateur d'Openstreetmap, j'ai réussi à intégrer la feuille du cadastre de mon secteur, et j'aimerais pouvoir effectuer un suivi de ma trace GPS en live pour me situer sur des parcelles. J'ai donc installé le module live gps proposé mais au démarrage d'openstreetmap, j'ai un message d'erreur: impossible de charger la bibliothèque rxtxSerial ([i] raphael-mack.de) [/i] J'ai bien tenté différentes manip. mais je commence à y perdre mon latin. Mon PC tourne sous win 7 pro. En vous remerciant par avance pour votre aide PS : un grand Merci à Pieren :idea: qui m'avait aidé dans mes début via un autre forum, et dont je viens de voir qu'il est un de vos membres. Bernard A+ a été posté sur le forum http://forum.openstreetmap.fr/viewforum.php?f=3 Une réponse par mail sur l'adresse d'expédition n'arrivera nulle part Une réponse à la liste ne sera pas transmise au forum, ce qui n'empêche pas une concertation sur la liste avant de recopier la/les meilleurs réponses sur le forum. Notez qu'il n'est pas necessaire d'avoir un compte sur le forum pour répondre. -- Les questions sur ce robot de transfert forum-liste peuvent être posées à sylvainaletuffe.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Ligne électrique enterrée
Merci, et désolé pour le bruit, je n'avais pas bien cherché. 'location' me conviendrait plus que 'tunnel' mais bon. Samy le 22/08/2012 10:52, Frédéric Rodrigo a écrit: Le 22/08/2012 10:34, Samy Mezani a écrit : Bonjour, Je n'arrive pas à trouver l'info pour tagguer une ligne à très haute tension enterrée. Comme pour les cours d'eau [1], je pensais ajouter 'tunnel=yes' et 'layer=-1'. J'a bon ? Samy [1] http://wiki.openstreetmap.org/wiki/FR:Tag:waterway%3Dstream http://wiki.openstreetmap.org/wiki/Key:power En tout cas c'est ce que propose le wiki : tunnel=yes Use this if the line is underground. (disputed, see also location=underground) Frédéric. ___ 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] Ligne électrique enterrée
2012/8/22 Samy Mezani samy.mez...@wanadoo.fr: Merci, et désolé pour le bruit, je n'avais pas bien cherché. 'location' me conviendrait plus que 'tunnel' mais bon. Samy 'location' est un terme trop vague pour OSM. La localisation, l' endroit, l' emplacement se fait d'abord par les coordonnées x,y définis dans les noeuds. C'est une information de base déjà disponible. Des tags comme à gauche, vers le nord ou nord-nord-est (des propositions de ce genre existent), emplacement (traduction de 'location') sont à proscrire en général car la localisation se fait autrement. ... sauf qu'il manque le 'z' pour la hauteur des noeuds (un 'z' négatif signifierait automatiquement 'souterrain'). On entre dans le mapping 3D avec toutes ses difficultés (éditeur adapté, sources fiables). Pour compenses, certains tags ont été très tôt créés dans le but de juste dire c'est souterrain : d'abord, il y a eu tunnel, puis covered (essentiellement pour les routes). Puis on a vu les tags indiquant des chiffres : ele pour les hauteurs absolues ou height pour les valeurs relatives. Et enfin undergound pour les parkings. La clé location n'est apparue que tardivement et essentiellement dans le contexte des pipelines. Maintenant, cette clé est utilisée de manière abusive : 7300 valeurs différentes pour 31000 exemplaires d'après taginfo. Ce qui prouve que son sens est souvent mal interprété. Il aurait mieux fallu proposer un underground=yes si le mot tunnel ne plaisait pas. Je ne désespère pas que ce genre d'erreurs soient corrigées dans le futur. Pieren (on voit souvent d'autres propositions de mot-clés du même genre rejetés car trop vagues ou trop généralistes comme type ou class) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nom commun à plusieurs polygones
Salut, Le 22 août 2012 10:05, Plop76 vaujani...@free.fr a écrit : Philippe Verdy a écrit : Le 21 août 2012 21:38, Plop76 vaujani...@free.fr a écrit : Bonjour, En essayant de nommer un bois qui est représenté par deux polygônes adjacents avec des tags incompatibles (http://www.openstreetmap.org/**browse/way/177031065http://www.openstreetmap.org/browse/way/177031065et http://www.openstreetmap.org/**browse/way/177031066http://www.openstreetmap.org/browse/way/177031066), je vois que Mapnik affiche deux fois le nom, ce qui me semble inutile. Est-ce la façon correcte de tagguer (en laissant se débrouiller les logiciels de rendu) ? J'ai pensé à faire un multipolygon avec le tag name dessus, mais cela ne respecterait pas le wiki qui dit que si la relation multipolygon a des tags, ceux des polygones extérieurs doivent être ignorés. C'est pour tant ce qu'il faut faire. Le nom commun pour l'ensemble des polygone va dans la relation multipolygone. Et tu fais une mauvaise interprétation de ce que dit le wiki : ce qu'il faut lire c'est que si les polygones adjascents peuvent avoir leur propre nom, cela ne veut pas dire qu'ils le perdent parce qu'un mutlipolygone qui les inclut en porte un autre. Ce que cela signifie c'est que le multipolygone, s'il definit un nom adopte ce nom pour l'ensemble qu'il représente, indépendamment des noms qui peuvent être définis pour ses composantes. En revanche si les composantes portent le même nom que l'ensemble, le nom donné aux composantes est inutile, souvent, mais pas toujours (par exemple une ville et un canton portent chacun un nom même s'il est identique dans le champ name (mais les autres tags indiquent que ce sont en fait des objets différents par nature, bien qu'homonymes : la ville ne perd pas son nom parce qu'un canton homonyme prend le même nom). Quand je lis : «There is more than one outer way: The relation has tags Use the relation tagging. Ignore anything on the ways.» Je comprends que si je mets le nom dans la relation, les tags wood des composantes vont être ignorés par exemple (Ça changerait rien avec Mapnik de toute façon...) En fait ignore anything on the ways voudrait dire d'ignorer tout ce qui est incohérent avec les tags sur la relation ? Je comprends le contraire… « The relation has tags » : la relation contient des attributs « Use the relation tagging » : utilise les attributs sur la relation. « Ignore anything on the ways » : ignore tout en ce qui concerne les chemins (les polygones). En tout cas, je ne sais pas quel logiciel te dis ça, mais ignorer des attributs, ça me paraît un peu culotté. __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr Cordialement, -- Mikaël Cordon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Ligne électrique enterrée
C'est vrai que mettre tunnel=yes risque de provoquer une mauvaise interprétation en cas de superposition de ways, et faire passer alors cela pour un vrai tunnel empruntable au moins par les piétons, alors que ce n'est qu'une conduite enterrée, pas un tunnel. Franchement location=underground est plus approprié (mais là encore en cas de superposition de ways, on pourrait prendre ça aussi pour un passage souterrain pour piétons (comme sous les voies ferrées d'une gare, qui magré tout sont tagués spécifiquement avec tunnel=yes). Les conduites enterrées pour l'électricité, l'eau, la fibre optique, etc... sont un réseau technique pas empruntables directement par l'homme, ce sont en plus des passages privés exploités par un opérateur même s'ils sont construits dans le domaine public (sous licence d'une collectivité locale) ou dans un domaine privé (par une servitude de passage par laquelle l'opérateur a établi un contrat pour sa responsabilité et pour indemniser les propriétaires de cette servitude, même si elle leur a été accordée dans le cadre d'une procédure publique d'expropriation partielle obligeant les propriétaires à accepter cette servitude). J'aurais donc tendance à privilégier power=underground_cable pour bien indiquer la nature de cette conduite et pour aussi éviter de la fusionner avec une autre voie qui manifestement empruntera de toute façon un autre passage, à une profondeur différente en cas de simultanéité d'un tunnel Si on allait plus loin, les réseaux d'égouts/eaux usées pourraient aussi être cartographiés mais typiquement ils sont associés à la rue qu'ils desservent au dessus (les conduites d'égouts sont aussi nommées comme la rue au dessus même si la signalisation n'a rien à voir et qu'on n'a pas de carrefour ou de feux, ou de limites de vitesses applicables. Les réseaux d'égouts sont souvent utilisés comme voies pour divers autres réseaux, dont le téléphone ou la fibre optique et les faisceaux de transports de données pour professionnels. Ils forment un réseau à part qui à mon avis ne devraient pas être fusionnés non plus, pas même avec un réseau de transport d'électricité qui en est parfaitement isolé. Même chose pour les gazoducs même si les nœuds du réseau sont accessibles par un puits couvert par une plaque depuis la rue ou un passage depuis les égouts. [OT] Par exemple l'énorme gazoduc sous pression qui passe sous terre le long de la Seine depuis le port de Gennevilliers vers le réseau de distribution de Paris ou des Hauts-de-Seine, mais dans des conduites séparées du réseau des égouts, même s'il y a des passages souterrains entre les deux... L'existence de ce gazoduc (connecté avec le réseau international de transport de gaz) s'est manifestée aux habitants quand il y a des incidents sérieux par des fuites importantes de gaz dans les égouts et des évacuations temporaires de quartier à cause du risque d'explosion souterraine, la fuite étant provoquée par un glissement de terrain dans cette couche alluvionnaire gorgée d'eau, par exemple à cause de pompages très importants réalisés par certains chantiers de construction réalisés de façon illégale... par le ministère de l'Intérieur (qui a creusé sous un de ses bâtiments plus de 15 mètres en dessous du niveau autorisé et a été contraint en urgence à cesser ces pompages et renflouer de sable plusieurs étages interdits, avec en conséquence des dégats très importants dans les immeubles de tout un quartier qui a littéralement glissé vers la Seine, en emportant avec le gazoduc qui n'a pas résisté et a inondé les sous-sols de gaz ; en plus de ça le ministère de l'intérieur a du indemniser les propriétaires de plusieurs immeubles qui ont été mis en péril, et du reloger leurs locataires, ces bâtiments ont du être démolis, malgré la construction en urgence de poutres énormes de soutien en béton qui ont éclaté en quelques semaines avant que le chantier illégal soit contraint non seulement d'arrêter les pompages mais aussi de renflouer plusieurs niveaux de sous-sol par un mélange de sable et ciment (le glissement de terrain, aggravé en 2003 lors de la canicule et de la sécheresse, a encore continué pendant plusieurs mois jusqu'à ce que les pressions s'équilibrent et que le niveau des eaux souterraines remonte pour réimpreigner les sols qui avaient été déstabilisés). Cartographier de tels gazoducs (je ne parle pas du réseau de distribution à faible pression qui dessert les habitations) n'est donc pas inutile : les habitants devraient savoir qu'un tel réseau, potentiellement dangereux, existe sous leurs pieds pour aussi savoir alerter à temps les autorités avant des incidents graves mettant en danger leurs vies et leurs biens. Pourtant GDF (ou tout autre exploitant de tels réseaux) dissimule encore de telles données, et je ne suis même pas convaincu que même les ministères, notamment le ministère de l'Intérieur, aient un état des lieux précis de ces réseaux qui ont fait l'objet de conventions diverses de passage avec les collectivités (mais
Re: [OSM-talk-fr] Ligne électrique enterrée
Le 22 août 2012 11:30, Pieren pier...@gmail.com a écrit : (on voit souvent d'autres propositions de mot-clés du même genre rejetés car trop vagues ou trop généralistes comme type ou class) Tout à fait d'accord ! Ce genre de tag qui ne précise pas à quoi il s'applique donne vite des anomalies d'interprétation dès qu'il commence à y avoir des intersections de ways ou des fusions de nœuds, et tout outil essayant de tracer une carte d'un certain nombre de caractéristiques (features). En revanche il pose nettement moins de difficultés quand on les met dans une relation ; mais par uniformité du modèle, il n'y a pas de raison de distinguer selon qu'il s'agit d'un nœud, d'un way ou d'une relation (d'autant qu'on est régulièrement amené à convertir des polygones en multipolygones, et donc en relations avec le schéma OSM actuel qui n'en fait pas des objets géométriques, pas plus qu'il ne distingue les polygones fermés simples qu'on confond encore avec les ways : cela donne fréquemment des difficultés lors de la conversion habituelle du schéma OSM vers un schéma standard OpenGIS, une conversion nécessaire pourtant dans tous les moteurs actuels de rendu ou d'analyse). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Ligne électrique enterrée
Bonjour Pourrait-on faire la différence entre : - Une ligne électrique enterrée directement dans le sol (cela existe-t'il ?) - Une ligne électrique enterrée ou posée sur le sol dans une canalisation accessible à un humain et ne pouvant pas y circuler (usage courant de la gaine de protection de couleur rouge (cas enterré) ou dans un caniveau en béton (cas posé au sol)) - Une ligne électrique enterrée dans une canalisation accessible à un humain et pouvant y circuler (tel qu'égout ou autre gros caniveau indépendant) Sinon pour les canalisation enterré, ne pas oublier les bornes de marquage : http://wiki.openstreetmap.org/wiki/Tag:pipeline%3Dmarker -- Cordialement David Crochet http://fr.wikiversity.org : Communauté pédagogique libre à laquelle chacun peut prendre part ! http://www.wikimedia.fr : Aidons la diffusion de la connaissance libre ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nom commun à plusieurs polygones
Je pense malgré tout qu'un tel regroupement de deux bois (ayant des caractéristiques wood=* différentes) dans un même multipolygone est malvenu. Mêm si ces bois portent le même nom, isl sont cartographiés comme des objets distincts. Ce n'est pas parce qu'un moteur de rendu ne fait pas la différence entre les type wood=* et ne considère que le fait que ces objets sont visualisés de façon identique comme étant une seule et même forêt que ce moteur (qui a choisi d'ignorer wood=*) doit s'empêcher alors de les fusionner dans un seul objet. S'il fait cette fusion alors, il va détecter des tags communs et devrait appliquer le nom une seule fois à cet ensemble. Dès lors ce nom sera affiché une seule fois à la position du centroïde de l'ensemble ainsi créé. Comme on ne tague pas pour le rendu, on doit alors taguer pour ce qui est le plus précis. Ce n'est pas à OSM de faire cette fusion à cause de certains tags ignorés ou non différenciés par un moteur de rendu spécifique. L'ennui c'est que les landuse=* sont souvent instables et imprécis, au regard des noms effectivement portés localement : un même landuse=forest comprend souvent des zones différentes sans s'appuyer sur le tracé des parcelles, parce que la plupart ont été créés par un import de la base Corine, qui ne s'est jamais appuyée sur le cadastre, mais seulement sur une photo apparente à un instant T (en fait un jeu de photos récoltées à des moments différents, avec une résolution faible, et analysées sommairement sans tenir compte des limites réelles de terrains, parcelles, et des limites administratives ; les landuse=* ont aussi été découpés en sous-polygones adjascents de façon totalement arbitraire, uniquement pour en réduire la surface ; surtout d'ailleurs les forêts et particulièrement dans les zones montagneuses, et les terres agrocoles qui changent fréquemment de type de culture : l'analyse Corine ne sait pas clairement distinguer la simple jachère d'une prairie d'élevage, souvent les divisions sont arbitraires et globalement cela donne juste une idée du taux approximatif d'utilisation des terres, dans des zones larges de la taille d'une commune entière, et pas au niveau local ; cela fait juste joli aussi sur les cartes, mais c'est en fait assez éloigné de la topographie réelle dès qu'on zoome un peu au point qu'on voit se distinguer certaines limites de parcelles, comme aussi l'hydrographie terrestre et maritime...). J'espère que l'import Corine, qui n'a été fait qu'une fois pour la base 2006, ne sera jamais refait une autre fois car partout on est amené à corriger ces données très imprécises. On peut essayer de garder certains tags contenant les identifiants Corine d'origine, mais dès qu'on a fait des modifications pour préciser les choses, il n'y a plus unicité des zones Corine dans OSM : cela signale juste que la zone Corine a été importée et ne doit plus l'être. Peut importe alors la date de cet import, mais au moins cela devrait garantir qu'on ne le refera pas pour le même objet Corine, même si depuis Corine a été mis à jour. On peut faire, et on fait, mieux que Corine dans OSM, même si pour l'instant on n'a pas des données plus précises avec le même taux de couverture du territoire (Corine est là dans la base OSM faute de mieux... en attendant qu'on corrige) Le 22 août 2012 09:57, Pieren pier...@gmail.com a écrit : 2012/8/22 Philippe Verdy verd...@wanadoo.fr: C'est pour tant ce qu'il faut faire. Le nom commun pour l'ensemble des polygone va dans la relation multipolygone. Le tag 'name' n'est qu'une partie du problème. Les deux polygones ont des tags communs (name, landuse) et différents (wood). Alors qu'un des caractères de l'objet est décrit par un tag composé (landuse+wood). Si on met uniquement name dans la relation, on perd le lien direct entre le nom et les typages landuse. Si on met aussi le tag commun landuse dans la relation, on perd le lien direct entre landuse et wood. On ne peut pas mettre wood dans la relation puisqu'il est différent pour chaque polygone. Perso, je dirais que la relation de type multipolygon est bien adapté pour grouper des polygones de même nature (tous les tags identiques) mais pas dans les autres cas, surtout pour les tags composés. Logiquement, on pourrait dire que les tags communs sont mis dans la relation et que les parties plus spécifiques se mettent dans les polygones eux-même. Aux logiciels ensuite de reconstruire l'ensemble du typage en additionnant les tags de la relation avec ceux de chaque polygone. Mais je ne crois pas que ce soit formalisé quelque part et je doute qu'aucun logiciel procède de cette façon. Je pense que ce problème mériterait une réflexion au niveau international , sur la liste tagging par exemple. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] cartes de pays
Oui bien sûr, j'avais posé ma question ailleurs, je n'avais pas fait le lien entre les 2; comme j'ai dû (mal) expliquer, mon but est de mettre à disposition de participants d'un forum de camping car quelques outils leur permettant d'avoir les cartes de ces 3 pays (Espagne, Portugal et Maroc), avec des POI's que nous intégrerons, (terrains de campings, cabinets médicaux, ravitaillement en gaz, et plein d'autres choses) avec leur géolocalisation bien sûr. Quelque chose que j'ai oublié de préciser, un d'entre vous m'a bien expliqué ce qu'est osm, une carte, des données etc; comme j'ai dit, j'ai fait un peu de cartographie sur mapinfo il y a quelques années, ainsi que de la base de données; je suis donc familiarisé avec ces concepts. Je fais aussi professionnellement du graphisme, et connais donc aussi la différence entre vectorial et bitmap; bien sûr, quand je parle de télécharger l'intégralité des données d'un pays, 3 en l'occurence, je parle du fond de carte plutôt en vectoriel, les routes, les noms des villes, villages, éventuellement l'hydrologie; à priori, ça doit être suffisant; ensuite, il faut que l'affichage soit du type glissant, donc charger ce que l'on veut voir au fur et à mesure, avec pour nous concepteurs la possibilité d'ajouter une ou plusieurs couches (calques) avec les poi's que l'on désire afficher; je pourrais m'occuper du moteur soit sous josm, soit sous mapinfo si celui-ci accepte les fichiers osm (question ouverte d'ailleurs), d'autant que nous avons déjà des bases de données sur les poi's avec leur géolocalisation, donc facilement importable sur mapinfo; les utilisateurs possèdent un panel composé surtout de pc portables, d'autres de gps, garmin surtout mais aussi tomtom, tablettes pas beaucoup mais à prévoir je vous mets le lien vers le site où vous pourrez en voir plus sur les besoins http://www.ccomaroc.com/forum1/portal.php je vous remercie de l'aide que vous pourrez nous apporter René 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
[OSM-talk-fr] PlaceMaker Bureaux de poste : quelques évolutions
Bonjour, Quelques changements ces jours-ci : * Une nouvelle couche de données (puces bleues) indique les objets taggués dans OSM en amenity=post_office mais dépourvus de tag ref:FR:LaPoste. Ce sont donc des candidats potentiels à fusionner avec les points proposés par La Poste. * Une autre nouvelle couche illustre par de (plus ou moins) grandes lignes droites, le chemin parcouru par un bureau de poste, entre ses coordonnées proposées par le fichier de La Poste, et ses coordonnées une fois intégré dans OSM. On est souvent proches (quelques mètres) mais quelques vilains petits canards font grimper la moyenne. Le record pour l'instant est détenu par une poste du Finistère proposée en Saône-et-Loire : 680 km ! Record mis à part, ça me semble intéressant pour illustrer les disparités de qualité au sein d'un même jeu de données. Il n'y a pas de qualité OpenData, ni même de qualité La Poste... * Ces nouvelles couches m'ont fait activer le célèbre bouton '+' bleu en haut à droite de la carte, pour allumer/éteindre chacune séparément. D'autres évolutions à venir : * mettre à jour la source de données : La Poste a publié une m-à-j en juillet, je ne l'ai pas encore analysée * ajouter les postes d'Outre-Mer * gérer les bureaux fermés/supprimés sur le terrain, bien que proposés dans le fichier À suivre, toujours par ici : http://osm.vdct.free.fr/postes/index.html merci 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] Nom commun à plusieurs polygones
Mikaël Cordon a écrit : En tout cas, je ne sais pas quel logiciel te dis ça, mais ignorer des attributs, ça me paraît un peu culotté. C'est sur le wiki : http://wiki.openstreetmap.org/wiki/Relation:multipolygon#Detailed_tagging ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Ligne électrique enterrée
Bonjour, Pas du tout hors sujet, tu apportes une justification de taille à l'existence d'OSM : une base de données cartographique hors pression d'intérêt. Je vote +1 pour cartographier les trucs qui grattent et dérangent. A+ Le 22/08/2012 13:04, Philippe Verdy a écrit : Couic Ainsi régulièrement on constate en France et dans d'autres pays des accidents de chantiers, parfois avec des victimes humaines, où un tractopelle vient éventrer une conduite dangereuse qui n'était signalé sur aucune carte, alors que les constructeurs ont eu les permis et autorisations nécessaires (preuve que les collectivités qui fournissent ces autorisations de chantiers ne connaissent pas tout). [/OT] Couic Le 22 août 2012 10:58, Samy Mezani samy.mez...@wanadoo.fr a écrit : Merci, et désolé pour le bruit, je n'avais pas bien cherché. 'location' me conviendrait plus que 'tunnel' mais bon. Samy le 22/08/2012 10:52, Frédéric Rodrigo a écrit: Le 22/08/2012 10:34, Samy Mezani a écrit : Bonjour, Je n'arrive pas à trouver l'info pour tagguer une ligne à très haute tension enterrée. Comme pour les cours d'eau [1], je pensais ajouter 'tunnel=yes' et 'layer=-1'. J'a bon ? Samy [1] http://wiki.openstreetmap.org/wiki/FR:Tag:waterway%3Dstream http://wiki.openstreetmap.org/wiki/Key:power En tout cas c'est ce que propose le wiki : tunnel=yes Use this if the line is underground. (disputed, see also location=underground) Frédéric. ___ 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 ___ 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
[OSM-talk-fr] GRP en direct
Bonjour à tous, le GRP est une course en montagne dans les Pyrénées dont la première épreuve a démarré aujourd'hui. Le site http://chrono.geofp.com/grp2012/v2/ permet de suivre l'avancement des concurrents en direct sur une carte, dont la couche de fond par défaut est... le rendu mapnik Openstreetmap bien sûr. Christophe -- | http://orhyginal.free.fr | ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
