Re: [OSM-talk-fr] Code Corine 324 «Forêt et v égétation arbustive en mutation»
On mardi 13 octobre 2009, Jean-Christophe Haessig wrote: Moi j’aimerais bien un tag density=scattered… Au delà même de corine, quand je tag certaines forêts de montagne avec les photos yahoo très précise, il arrive que je rencontre des zones comme tu décrivais. ni des paturages, ni des forêts. Au début j'avais pensé mettre en paturage et avec des points pour chaque arbre visible, mais faut pas être maso non plus. J'aurais donc bien aimé un landuse=scattered_forest ou comme tu le proposes un tag de densité. Comme d'hab, yaka utilisé et documenter ? -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Code Corine 324 «Forêt et vég étation arbustive en mutation»
Le mardi 13 octobre 2009 à 01:37 +0200, Jean-Christophe Haessig a écrit : Bonsoir, J’ai vu qu’il avait plus ou moins été décidé de tagguer ces zones en natural=wood;wood=mixed. La raison était que ces zones seraient des forêts en devenir. Sur la nomenclature, le code 324 est pour l'instant abandonné. natural=wood;wood=mixed est déjà utilisé pour le code 313 Je trouverais dommage de perdre les distinctions de terrains de CLC dans OSM. Idem pour natural=scrub pour le maquis code CLC 323, mais pas pour le 333. J’ai aussi l’impression que cela regroupe également tous les cas d’arbres épars, c’est à dire des zones avec des arbres mais pas assez denses pour être qualifiées de forêt (à priori toutes les forêts n’ont pas une orée nette). Difficle de dire s’il s’agit d’ex-ou-future-forêt et cela dit cette transformation durera plusieurs années si elle a lieu. Devons nous cartographier le monde tel qu’il sera dans 10 ans ou tel qu’il est maitenant ? Moi j’aimerais bien un tag density=scattered… Je ne suis pas trés chaud pour une nouvelle clé. Pour le code 324, pourquoi pas natural=wood;wood=shrub shrub signifiant arbuste ou plus généralement végétation arbustive ? Pour le code CLC 333 pourquoi pas natural=steppe Librement, -- Christophe Merlet (RedFox) signature.asc Description: Ceci est une partie de message numériquement signée ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Code Corine 324 «Forêt et vég étation arbustive en mutation»
Le mardi 13 octobre 2009 à 09:59 +0200, Christophe Merlet (RedFox) a écrit : Je ne suis pas trés chaud pour une nouvelle clé. Pour le code 324, pourquoi pas natural=wood;wood=shrub shrub signifiant arbuste ou plus généralement végétation arbustive ? Pour le code CLC 333 pourquoi pas natural=steppe Je rajouterais que CLC étant une base de dimension européenne, il me semble indispensable d'assurer dés maintenant une correspondance unique de chaque code CLC vers un équivalent OSM afin que le problème soit résolu avant que d'autres pays décide de faire leur propre table de correspondance parceque tel ou tel type de végétation ets prédominant chez eux. J'imagine sans peine, que les personnes qui ont créé la nomenclature CLC au niveau européen y ont réfléchi longuement avant de la déployer. On ne devrait donc pas se précipiter a attribuer des correspondances OSM identiques a différents codes CLC juste histoire d'importer des polygones... Librement, -- Christophe Merlet (RedFox) signature.asc Description: Ceci est une partie de message numériquement signée ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] [Fwd: [OSM-talk] State of the Map 2010 - Where?]
Ca y est! La course au SOTM 2010 vient d'etre officiellement ouverte. Le lien est le suivant: http://wiki.openstreetmap.org/wiki/State_Of_The_Map_2010/Bid Emilie Laffray ---BeginMessage--- State of the Map 2009 is now several months behind us. Thanks to all the people who where there (either in person or virtual) we can look back on three awesome days. It showed what a wonderfull bunch of people we are! It's time to think about the next State of the Map, SotM10. During the last conference there have been an informal vote on the location of next years event. Several places where mentioned including the ranch of former president George Bush or a Lidl supermarket. We apparently do not only want our data to be used in unexpected ways but also want to have our conference at unexpected locations! Now it's time to work on the next location/venue of the State of the Map. Do you want to have this international conference in your favorite country/city? Let's hear it! The call for bids is now open at http://wiki.openstreetmap.org/wiki/State_Of_The_Map_2010/Bid Cheers, Henk Hoff State of the Map 2010 ___ talk mailing list t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ---End Message--- signature.asc Description: OpenPGP digital signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] RFC - (boundary=military)
Bonjour à tous, La discution est maintenant lancée pour le tag boundary=military. La page de présentation : http://wiki.openstreetmap.org/wiki/Proposed_features/Military_base Et les commentaires : http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Military_base Bonne journée, Gilles ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Corine] Polygone geant (Attention SQL a faire peur)
Je suis le débat avec attention. Quelle est donc la méthodologie à suivre? Car je peut vous dire que des poly landluse=farm de très grande taille j'en ai trouvé quelques uns en cherchant un peut. 2009/10/13 Emilie Laffray emilie.laff...@gmail.com Etienne Chové wrote: Est ce que le gros polygone ne fait pas presque autant de taille que l'original ? Le but est de générer 60 fichiers et des les envoyer un par un ? C'est donc du multipolygone où un a un outer (le gros) et plein de inner (les petits) ? Je crois que j'ai pas tout compris :-( Le gros polygone est quasiment aussi gros que le principal. Toutefois, les autres polygones sont indépendants du principal du fait du coupure du polygone principal. Dans certains cas, la surface est négligeable, dans d'autres cas, elle ne l'est pas. Les inners ne rentrent pas en ligne de compte en fait, car ils font partie d'un polygone. La technique utilisée en fait ne résoud qu'un problème: importer un polygone qui est énorme et qui n'a plus les overlaps puisque je les ai enlevés. Il est possible de découper un gros polygone en plusieurs bouts mais ça implique d'écrire un petit programme en Python pour découper ça a posteriori, ce qui devrait être assez facile a faire. Après, on peut en théorie tout remettre dans le même fichier OSM, mais on ne change rien a la taille. Ou alors, on fait le travail en amont a partir de la base Corine, et on crée des entrées supplémentaires (centroid au final plus simple a trouver). Enfin, voila ce ne sont que des idées. Mais techniquement tout est possible. Emilie Laffray ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Mon weblog - http://www.tenshu.fr/ Je soutiens le Logiciel Libre, j'adhère à l'APRIL ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] natural=rock bug / osmose / corine
Vincent Meurisse a écrit : if tags[CLC:code] == 323: tags[natural] = scrub if tags[CLC:code] == 324: tags[natural] = wood tags[wood] = mixed if tags[CLC:code] == 331: tags[natural] = beach if tags[CLC:code] == 333: tags[natural] = scrub Merci pour ta vigilance, je ne sait pas ce qui s'est passé, j'en ai loupé un paquet. C'est corrigé. -- Etienne ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Corine] Polygone geant (Attention SQL a faire peur)
Emilie Laffray a écrit : Celui ci est constitue d'un très gros polygone, et pleins de tous petits. Est ce que le gros polygone ne fait pas presque autant de taille que l'original ? Le but est de générer 60 fichiers et des les envoyer un par un ? C'est donc du multipolygone où un a un outer (le gros) et plein de inner (les petits) ? Je crois que j'ai pas tout compris :-( -- Etienne ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import polygones CLC manquants - Re tour d'expérience.
Emilie Laffray a écrit :
Etienne Chové wrote:
Emilie, t'as une version corrigée ? Je doit avoir une ancienne version
avant la correction du bug 2001.
Voila la correction.
Merci, c('est corrigé.
--
Etienne
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Code Corine 324 «Forêt et vég étation arbustive en mutation»
2009/10/13 Christophe Merlet (RedFox) red...@redfoxcenter.org: Je rajouterais que CLC étant une base de dimension européenne, il me semble indispensable d'assurer dés maintenant une correspondance unique de chaque code CLC vers un équivalent OSM afin que le problème soit résolu avant que d'autres pays décide de faire leur propre table de correspondance parceque tel ou tel type de végétation ets prédominant chez eux. C'est bien pour ça que j'avais traduit la page de correspondance CLC-OSM en anglais sur le wiki ;-) J'ajouterais qu'avant de chercher une correspondance systématique, il faut savoir pour quelle échelle ses données sont faites (1/100.000e, taille minimum 25h.) et regarder des exemples concrets en utilisant le site de l'ifen qui a les photos de l'IGN. Les polygones marqués comme mixtes sont parfois des mélanges sur tout le polygone et parfois une addition de parcelles trop petites pour Corine. Et eux devaient couvrir 100% du territoire, donc ces valeurs d'usage mixte ou en devenir ont souvent servies de bouche-trou. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rond-points coupés
Bhen oui, dilemme dans la stratégie générale d'osm... :-( Utiliser les points seulement, ça deviendrait vite ingérable (invisible, et pas exploité), Saucissonner tout en petits morceaux et les fourrer dans des relations, ce serait certes systématique, mais tant que les éditeurs sont ce qu'ils sont, ça va finir dans un plateau de charcuterie à la fin d'un buffet froid : Plat de résistance : Île flottante de jambon cru dans saumure de cornichon, garnie d'anneaux de peau de tranches de salami :-( (Pour être conséquent avec soi-même, il faudrait que Tout osm du jour au lendemain bascule vers un système de relations imbriquées : Plus aucun tag sur des nodes ni sur des ways, qui eux deviendraient géopositionnement pur, et toute la description irait dans les relations... On aurait donc aussi des relations mono-nodes, et un système de super-hyper-duper-relations. Il deviendrait inconséquent, de noter un copyright dans chaque sous- élément ou sous-relation : On aurait une seule super-relation par année d'édition de cadastre, dans laquelle on fourre tous les tracés de cette année-là, l'IGN ne figurera qu'une seule fois : dans le tag d'une super-relation dans laquelle on engloutirait toutes ses bornes, voire même une seule relation pour tous les parkings de France et de Navarre, pareil pour les églises, mairies, peaks et autres. Ce deviendrait une approche inverse à l'actuelle. Peut-être ça viendra un jour, mais on n'en est pas là, pour l'instant c'est hybride). Revenir à l'api précédente : en aucun cas, Et superposer des ways à part pour les itinéraires en utilisant les mêmes nodes, ça avait été regardé comme indigne, ringard out over Mathusalem, si j'ai bon souvenir (Dans l'amas des spaghetti superposés, parfois il n'est pas aisé de sélectionner celui qu'on cherche, il est plus facile de dire, que c'est méthode ringard...) Donc, qu'est-ce qu'on fait ? Pour être in ? me grattant la tête... ...bhen, n'étant pas féru en relations, et par trouille de casser une relation, pour l'instant je pense continuer avec des ways superposés, pour les trajets/itinéraires. Dans le cas d'itinéraire rando que présente Fabien, si le randonneur doit emprunter le bitume de la route (comme c'est le cas dans des villages où il n'y a pas de trottoirs, et sur beaucoup de petites routes dehors), je pense que je collerai un way footway supplémentaire sur les nodes de la route, mais si les randonneurs passent sur le bas-côté (se sont faits un sentier à part), ou en ville sur des trottoirs, j'y mettrai probablement un footway avec des nodes séparés, et des nodes communs avec les highway voitures, là où ça les croise. Et pour le trajet d'un bus ou tram, je probablement mettrai un way à lui, pareillement : Si ça partage le même espace, sur les mêmes nodes que la route, mais si ça passe à côté sur voie séparée ou entre deux voies sens- uniques, sur des nodes distincts. Donc le rond-point resterait un rond-point fermé, avec collé dessus d'autres ways qui eux représentent le trajet du car, donc un way pour l'aller et un autre pour le retour, à chaque fois un way complet entre deux arrêts (solution que je préférerais), Ensuite, je pourrai imaginer de découper ce way-trajet en morceaux sur le rond-point, et fourrer les morceaux dans des relations distinctes, une pour l'aller, l'autre pour le retour. Mais dans ce cas, je ne sais pas comment faire pour qu'un trajet entre deux arrêts reste cohérent *et* qu'il reste distinctif de la ligne entière : Il y a bien des trajets de car/tram/métro distincts dans les deux sens, soit-ce à cause de rues en sens unique, ou des lignes qui bifurquent pour desservir des coins différents. Il faut donc garder bien séparé les deux trajets, afin qu'un nav' mixte ne propose pas un tour de manège autour d'un rond-point ou autour d'un quartier, là où pour ce faire, en réalité on doit descendre à la station suivante et prendre la rame / le car suivant dans l'autre direction. Dans d'autres pays, on voit sur osm des lignes de transport-en-commun représenté par des linges droites entre les haltes/stations. D'un point de vue topologique et pour les nav', ça se tient, puisque les points où on change de réseau, y sont, mais sur la carte ça fait désordre, quand une ligne de car traverse les blocs de maisons, ou traverse les Alpes en ligne droite là où il n'y a pas de tunnel. Je suis donc pour une représentation réaliste des lignes de transport en commun, mais je suis conscient que pour la ligne de car Montpellier-Rodez (officielle) ça pose des conflits, sans parler de lignes de car comme Berlin-Istanbul ou Paris-Alger (privées, je pense). Je n'ai pas la science infuse :-( Je vois déjà les foudres que ce commentaire va m'attirer, et rétracte la tête entre les épaules, mais faute de mieux je ne sais pas comment conserver la cohérence *et* la lisibilité par une autre manière, que de tracer un way concret. Amicalement (et pas sur de moi, du tout...) Gerhard
Re: [OSM-talk-fr] Rond-points coupés
Bonjour Pas de foudre pour ma part, je trouve ton commentaire très intéressant, car il montre bien la complexité de la choses et ne tombe pas l'écueil de la simplification abusive d'un problème complexe. Je ne pense pas non plus qu'il y ait de solution évidente. Il faut que le travail des participants reste simple, sinon comme cela a été dit personne n'ajoutera des lignes de transport, et à force de créer des relations par dessus les données de base on ne verra plus rien. D'un autre côté, je n'aime pas trop les affirmations du genre On n'est pas là pour simplifier le travail du concepteur de logiciel. D'accord, les développeurs peuvent toujours s'adapter, mais il ne faut pas que cela oblige à concevoir des usines à gaz non plus. Tout est dans l'équilibre. Pour finir, on atteint peut-être là aussi la limite de ce qu'on devrait cartographier dans osm. Peut être que tous nos chemins de rando, lignes de bus, etc, bref tout ce qui n'est pas physique ne devrait pas être ajouté directement dans la donnée brute d'osm, mais seulement sur des bases de données parallèles dédiées. ? Cela permettrait d'avoir un fond de carte physique qui reste simple, mais cela demande une fois encore plus de travail pour développer ces applications tierces. (Si la route n'est pas découpée en plusieurs ways, il est plus difficile de créer les routes et il faudrait alors travailler noeud par noeud ? Par exemple on définit une ligne comme passant par des noeuds, et plus comme une relation contenant des ways = morceaux de rues ?) Kimaidou Le 13 octobre 2009 12:43, g.d g...@wanadoo.fr a écrit : Bhen oui, dilemme dans la stratégie générale d'osm... :-( Utiliser les points seulement, ça deviendrait vite ingérable (invisible, et pas exploité), Saucissonner tout en petits morceaux et les fourrer dans des relations, ce serait certes systématique, mais tant que les éditeurs sont ce qu'ils sont, ça va finir dans un plateau de charcuterie à la fin d'un buffet froid : Plat de résistance : Île flottante de jambon cru dans saumure de cornichon, garnie d'anneaux de peau de tranches de salami :-( (Pour être conséquent avec soi-même, il faudrait que Tout osm du jour au lendemain bascule vers un système de relations imbriquées : Plus aucun tag sur des nodes ni sur des ways, qui eux deviendraient géopositionnement pur, et toute la description irait dans les relations... On aurait donc aussi des relations mono-nodes, et un système de super-hyper-duper-relations. Il deviendrait inconséquent, de noter un copyright dans chaque sous- élément ou sous-relation : On aurait une seule super-relation par année d'édition de cadastre, dans laquelle on fourre tous les tracés de cette année-là, l'IGN ne figurera qu'une seule fois : dans le tag d'une super-relation dans laquelle on engloutirait toutes ses bornes, voire même une seule relation pour tous les parkings de France et de Navarre, pareil pour les églises, mairies, peaks et autres. Ce deviendrait une approche inverse à l'actuelle. Peut-être ça viendra un jour, mais on n'en est pas là, pour l'instant c'est hybride). Revenir à l'api précédente : en aucun cas, Et superposer des ways à part pour les itinéraires en utilisant les mêmes nodes, ça avait été regardé comme indigne, ringard out over Mathusalem, si j'ai bon souvenir (Dans l'amas des spaghetti superposés, parfois il n'est pas aisé de sélectionner celui qu'on cherche, il est plus facile de dire, que c'est méthode ringard...) Donc, qu'est-ce qu'on fait ? Pour être in ? me grattant la tête... ...bhen, n'étant pas féru en relations, et par trouille de casser une relation, pour l'instant je pense continuer avec des ways superposés, pour les trajets/itinéraires. Dans le cas d'itinéraire rando que présente Fabien, si le randonneur doit emprunter le bitume de la route (comme c'est le cas dans des villages où il n'y a pas de trottoirs, et sur beaucoup de petites routes dehors), je pense que je collerai un way footway supplémentaire sur les nodes de la route, mais si les randonneurs passent sur le bas-côté (se sont faits un sentier à part), ou en ville sur des trottoirs, j'y mettrai probablement un footway avec des nodes séparés, et des nodes communs avec les highway voitures, là où ça les croise. Et pour le trajet d'un bus ou tram, je probablement mettrai un way à lui, pareillement : Si ça partage le même espace, sur les mêmes nodes que la route, mais si ça passe à côté sur voie séparée ou entre deux voies sens- uniques, sur des nodes distincts. Donc le rond-point resterait un rond-point fermé, avec collé dessus d'autres ways qui eux représentent le trajet du car, donc un way pour l'aller et un autre pour le retour, à chaque fois un way complet entre deux arrêts (solution que je préférerais), Ensuite, je pourrai imaginer de découper ce way-trajet en morceaux sur le rond-point, et fourrer les morceaux dans des relations distinctes, une pour l'aller, l'autre pour le retour. Mais dans
Re: [OSM-talk-fr] Rond-points coupés
2009/10/13 kimaidou kimai...@gmail.com: D'accord, les développeurs peuvent toujours s'adapter, mais il ne faut pas que cela oblige à concevoir des usines à gaz non plus. Parce que découper un quart de rond-point pour tracer son itinéraire, ça fait pas usine à gaz... (Si la route n'est pas découpée en plusieurs ways, il est plus difficile de créer les routes et il faudrait alors travailler noeud par noeud ? Par exemple on définit une ligne comme passant par des noeuds, et plus comme une relation contenant des ways = morceaux de rues ?) On se demande comment font tous les logiciels de navigation qui tiennent dans de si petites boites qu'on peut les coller sur le pare-brise d'une voiture. Pour revenir à la question de départ, je conseillerais à Christophe de recoller son rond-point en un morceau et de choisir lui-même de mettre ou pas celui-ci dans la relation route. Ceci en attendant qu'une solution moins destructive soit trouvée. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rond-points coupés
Le 13 octobre 2009 15:48, Pieren pier...@gmail.com a écrit : Pour revenir à la question de départ, je conseillerais à Christophe de recoller son rond-point en un morceau et de choisir lui-même de mettre ou pas celui-ci dans la relation route. Ceci en attendant qu'une solution moins destructive soit trouvée. Euh Son rond-point ? Parce qu'il n'y aurait qu'un seul rond-point découpé, en France ? J'ai des doutes. Le 27 juin dernier, ce sujet avait déjà été évoqué. J'avais proposé : est-ce difficile de rajouter le test que le way formant un roundabout est bien fermé ? Je fais cette proposition, car il n'est arrivé de rencontrer des cas où le tag junction=roundabout avait débordé sur une des routes y arrivant... ce qui faisait rond-point ouvert et linéaire. Et Pierre Mauduit avait répondu : Je ne sais pas si c'est une bonne idée : Il m'est arrivé de découper des rond-points afin de ne pas en inclure la totalité dans des descriptions de lignes de bus. Et il avait même fait un décompte. A l'époque, il y avait 796 rond-points ouverts, et 18118 fermés. Même si certains des 796 rond-point ouverts sont des erreurs (roundabout=true sur route), je pense que cela fait plus d'un rond-point découpé. Art. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Code Corine 324 «Forêt et vég étation arbustive en mutation»
Le 13 oct. 09 à 10:08, Christophe Merlet (RedFox) a écrit : Le mardi 13 octobre 2009 à 09:59 +0200, Christophe Merlet (RedFox) a écrit : Je ne suis pas trés chaud pour une nouvelle clé. .../... .../... une correspondance unique de chaque code CLC vers un équivalent OSM +1 Il nous faut des tags de correspondante exacte avec CLC, donc nécessité de nouveaux clés, je pense. ...et inversement, là où OSM est plus détaillé que CLC, garder les notres (residential, commercial...), mais trouver, sans ambiguïté, avec quelle rubrique CLC les assimiler, de façon à ce que ça restera traitable et comparable par un script, aller-et-retour. Autrement, toute communication automatisée entre OSM et CLC s'arrêterait-là, avec ce récent import, ce qui serait coumême dommage :-( On a déjà assez de confuses dans OSM, pas en rajouter. Oui, j'entends déjà dire si chaque pays fera son relevé d'utilisation des sols à sa sauce, et que pour chacun on fera des tags à part, où ça nous mène ? Un foisonnement pas possible de tags !?. Bhen OUI, si nécessaire, on devra le faire, si on ne veut pas passer à côté de ressources précieuses. Mais CLC est européen, pas seulement franco-français, déjà cela limite le foisonnement de tags sur le vieux continent... ;-) (Ouh... CLC couvre l'Europe - Est-ce que quelqu'un serait au courant d'autres communautés OSM qui de leur côté importent le landcover de leurs pays ? Ou est-ce que la France est précurseur en la matière ? Juste pour éviter, qu'on fasse notre sauce propre chacun dans not' coin, et qu'on harmonise les équivalences des tags ?). --- Dans mon coin, pour l'instant je ne touche pas aux polys de CLC non encore importés dans osm, déjà par manque de tags adéquats. Il y en a un paquet, au premier vu dans les 70 % du paysage manque à l'appel, je dirai, dans le coin où j'habite actuellement, et dans les 95 % dans le coin où j'envisage d'aménager. Pour la plupart, c'est du Forêt et végétation arbustive en mutation du Systèmes culturaux et parcellaires complexes et du Surfaces essentiellement agricoles, interrompues par des espaces naturels importants que je ne sais pas, comment les caser dans osm. Je suppose que la plupart des Forêts de conifères, Forêts de feuillus, Vignobles et les Prairies non importées dans mon coin soient plutôt des recoupements/superpositions/chevauchements avec des tracés pré-existants dans osm, ou, que dans CLC même, leurs polys se chevauchent de trop avec d'autres landuse CLC. Ces cas-là se laisseront résoudre à la main, je pense, avec un peu de connaissance du terrain. Mais quand il n'y a pas de tag équivalent dans osm, je donne ma langue au chat... Aussi, j'attends encore des outils pour pouvoir traiter ça comme il faut (ou d'apprendre, comment mieux me servir des outils existants) : Par exemple, le lien ouvrir dans josm sur osmose ne semble pas marcher sur mon mac, ça n'ouvre rien, je dois importer le fichier gpx (le fichier osm ne semble pas marcher, non plus). Mais, bon ça viendra... --- Déjà un grand merci pour l'astuce comment augmenter la ram de josm sur mac, j'avais désespérément tenté d'augmenter la ram de la version java, que tchi !, ça restait mordicus dans les cinquante, soixante mégas, avec des strange things may happen à tout bout de champs :-( Là où avec la version pour mac, et son fichier de prefs modifié à la main, ça marche feu de ziou, enfin trois gigas live pour josm, et autant en mem' virtuelle, ça fuuuse ! :-) --- Si quelqu'un pourrait résoudre l'histoire des tags landuse manquants, pour qu'on arrive à une équivalence travaillable ? De toute façon, une proposal de tag, quand il y a déjà dix ou vingt mille nodes et polys derrière, ça passe sans discussion, surtout que dans le cas présent, je pense que les personnes qui ont monté CLC ont déjà dû cramer une quantité respectable de matière grise hautement qualifiée, pour arriver à leur classement, donc il n'est ptèt' pas utile qu'on réinvente la roue juste pour rajouter une couche à la sauce d'OSM sur la Tour de Babylone... autant se tenir à leur classification... (si c'est admis). A la base, ça m'a l'air d'être une classification de type décimale, les descriptifs en langues locales n'interviendraient que par la suite, je pense. Amicalement Gerhard ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rond-points coupés
L'idée de bases séparées par réseau au premier abord sonne pas mal, ça probablement marcherait pour des réseaux comme ERDF ou SNCF, mais je ne vois pas, comment traiter puis recouper des réseaux qui par endroits partagent un même espace avec d'autres réseaux, et par endroits ont leur support propre à eux. Si on séparerait les BdD, je crains que leur superposition/croisement poserait plus de blêmes que leur séparation résoudrait, logiques, et matériels. On est des hobbyistes, je crains qu'on ne puisse pas se payer des lignes atlas réservées sans limite de bande passante. Je pense que tout ce qui est physique (géoréférencement, nature et caractéristiques des choses...) devrait rester ensemble dans une même et unique BdD. Y compris les trajets ou itinéraires des différents réseaux (sinon blême aux intersections). Ce qui est des infos supplémentaires (opérateur du carting, financier de la chaîne d'achats, url externe, n° de téléphone du gîte, liens vers des photos ou des tracks sonores, prix des carburants à la pompe, de la boîte de ravioli ou du kilo de patates, prénom de la fille de la cousine...) d'acc, ça devrait/pourrait aller dans des BdD à part. --- Le 13 oct. 09 à 14:30, kimaidou a écrit : Bonjour Pas de foudre pour ma part, je trouve ton commentaire très intéressant, car il montre bien la complexité de la choses et ne tombe pas l'écueil de la simplification abusive d'un problème complexe. Je ne pense pas non plus qu'il y ait de solution évidente. Il faut que le travail des participants reste simple, sinon comme cela a été dit personne n'ajoutera des lignes de transport, et à force de créer des relations par dessus les données de base on ne verra plus rien. D'un autre côté, je n'aime pas trop les affirmations du genre On n'est pas là pour simplifier le travail du concepteur de logiciel. D'accord, les développeurs peuvent toujours s'adapter, mais il ne faut pas que cela oblige à concevoir des usines à gaz non plus. Tout est dans l'équilibre. Pour finir, on atteint peut-être là aussi la limite de ce qu'on devrait cartographier dans osm. Peut être que tous nos chemins de rando, lignes de bus, etc, bref tout ce qui n'est pas physique ne devrait pas être ajouté directement dans la donnée brute d'osm, mais seulement sur des bases de données parallèles dédiées. ? Cela permettrait d'avoir un fond de carte physique qui reste simple, mais cela demande une fois encore plus de travail pour développer ces applications tierces. (Si la route n'est pas découpée en plusieurs ways, il est plus difficile de créer les routes et il faudrait alors travailler noeud par noeud ? Par exemple on définit une ligne comme passant par des noeuds, et plus comme une relation contenant des ways = morceaux de rues ?) Kimaidou Le 13 octobre 2009 12:43, g.d g...@wanadoo.fr a écrit : Bhen oui, dilemme dans la stratégie générale d'osm... :-( Utiliser les points seulement, ça deviendrait vite ingérable (invisible, et pas exploité), Saucissonner tout en petits morceaux et les fourrer dans des relations, ce serait certes systématique, mais tant que les éditeurs sont ce qu'ils sont, ça va finir dans un plateau de charcuterie à la fin d'un buffet froid : Plat de résistance : Île flottante de jambon cru dans saumure de cornichon, garnie d'anneaux de peau de tranches de salami :-( (Pour être conséquent avec soi-même, il faudrait que Tout osm du jour au lendemain bascule vers un système de relations imbriquées : Plus aucun tag sur des nodes ni sur des ways, qui eux deviendraient géopositionnement pur, et toute la description irait dans les relations... On aurait donc aussi des relations mono-nodes, et un système de super-hyper-duper-relations. Il deviendrait inconséquent, de noter un copyright dans chaque sous- élément ou sous-relation : On aurait une seule super-relation par année d'édition de cadastre, dans laquelle on fourre tous les tracés de cette année-là, l'IGN ne figurera qu'une seule fois : dans le tag d'une super-relation dans laquelle on engloutirait toutes ses bornes, voire même une seule relation pour tous les parkings de France et de Navarre, pareil pour les églises, mairies, peaks et autres. Ce deviendrait une approche inverse à l'actuelle. Peut-être ça viendra un jour, mais on n'en est pas là, pour l'instant c'est hybride). Revenir à l'api précédente : en aucun cas, Et superposer des ways à part pour les itinéraires en utilisant les mêmes nodes, ça avait été regardé comme indigne, ringard out over Mathusalem, si j'ai bon souvenir (Dans l'amas des spaghetti superposés, parfois il n'est pas aisé de sélectionner celui qu'on cherche, il est plus facile de dire, que c'est méthode ringard...) Donc, qu'est-ce qu'on fait ? Pour être in ? me grattant la tête... ...bhen, n'étant pas féru en relations, et par trouille de casser une relation, pour l'instant je pense continuer avec des ways superposés, pour les trajets/itinéraires. Dans le cas
Re: [OSM-talk-fr] Code Corine 324 «Forêt et v égétation arbustive en mutation»
+--On 13 octobre 2009 01:37:33 +0200 Jean-Christophe Haessig jean-christophe.haes...@dianosis.org wrote: | Bonsoir, | | J’ai vu qu’il avait plus ou moins été décidé de tagguer ces zones | en natural=wood;wood=mixed. La raison était que ces zones seraient des | forêts en devenir. à coté de chez mon père, il y a deux zones comme ça, je les ai taggées landuse=heath. -- Mathieu Arnold ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Comment trouver une bulle (était I mport polygones CLC manquants - Retour d'expérien ce.)
Etienne Chové wrote: Cedric Dumez-Viou a écrit : Bonjour, Je mappe dans la Sologne et j'ai un problème similaire. Une grande portion de foret ne s'est pas importée automatiquement au nord de Vierzon (http://osmose.openstreetmap.fr/clc/cgi- bin/index.py?layers=TB0Tzoom=15lat=47.25975lon=2.02811ch=111,112,121,122,123,124,131,132,133,141,142,311,411,412,421,422,423,511,512,521,522,523st=inauto,inmanu,out,outbad) et je cherche comment télécharger ce polygone. Il se trouve qu'il est très découpé et étendu et je n'arrive pas à trouver la bulle qui me permettrait d'y accéder. Clique sur Rechercher la bulle (dans le menu de gauche) puis sur un point de la carte... au bout de quelques secondes ta carte sera centrée sur la bulle si tout marche bien. Merci! C'est super pratique!!! J'ai pu uploader ma forêt. Je vais la couper en quelques morceaux pour faciliter l'édition. Je vais essayer de m'aligner sur les limites communales. Vous voyez mieux comme idée de découpe? Cedric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] zoom 18 et plus
Emilie Laffray a écrit : Peut être que le mont Saint Michel gagnerait a être mis sur la carte bestofosm.org C'est quand même assez impressionnant. J'en serai assez fier ! Il manque les alentours qui ne sont pas fini, notamment les water=tidal qui sont tout de même un des éléments de la réputation du site. Mais je n'ai pas assez de connaissance là-dessus. Si des gens un peu marins (bretons, quoique le mont soit en Normandie)... L'autre solution bien sur est d'avoir son propre serveur Mapnik. Ah ! quand je saurai faire... Un jour quelqu'un fera un mapOSMatic spécial pour les sites touristiques denses (quid de Disneyland ?)... Voire même un renderer pour les sites 3D. -- Vincent alias FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Code Corine 324 «Forêt et vég étation arbustive en mutation»
g.d a écrit : Le 13 oct. 09 à 10:08, Christophe Merlet (RedFox) a écrit : Le mardi 13 octobre 2009 à 09:59 +0200, Christophe Merlet (RedFox) a écrit : Je ne suis pas trés chaud pour une nouvelle clé. .../... Pourtant on l'a fait : landuse=orchard qui existait de façon discrète, sans référence dans le wiki (juste une allusion à un proposal ancien que je n'ai jamais retrouvé) Avec même une proposition de tag de second niveau. .../... une correspondance unique de chaque code CLC vers un équivalent OSM +1 Il nous faut des tags de correspondante exacte avec CLC, donc nécessité de nouveaux clés, je pense. Cependant le code CLC peut renvoyer à une combinaison OSM landuse=forest + wood=permanent ...et inversement, CLC 211, 212, 213 renvoient au landuse=farm. Seul le tag CLC:ref fait la distinction. Donc ne pas retirer trop vite les tags CLC (notamment pour les rizières) Nous étions peu concerné par le 212 (5 polygones) pour chercher jeu de tags distincts. Peut-être que les voisins trouveront, inventeront. Ça a déjà été une bagarre pour faire passer le landuse=orchard (qu'il faut faire passer au vote) j'imagine pour les rizières ce que ça va être, comment les italiens vont se heurter aux allemand(e)s. là où OSM est plus détaillé que CLC, garder les notres (residential, commercial...), mais trouver, sans ambiguïté, avec quelle rubrique CLC les assimiler, de façon à ce que ça restera traitable et comparable par un script, aller-et-retour. Autrement, toute communication automatisée entre OSM et CLC s'arrêterait-là, avec ce récent import, ce qui serait coumême dommage :-( On a déjà assez de confuses dans OSM, pas en rajouter. Oui, j'entends déjà dire si chaque pays fera son relevé d'utilisation des sols à sa sauce, et que pour chacun on fera des tags à part, où ça nous mène ? Un foisonnement pas possible de tags !?. Bhen OUI, si nécessaire, on devra le faire, si on ne veut pas passer à côté de ressources précieuses. Pieren a traduit la nomenclature en anglais pour favoriser la cohérence. Ou est-ce que la France est précurseur en la matière ? La France est précurseur, pour la méthodologie, pour le jeu de tag, pour les outils d'upload, Dans mon coin, pour l'instant je ne touche pas aux polys de CLC non encore importés dans osm, déjà par manque de tags adéquats. Il y en a un paquet, au premier vu dans les 70 % du paysage manque à l'appel, je dirai, dans le coin où j'habite actuellement, et dans les 95 % dans le coin où j'envisage d'aménager. Pour la plupart, c'est du Forêt et végétation arbustive en mutation du Systèmes culturaux et parcellaires complexes et du Surfaces essentiellement agricoles, interrompues par des espaces naturels importants que je ne sais pas, comment les caser dans osm. En les éclatant ! CLC, c'est du 1/100 000, on cartographie au 1/25 000 (voire moins sur le Mont Saint-Michel qui est pratiquement de la carto métrique) C'est là que celui qui connaît les 70% de trous d'un côté et les 95 % de l'autre est quelqu'un de précieux ! Pas d'autre moyen que la connaissance du terrain. Mais quand il n'y a pas de tag équivalent dans osm, je donne ma langue au chat... Aussi, j'attends encore des outils pour pouvoir traiter ça comme il faut (ou d'apprendre, comment mieux me servir des outils existants) : Par exemple, le lien ouvrir dans josm sur osmose ne semble pas marcher sur mon mac, ça n'ouvre rien, je dois importer le fichier gpx (le fichier osm ne semble pas marcher, non plus). Mais, bon ça viendra... As tu le plugin remoteControl dans JOSM ? Su mon mac, ça marche à merveille ! (sauf dédoublonage de points, et parfois affichage du polygone dans le rendu) Si quelqu'un pourrait résoudre l'histoire des tags landuse manquants, pour qu'on arrive à une équivalence travaillable ? Pas d'équivalence possible quand la classe CLC désigne des zones hétérogènes (système parcellaires complexe... ) Sauf à utiliser du landuse=farm sur de vastes zones comme le suggéraient certains sur le wiki (mais on cartographie alors au 1/1 000 000) De toute façon, une proposal de tag, quand il y a déjà dix ou vingt mille nodes et polys derrière, ça passe sans discussion, surtout que dans le cas présent, je pense que les personnes qui ont monté CLC ont déjà dû cramer une quantité respectable de matière grise hautement qualifiée, pour arriver à leur classement, donc il n'est ptèt' pas utile qu'on réinvente la roue juste pour rajouter une couche à la sauce d'OSM sur la Tour de Babylone... Sauf que les objectifs de CLC et d'OSM ne sont pas les mêmes. Des passerelles c'est bien, la même grille, c'est un peu juste... -- Vincent alias FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Google a encore frappé !
Forcément inutilisable avec OSM mais impressionnant quand même ! http://feedproxy.google.com/~r/blogspot/MKuf/~3/zgjSWl7SrD0/introducing-google-building-maker.html ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Code Corine 324 «Forêt et vég étation arbustive en mutation»
Vincent Pottier wrote: La France est précurseur, pour la méthodologie, pour le jeu de tag, pour les outils d'upload, Je confirme sur le cote précurseur sur pas mal de points. Il y a déjà eus des imports massifs précédemment, mais celui de Corine est de loin le plus structuré. On a fait un travail communautaire associant a la fois le cote technique, et le cote participation sur le vote. La peur de certaines personnes (Harry Wood entre autres) avec les imports massifs c'est que ça décourage les gens de participer. Je pense que grâce a l'outil qu'Etienne a crée, on arrive justement a résoudre ce problème. Sylvain avec Beta a joue un rôle très important car on a pu facilement évalué le travail. Il est prévu que j'écrive un post mortem pour l'import group, maintenant que le gros du travail a été fait. Les américains avec Tiger ont effectue initialement un excellent travail. Ils utilisent aussi un site pour corriger certains bugs. J'ai un lien qui traîne quelque part. Je vais le soumettre un peu plus tard. Les canadiens sous l'impulsion de Sam Vekemans avancent vite sur leur import mais il est difficile d'automatiser aussi facilement que l'on a fait car ils ont un import de route a faire. Les australiens ont récemment obtenus de nombreuses données libres provenant de leur gouvernement mais ils ont du mal a s'organiser pour le moment. De plus, le format de fichier qu'ils ont est un format raster au lieu de vectoriel pour un certain nombre de leurs fichiers ce qui ne simplifient pas leurs taches. Je suis en train de regarder comment utiliser un programme de GDal pour exploiter leurs données (ce qui me permettra de me faire la main sur un projet français avec le même outil). Les Japonais avancent aussi dans leurs coins petit a petit avec l'obtention de certaines bases de données gouvernementales. Il faut noter que bien qu'on soit précurseur sur certains points au niveau d'outil upload, nos outils sont peu utilises (le script que Yann a modifié n'est quasiment pas utilisé, la majorité des gens utilisant soit une version perl, soit une version PHP). Emilie Laffray signature.asc Description: OpenPGP digital signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
