Re: [OSM-talk-fr] Quels tags pour un repère géod ésique
Le mercredi 30 septembre 2009 23:17:12, tetramonium a écrit : > Bonjour > Je n'avait pas vu ce fil, mais j'avais suivi le précédent et récupéré > les fichiers préparés par Fred avec dans l'idée de poser proprement > quelques chateau d'eau. > J'ai donc extrait les infos sur ceux-ci et après quelques vérif j'en ai > rentré quelques-uns à la main mais en choississant soigneusement une > position correspondant à l'axe ou au centre et en vérifiant sur les > photos satellite l'existence récente de ces chateaux d'eau. > Je n'ai pas taggé les repères géodésique mais juste entré en plus du tag > water_tower, un tag source=IGN, Service de Géodésie et Nivellement: 2006 > (2006 vient des fiches pdf mais c'est pas forcément trés malin). > J'ai amélioré le rendement de mes vérifications et mis en place un truc > qui me permet d'éviter les doublons, et d'éviter aussi d'abimer ce que > certain ont déjà fait (entre autre certain ont créé des building à > partir du cadastre et dans ce cas j'ai juste recalé la position et > ajouté le tag source). > j'en ai entré environ 150, il y en a environ 500 entrés mais j'en ai > 5000 sous le coude, et avant de poursuivre, je me pose quelques questions > J'avais lu que les repères devraient être ses noeuds séparé des supports > et je trouve ça plutôt judicieux pour avoir une chance qu'il ne soient > pas déplacé d'une part, et peut-être aussi pour les supprimer et recréer > de temps en temps (je ne sais pas si c'est jouable mais si on > veut s'en servir de repère ce serait peut-être bien). > Ceci dit, est-ce qu'il ne serait judicieux que le support en plus du tag > source ign, ait aussi un tag ref qui permettrai facilement de retrouver > toutes les infos du repère? Où vaut-t-il mieux que j'ajoute un noeud > taggé comme l'avait proposé Marc Sibert: > * man_made=survey_point > * ref =numéro du site + "-" + lettre du repère, > * name=libellé du repère, > * source="©IGN 2009 dans le cadre de la cartographie réglementaire.", > * ele=altitude : quand elle est donnée, mais est-ce qu'il faut > l'altitude / ellipsoïde ou / géoïde ? > * url=lien vers la fiche IGN J'avais entrepris l'extraction des repères dans le secret espoir d'en extraire les châteaux d'eau, églises et d'autres choses... (mais sur tout pour les châteaux d'eau:] ) et pas réellement pour le repères eaux mêmes. J'avais fait quelques statistiques sur les mots les plus fréquents dans les descriptions. Pour ce qui est des tags le lien me semble superflu. Le ref décrit déjà la même chose (attention la lettre de repère n'est pas unique pour un site). Fred ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Quels tags pour un repère géod ésique
Bonjour Je n'avait pas vu ce fil, mais j'avais suivi le précédent et récupéré les fichiers préparés par Fred avec dans l'idée de poser proprement quelques chateau d'eau. J'ai donc extrait les infos sur ceux-ci et après quelques vérif j'en ai rentré quelques-uns à la main mais en choississant soigneusement une position correspondant à l'axe ou au centre et en vérifiant sur les photos satellite l'existence récente de ces chateaux d'eau. Je n'ai pas taggé les repères géodésique mais juste entré en plus du tag water_tower, un tag source=IGN, Service de Géodésie et Nivellement: 2006 (2006 vient des fiches pdf mais c'est pas forcément trés malin). J'ai amélioré le rendement de mes vérifications et mis en place un truc qui me permet d'éviter les doublons, et d'éviter aussi d'abimer ce que certain ont déjà fait (entre autre certain ont créé des building à partir du cadastre et dans ce cas j'ai juste recalé la position et ajouté le tag source). j'en ai entré environ 150, il y en a environ 500 entrés mais j'en ai 5000 sous le coude, et avant de poursuivre, je me pose quelques questions J'avais lu que les repères devraient être ses noeuds séparé des supports et je trouve ça plutôt judicieux pour avoir une chance qu'il ne soient pas déplacé d'une part, et peut-être aussi pour les supprimer et recréer de temps en temps (je ne sais pas si c'est jouable mais si on veut s'en servir de repère ce serait peut-être bien). Ceci dit, est-ce qu'il ne serait judicieux que le support en plus du tag source ign, ait aussi un tag ref qui permettrai facilement de retrouver toutes les infos du repère? Où vaut-t-il mieux que j'ajoute un noeud taggé comme l'avait proposé Marc Sibert: * man_made=survey_point * ref =numéro du site + "-" + lettre du repère, * name=libellé du repère, * source="©IGN 2009 dans le cadre de la cartographie réglementaire.", * ele=altitude : quand elle est donnée, mais est-ce qu'il faut l'altitude / ellipsoïde ou / géoïde ? * url=lien vers la fiche IGN A vous lire Un grand bravo en passant à tous les acteurs de l'import CLC! Christophe Marc SIBERT a écrit : > Pieren a écrit : >> 2009/9/12 Gilles Corlobé : >> >>> Bonjour, >>> Je crois que, en ce qui concerne la légalité, il y a 2 possibilités : >>> - soit le contributeur a relevé les éléments sur place à l'aide de son GPS >>> et a noté la référence du repère (mais ce n'est pas toujours facile parce >>> que certains sont "perchés" dans des endroits inaccessibles : j'en ai vu >>> certains sur le côté d'un pont, à plusieurs m au-dessus du sol), >>> - soit le contributeur a utilisé la fiche de l'IGN pour ajouter les >>> informations. >>> >>> Dans le premier cas, je ne vois pas ce qui pourrait être interdit, puisqu'il >>> s'agit d'informations relevées sur le terrain, et pas forcément celles de >>> l'IGN (écart de quelques m). >>> >>> Gilles >>> >> Relever un repère géodésique avec un GPS grand public n'a que peu >> d'intérêt : le repère n'a de sens que s'il est parfaitement positionné >> dans la base. Il peut éventuellement servir à mesurer la marge >> d'erreur de ton GPS si tu vas sur place. >> Et ce, d'autant plus que nous avons le droit d'importer ces repères >> dans OSM, voir le message de confirmation de l'IGN dans les archives: >> http://lists.openstreetmap.org/pipermail/talk-fr/2009-June/010306.html >> >> La demande a été faite par un certain Eric Sibert. Aucun lien de >> parenté avec Marc Sibert ? >> >> Pieren >> >> ___ >> >> > Si, le comble ! c'est mon frère et on s'est skypé hier sur le sujet mais > pas d'échange sur la légalité ! > -- > Marc > > ___ > 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] Re : Les arrêts de l'import de corine...
Art Penteur wrote: > buffer était un mot en l'air, sans savoir. l'idée de base est qu'avec > un délai à chaque changeset, on reste dans une logique "charge moyenne > constante", alors qu'avec de gros délais espacés, on laisse le temps à > des périodes de maintenance. Mais c'est une intuition basée sur aucun > fait. > > Quand on regarde les numéros de changeset, on voit que Corine représentait environ 10% des changesets a un moment donne. > > Dans la même veine "je parle sans savoir" : Est-ce que faire un tri > sur une clef primaire de latitude et secondaire de longitude n'aurait > pas minimisé le risque ? > Non rien a voir. La peur de Pieren est que quelqu'un arrive et qu'il efface les nodes qui sont nécessaires pour Corine. Un tri ne changerait rien a cet utilisateur. La preuve, il faut voir qu'un utilisateur sur le forum s'est plaint de voir apparaître des polygones de fermes sur son territoire de chasse :) > Comme ça on aurait été rempli la france en continu, par bandes de > latitude, et chaque nouveau polygone avait une forte probabilité de > s'appuyer sur des poylgones récemment créés, donc avec un faible > risque d'altération. > > Si tu regardes un peu l'import, tu vois qu'il y a un motif de ce genre qui apparaît. C'est lie au fait que les données n'étant pas filtrées on voit apparaître la manière dont les données sont stockées dans la base de donnée. Ca donne un motif proche d'une bounding box. Si on suit directement ton raisonnement potentiellement, oui on réduirait, mais ça ne change pas le risque de l'utilisateur lambda. De plus, ça rend le tri plus complexe car une bande de latitude peut être très large pour la France et on revient au point de départ de la discussion. Emilie Laffray > Art. > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr > signature.asc Description: OpenPGP digital signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Re : forum: dans landfill "bizarres" ...
De : "fo...@letuffe.org" À : talk-fr@openstreetmap.org Envoyé le : Mercredi, 30 Septembre 2009, 19h58mn 01s Objet : [OSM-talk-fr] forum: dans landfill "bizarres" ... Le message suivant : ## Bonjour, depuis quelques jour je vois apparaître des "délimitations" d'exploitations agricoles (landuse=farm) sur les fonds de cartes d'osm des zones où je mappe. Les contours de ces surfaces apparaissent en "couche supérieure" sur les fonds de cartes donc elles masquent certaines routes, ce qui est assez désagréable pour travailler avec potlatch!!! Est ce que c'est normal d'avoir ça (à mon avis non par ce qu'il y a écrit dessus "not in map feature") et sinon que faire pour y remédier ? @+, Philippe PS : pour chacun de ces contours il y a des champs "bizarres" tels que CLC:id, CLC:code, CLC:year et ces données sont signalées être saisies par CLCF06 ... a été posté sur le forum http://forum.letuffe.org/viewforum.php?f=3 Une réponse sur la liste directement n'est hélas pas transmise sur le forum, ce qui n'empeche pas une concertation avant réponse sur ce fil de discussion je me suis permis de vite repondre a ce post sur le forum en expliquant brievement le pourquoi du comment et qu il ne fallait pas toucher a ces nouveaux polygones en esperant que la personne n a fait aucune modif et n en fera pas Julien ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Les arrêts de l'import de corine...
Le 30 septembre 2009 19:27, Pieren a écrit : > 2009/9/30 Art Penteur : > > Je ne pense pas qu'il y ait de buffer. Lorsqu'on reçoit la réponse du > serveur, c'est que les données sont dans la base (avec leur id > définitif). buffer était un mot en l'air, sans savoir. l'idée de base est qu'avec un délai à chaque changeset, on reste dans une logique "charge moyenne constante", alors qu'avec de gros délais espacés, on laisse le temps à des périodes de maintenance. Mais c'est une intuition basée sur aucun fait. > [...] Mais en même temps, l'import durera moins longtemps et on > réduit les risques d'altérations des données pendant le temps de > l'import (ma peur vient toujours du risque que des nodes soient > supprimés alors que tous les polygones ne sont pas encore là). Dans la même veine "je parle sans savoir" : Est-ce que faire un tri sur une clef primaire de latitude et secondaire de longitude n'aurait pas minimisé le risque ? Comme ça on aurait été rempli la france en continu, par bandes de latitude, et chaque nouveau polygone avait une forte probabilité de s'appuyer sur des poylgones récemment créés, donc avec un faible risque d'altération. Art. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] forum: dans landfill "bizarres" ...
Le message suivant : ## Bonjour, depuis quelques jour je vois apparaître des "délimitations" d'exploitations agricoles (landuse=farm) sur les fonds de cartes d'osm des zones où je mappe. Les contours de ces surfaces apparaissent en "couche supérieure" sur les fonds de cartes donc elles masquent certaines routes, ce qui est assez désagréable pour travailler avec potlatch!!! Est ce que c'est normal d'avoir ça (à mon avis non par ce qu'il y a écrit dessus "not in map feature") et sinon que faire pour y remédier ? @+, Philippe PS : pour chacun de ces contours il y a des champs "bizarres" tels que CLC:id, CLC:code, CLC:year et ces données sont signalées être saisies par CLCF06 ... a été posté sur le forum http://forum.letuffe.org/viewforum.php?f=3 Une réponse sur la liste directement n'est hélas pas transmise sur le forum, ce qui n'empeche pas une concertation avant réponse sur ce fil de discussion -- Tout commentaire sur ce message peut être demandé à sylvainaletuffe.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Re : Statistiques sur les donnees Corine
De : Bastien JACQUET Est-il possible (simple ?) de ne calculer dans un premier temps uniquement (nb habitant)/(longueur rue en zone landuse residential) Meme si cela peut etre haut pour des villes dense, je pense que l'ordre de grandeur n'est pas du tout le meme entre villes mappée et non mappé (meme dense), non ? Et pour mettre tout le monde d accord est ce qu il ne serait pas possible de definir un petit echantillon de landuse residential representatifs de ce qu on peut trouver en france et de faire tourner un ou deux algorithmes dessus pour voir concretement ce que ça donne ? Dans tous les gens de la mailing list il y a certainement moyen que quelqu un connaisse des villes de plus ou moins grandes tailles plus ou moins bien mappées qui pourraient servir aux tests. On pourrait par exemple definir deux axes arbitraires : _ Taille de la ville en nombre d habitant ( 100,1000, 1, 10, 100 et plus) _ geographie de l endroit : plaine, montagne et un axe juge subjectivement : _ Avancee du mapping : faible, moyenne, forte En combinant les trois cela voudrait dire trouver 30-40 examples max et appliquer l algo. On verrait vite si on obtient des valeurs tres differentes d un cas a l autre en rapport avec l avancee et donc exploitable ou si elles sont trop proches pour etre reprentatives. Dans le cas ou l algorithme s avererait "juste" sur l echantillon il n y aurait ensuite plus qu a definir des seuil etablisant si le mapping est faible moyen ou fort pour chaque combinaison taille/geographie et l appliquer a l ensemble des landuse de France pour avoir une pseudo estimation de l avance des mappings Julien ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Re : Re : Les arrêts de l'i mport de corine...
De : Pieren Je ne pense pas qu'il y ait de buffer. Lorsqu'on reçoit la réponse du serveur, c'est que les données sont dans la base (avec leur id définitif). Par contre, c'est vrai que ça réduit d'autant la capacité pour les autres. Mais en même temps, l'import durera moins longtemps et on réduit les risques d'altérations des données pendant le temps de l'import (ma peur vient toujours du risque que des nodes soient supprimés alors que tous les polygones ne sont pas encore là). C'est toujours un choix délicat. J'avais posé la question sur la liste des imports mais personne n'a pu me donner de réponse. Par contre, concernant la taille des changesets, le nombre de 500 éléments semblait le meilleur compromis dans un autre retour d'expérience d'un précédent import. Actuellement on dirait qu il y a un import toutes les 30 secondes, OSM etant un projet d envergure mondiale on peut supposer qu il y a en permanence des gens qui font des upload, je ne sais pas de quelles tailles mais je ne pense pas que les 500 points de Corinne soient "enormes" en comparaison ( corrigez moi si je me trompe ). Se serait inquietant si cela suffisait a ecrouler l infrastructure d OSM Julien ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Statistiques sur les donnees Corine
Bonjour, Est-il possible (simple ?) de ne calculer dans un premier temps uniquement (nb habitant)/(longueur rue en zone landuse residential) Meme si cela peut etre haut pour des villes dense, je pense que l'ordre de grandeur n'est pas du tout le meme entre villes mappée et non mappé (meme dense), non ? Bastien Jacquet 2009/9/30 Emilie Laffray > Bonjour, > > Il n'a jamais été question d'avoir une formule magique. Le but du jeu est > d'essayer de créer un indicateur permettant d'indiquer la ou il y a > potentiellement du travail a faire. Cette valeur n'est pas une valeur qu'on > prendra comme référence absolue car comme tu l'as indique et comme je l'ai > indique précédemment aussi, il y a plein de facteurs qui font que c'est > impossible d'avoir quelque chose qui fonctionne parfaitement. Si je > mentionne l'idée d'un doctorat dans de précédents emails, c'est que je pense > qu'il y a matière a travailler pendant au moins quelques années pour avoir > une idée de ce qu'on veut. > Maintenant, tu parles de différence de terrain, et de facteurs socio > économiques; je suis la première a admettre cela. Ça joue évidemment sur le > nombre de route et leur densités. > Tu parles du type des routes, chose que j'ai soigneusement ignore dans mes > emails a part pour répondre que je ne voyais pas l'intérêt plus que ça d'en > tenir compte. Je souhaite vraiment ignorer cela actuellement car ça > n'apporte strictement rien a mes yeux. De plus, les considérations > touristes/locaux ne m'intéressent vraiment pas. Ce qui importe a mes yeux > c'est de pouvoir donner une idée a quel point une zone est développée. > Le postulat de base est simple: il y a des routes la ou les humains ont > besoin d'aller. Dans notre monde actuel, on se déplace de bâtiments en > bâtiments. Donc plus il y a de gens plus il y a de routes globalement > jusqu'à un point qui est une densité limite. Dans ce scénario il y a > toujours des exceptions comme des vallées en montagne ou la surface peut > être grande, la population faible et la densité ponctuelle faramineuse et > les villes plus étendues. > La population et indirectement la densité (obtenue via la surface, puisque > je parle en terme de commune, voire après réflexion en termes de landuse > residential) est un facteur de correction que l'on peut appliquer a une > valeur théorique. Au lieu de compliquer tout, cela permet de simplifier les > choses pour peu que tu aies une modélisation réaliste du facteur de > correction de la densité. Comme je le signalais précédemment, au bout d'un > moment, on a un facteur de correction qui a une asymptote: la relation n'est > plus linéaire. > Cela peut paraître complique et complètement farfelu. Ça ne l'est pas. Pour > un projet pour mon emploi, j'ai du calcule la surface des villes > australiennes. L'Australie est un pays passionnant d'un point de vue > géographique avec une très grande richesse géographique d'un point de vue > relief, système naturel, et population. Je n'avais pas de statistiques aussi > détaillées que pour la France et on arrivait a une surface correcte (marge > d'erreur raisonnable ) dans plus de 85% des cas. Il y a forcement des cas > particuliers, mais le chiffre donne est pour toute l'Australie y compris la > Tasmanie. Et pourtant, on ne peut pas dire que l'Australie soit un pays > uniforme. Ce chiffre a été obtenu en utilisant une courbe de distribution > des densités et calculer de manière empirique. Pourtant, cette valeur prise > avec le doigt mouille au vent a été efficace (enfin pas tant que ça mais > bon). > De retour a la France, dans le cas présent, j'ai accès a un pays que je > connais, ou j'ai des restes de cours d'urbanisme, et ou j'ai accès a des > statistiques que je peux utiliser sans soucis de droits commerciaux puisque > c'est dans un but non lucratif et juste un indicateur. Je ne vois pas > pourquoi certaines généralités ne pourront être déduites. > Tu signales que la Bretagne a probablement une densité de route supérieure > a d'autres régions. Tant mieux, dans les zones ou c'est déjà bien rempli, ça > apparaîtra comme déjà bien fini. Dans les zones ou il n'y a rien ça > apparaîtra toujours comme quoi il n'y a strictement rien. > Initialement, j'avais pense travaille au niveau de la commune, surtout > celles ou j'avais les polygones pour des raisons très simples de calcul. > Après avoir échangé un certain nombre d'emails que tu as pu voir, il est > devenu clair qu'il faut séparer la commune en deux niveaux: la surface du > bâti et la surface de la limite administrative de la commune. Clairement, le > second cas sera plus sensible aux potentiels dérives régionales que tu > signales; le premier cas lui sera moins sensible, habitat disperse ou non. > Le système de calcul n'est pas trivial, c'est évident mais je ne pense pas > que ça soit si difficile de produire un chiffre qui donne une indication. Ça > sera ce que le papier ph est au ph mètre. L'un donne une indication du ph > entre très acide, acide, neutre, basique,
Re: [OSM-talk-fr] Re : Les arrêts de l'import de corine...
2009/9/30 Art Penteur : Je ne pense pas qu'il y ait de buffer. Lorsqu'on reçoit la réponse du serveur, c'est que les données sont dans la base (avec leur id définitif). Par contre, c'est vrai que ça réduit d'autant la capacité pour les autres. Mais en même temps, l'import durera moins longtemps et on réduit les risques d'altérations des données pendant le temps de l'import (ma peur vient toujours du risque que des nodes soient supprimés alors que tous les polygones ne sont pas encore là). C'est toujours un choix délicat. J'avais posé la question sur la liste des imports mais personne n'a pu me donner de réponse. Par contre, concernant la taille des changesets, le nombre de 500 éléments semblait le meilleur compromis dans un autre retour d'expérience d'un précédent import. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Les arrêts de l'import de corine...
Le 30 septembre 2009 18:47, Pieren a écrit : > 2009/9/30 THEVENON Julien > > [...] j'ai supprimé un délai artificiel de 15 > secondes entre changesets dans le script d'upload. Je pensais soulager > le serveur et minimiser les risques d'erreurs grâce à ça mais comme on > a quand même les erreurs, autant y aller à donf... Ce délai n'a pas l'air de réduire les erreurs, mais il réduisait peut-être la latence pour les autres mappeurs ? Notion qui n'est pas facile à mesurer, ça dépend d'autres facteurs. Pour soulager le serveur, le bon délai ne serait-il pas, plutôt, du type un gros délai tous les N changeset, pour laisser au serveur le temps de vider ses buffer, de mettre à jour des index, de nettoyer ses pools de thread, que sait-je ? Par exemple 5 minutes tous les quart d'heures, ou 10 minutes tous les 60 changeset ? (chiffres pifométriques à adapter). Art. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Les arrêts de l'import de corine...
2009/9/30 THEVENON Julien Comme on peut le voir, il y a une légère amélioration de la performance. C'est parce que j'ai supprimé un délai artificiel de 15 secondes entre changesets dans le script d'upload. Je pensais soulager le serveur et minimiser les risques d'erreurs grâce à ça mais comme on a quand même les erreurs, autant y aller à donf... on verra bien si ça augmente le nombre d'arrêts ou pas. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Re : Les arrêts de l'import d e corine...
De : Etienne Chové ...sont visibles sur http://osmose.openstreetmap.fr/map/cgi-bin/clc.py Les nouvelles stats sont sympas ( d ailleurs c est bien mieux d avoir le nombre de changeset par minute plutot que par seconde pour le graphe sur une semaine ;-) ) ! correlees avec le status de l import par Pieren http://wiki.openstreetmap.org/wiki/WikiProject_France/Corine_Land_Cover#Historique_de_l.27import ca permet de bien suivre la progression et les raisons des arrets Julien ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Les arrêts de l'import de corine ...
...sont visibles sur http://osmose.openstreetmap.fr/map/cgi-bin/clc.py -- Etienne ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] JOSM : comment rattacher la boîte des calques ?
Ah bah oui. Forcément. Merci ! (On se sent bête des fois :) ) Le 30 septembre 2009 17:02, Julien D. > a écrit : > Il suffit de la fermer avec la croix :) > > 2009/9/30 Jeremy G > >> Bonjour à tous, >> >> J'ai détaché (comprendre : "mis en flottant") la boîte de dialogue des >> calques dans JOSM, et je ne trouve pas la commande pour la "rattacher"... :p >> >> Une idée ? Merci ! >> >> Jérémy >> ___ >> 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
Re: [OSM-talk-fr] JOSM : comment rattacher la boîte des calques ?
Il suffit de la fermer avec la croix :) 2009/9/30 Jeremy G > Bonjour à tous, > > J'ai détaché (comprendre : "mis en flottant") la boîte de dialogue des > calques dans JOSM, et je ne trouve pas la commande pour la "rattacher"... :p > > Une idée ? Merci ! > > Jérémy > ___ > 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] JOSM : comment rattacher la boîte des calques ?
Bonjour à tous, J'ai détaché (comprendre : "mis en flottant") la boîte de dialogue des calques dans JOSM, et je ne trouve pas la commande pour la "rattacher"... :p Une idée ? Merci ! Jérémy ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Besoin d'aide sur ma première rela tion
Ta relation semble bien faite. Cependant ce type de relation n'est pas vraiment prévu pour cet usage : il n'y a pas besoin de relation pour regrouper le nom ou la ref d'une même rue. Les relations sont sensées décrire des associations non physiques entre *différents* ways. http://wiki.openstreetmap.org/wiki/Talk:Relation:route#Why_roads.3F Un logiciel de rendu peut très bien faire ce travail de recollage pour afficher les noms des rues. Car si on va dans cette logique, quasiment toutes les rues du monde auront besoin de cette relation (car sont découpées), alors qu'on peux très bien s'en passer. D'un autre côté, ça me semble aussi plus propre de ne nommer/ref qu'une fois une rue et d'associer tous les morceaux à ce nom/ref. De toutes façon, je crois qu'aucun moteur de rendu ne gère l'affichage de nom utilisant cette relation. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Besoin d'aide sur ma première re lation
Bonjour à tous, J'essaie de faire ma première relation puisqu'un certain nombre de routes que j'ai taggées gagneraient grandement à l'être. J'ai donc pris une petite route séparée en trois ways avec des propriétés différentes (il y a une piste cyclable sur une portion seulement de la route). J'ai suivi la doc mais maintenant dans le rendu Mapnik, le nom de ma route n'apparaît plus. On ne tagge pas pour le rendu, mais quand même... Quelqu'un saurait-il me dire où je me suis vautré en taggant ma première relation ? http://osm.org/go/erGu1e5z9- Merci d'avance Thomas ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Statistiques sur les donnees Corine
Bonjour, Il n'a jamais été question d'avoir une formule magique. Le but du jeu est d'essayer de créer un indicateur permettant d'indiquer la ou il y a potentiellement du travail a faire. Cette valeur n'est pas une valeur qu'on prendra comme référence absolue car comme tu l'as indique et comme je l'ai indique précédemment aussi, il y a plein de facteurs qui font que c'est impossible d'avoir quelque chose qui fonctionne parfaitement. Si je mentionne l'idée d'un doctorat dans de précédents emails, c'est que je pense qu'il y a matière a travailler pendant au moins quelques années pour avoir une idée de ce qu'on veut. Maintenant, tu parles de différence de terrain, et de facteurs socio économiques; je suis la première a admettre cela. Ça joue évidemment sur le nombre de route et leur densités. Tu parles du type des routes, chose que j'ai soigneusement ignore dans mes emails a part pour répondre que je ne voyais pas l'intérêt plus que ça d'en tenir compte. Je souhaite vraiment ignorer cela actuellement car ça n'apporte strictement rien a mes yeux. De plus, les considérations touristes/locaux ne m'intéressent vraiment pas. Ce qui importe a mes yeux c'est de pouvoir donner une idée a quel point une zone est développée. Le postulat de base est simple: il y a des routes la ou les humains ont besoin d'aller. Dans notre monde actuel, on se déplace de bâtiments en bâtiments. Donc plus il y a de gens plus il y a de routes globalement jusqu'à un point qui est une densité limite. Dans ce scénario il y a toujours des exceptions comme des vallées en montagne ou la surface peut être grande, la population faible et la densité ponctuelle faramineuse et les villes plus étendues. La population et indirectement la densité (obtenue via la surface, puisque je parle en terme de commune, voire après réflexion en termes de landuse residential) est un facteur de correction que l'on peut appliquer a une valeur théorique. Au lieu de compliquer tout, cela permet de simplifier les choses pour peu que tu aies une modélisation réaliste du facteur de correction de la densité. Comme je le signalais précédemment, au bout d'un moment, on a un facteur de correction qui a une asymptote: la relation n'est plus linéaire. Cela peut paraître complique et complètement farfelu. Ça ne l'est pas. Pour un projet pour mon emploi, j'ai du calcule la surface des villes australiennes. L'Australie est un pays passionnant d'un point de vue géographique avec une très grande richesse géographique d'un point de vue relief, système naturel, et population. Je n'avais pas de statistiques aussi détaillées que pour la France et on arrivait a une surface correcte (marge d'erreur raisonnable ) dans plus de 85% des cas. Il y a forcement des cas particuliers, mais le chiffre donne est pour toute l'Australie y compris la Tasmanie. Et pourtant, on ne peut pas dire que l'Australie soit un pays uniforme. Ce chiffre a été obtenu en utilisant une courbe de distribution des densités et calculer de manière empirique. Pourtant, cette valeur prise avec le doigt mouille au vent a été efficace (enfin pas tant que ça mais bon). De retour a la France, dans le cas présent, j'ai accès a un pays que je connais, ou j'ai des restes de cours d'urbanisme, et ou j'ai accès a des statistiques que je peux utiliser sans soucis de droits commerciaux puisque c'est dans un but non lucratif et juste un indicateur. Je ne vois pas pourquoi certaines généralités ne pourront être déduites. Tu signales que la Bretagne a probablement une densité de route supérieure a d'autres régions. Tant mieux, dans les zones ou c'est déjà bien rempli, ça apparaîtra comme déjà bien fini. Dans les zones ou il n'y a rien ça apparaîtra toujours comme quoi il n'y a strictement rien. Initialement, j'avais pense travaille au niveau de la commune, surtout celles ou j'avais les polygones pour des raisons très simples de calcul. Après avoir échangé un certain nombre d'emails que tu as pu voir, il est devenu clair qu'il faut séparer la commune en deux niveaux: la surface du bâti et la surface de la limite administrative de la commune. Clairement, le second cas sera plus sensible aux potentiels dérives régionales que tu signales; le premier cas lui sera moins sensible, habitat disperse ou non. Le système de calcul n'est pas trivial, c'est évident mais je ne pense pas que ça soit si difficile de produire un chiffre qui donne une indication. Ça sera ce que le papier ph est au ph mètre. L'un donne une indication du ph entre très acide, acide, neutre, basique, très basique, tandis que l'autre donne une mesure complètement scientifique. L'un prête a interprétation et a précaution, l'autre non. L'autre point en faveur de la rationalisation sur les landuse residentials c'est les plans d'urbanismes modernes. Il me semble a moins que je me trompes que depuis la seconde guerre mondiale, la France est globalement uniforme dans les plans d'urbanisation. Je crois que la Bretagne n'échappe pas a la rurbanisation et aux phénomènes des lotissements
Re: [OSM-talk-fr] Statistiques sur les donnees Corine
Le 29 sept. 09 à 22:40, Emilie Laffray a écrit : Bonsoir, .../... je compte produire quelques statistiques .../... une fois que Corine sera importée. Pour le moment, je compte produire principalement une statistique car elle me tient a cœur: - Nombre et noms des polygones landuse residentials qui n'ont pas de villes proches d'elles. .../... de manière heuristique a partir de quelques villes a peu près complètes. .../... je veux juste soumettre l'idée de base. Toutes les idées sont bien sures (C) :P Bhen l'idée me paraît trèès bonne : Ça donnera une idée, à quels endroits osm manque d'être complété. (Ça donnerait aussi des infos sur des commerces manquants, du transport en commun manquant, de la couverture médicale manquante ...et inversement... hihi, on viendrait à la question "est-ce que ça manque sur OSM seulement ?", ou "est-ce que ça manque d'abord sur place, dans la réalité ?") --- Au passage, en poussant "un tout petit peu plus loin", ;-) , cela pourrait devenir un sacré outil pour la gestion du pays, ça pourrait donner des infos d'urba, pourait donner lieu à une étude sur l'urba elle-même... Mais, euh, d'abord, en pratique, d'une part on a des communes "composées" avec plusieurs zones habitées et du vert entre, sans qu'on ait les chiffres de populo pour chacune des composantes, d'autre part y a des villes qui sont "pleines" et poussent en hauteur... (en un premier temps "exclure" du calcul les communes où il y a plusieurs zones residential ? Juste pour se faire la main, mettre au point le premier algorithme de façon le moins faussée que possible ?). Pour en tirer des infos d'urba, ça ferait toute une arborescence aller- et-retour de critères qui devront s'ajuster eux-mêmes de façon automatisée, une sorte "d'intelligence artificielle", se "auto-pondérer" entre le nombre des rues, leur longueur, leur nombres de junctions au kilomètre linéaire, au kilomètre carré, leur curvicité, et je ne sais pas quoi encore, si on ne veut pas fausser la machine par trop de subjectivité. Donc ça serait à commencer dans un "bac à sable", une sandbox, juste pour voir ce que ça donne. Par exemple, chaque type de réseau de communication devrait intervenir seulement à partir des son "échelle" Aussi, le nombre de ways au km2, qui se touchent (ou qui ne se touchent pas) peut être intéressant, mais serait à pondérer par d'autres critères : Quand il y a peu qui se touchent, c'est plutôt du "au carré" (Manhattan, une cité années 50,60, ou un camp romain), et quand il y a beaucoup, ça pourrait être du "radio- concentrique" (Nouvelles villes, Karlsruhe, ou un village médiéval issu d'une "motte" féodale ou circulade). ...et le développement très divers dû aux contraintes externes, ennemi en face (Tarascon et Beaucaire, Brisach et Neuf-Brisach, par la topo, villes en forte pente donc en terrasses, villes sur butte promontoire dans un marais... :-), On pourrait ainsi distinguer les noyaux des autres zones historiquement différentes ou à usage autre... (et donc, juste pour le côté "urba", ptèt' qu'on pourrait se passer du nombre d'habitants, aussi bizarre que ça peut sembler, et se baser uniquement sur les coeffs de géométrie ? (La "city" de Londres a une densité d'habitants extrêmement faible...) ), "re-croiser" des coeffs topographiques (longueur et nombres des choses par hectare, par km2, par "e" km2 etc...) avec des coeffs topologiques (platitudes, courbures, singularités...), et les typologies... :-) ça pourrait faire tout un "jeu" de coeffs de coeffs de coeffs, à hérisser les chaveux, nécessiterait une rigueur incroyable pour séparer les divers aspects des choses, mais ça pourrait être trèees intéressant... Bon, là, je rêve debout, j'en suis bien conscient :-) --- Mais, dans le passé j'avais mis le doigt sur des camps romains, et sur des châteaux et des villages, retrouvé une voie romaine, qui aujourd'hui ont disparu de la surface de la terre (absolument plus rien à voir, que foret, broussaille ou champs à perte de vue), "simplement" en regardant les lignes et courbes des parcelles et les axes des chemins sur le cadastre napoléonien, avec à côté une carte topo, pour voir si peut-être ces bizarreries étaient dû à des incidences du terrain, et si oui ou non ces tracés pouvaient être vestige d'urbanisation :-) . Je pense donc, par analogie, qu'il pourrait être possible de tirer des infos d'urba intéressantes, "juste" sur base de la géométrie sur osm vectorielle... ;-) --- Mais comme je disais plus haut, c'est un peu du domaine du rêve, et serait un challenge énorme... ...et aussi, nul ne sait à quoi sera employé un tel outil, s'il existait : Dans le "Bon Sens" pour le bien de la population, ou pour mieux vendre des frigos solaires aux derniers esquimaux en igloo, à des raisons stratégiques, ou encore pour "économiser" des fonctions des services publics :-( (?). Une fois un outil crée, on ne contrôle
Re: [OSM-talk-fr] Gonflage
D'une manière plus générale, je me demande s'il ne faudrait pas organiser tags des services autour de la voiture. Récemment, j'ai voyagé à Madagascar avec une voiture toute pourrie. On était sur la route nationale la plus fréquentée du pays. On est assez vite amené à se poser des questions et dont on souhaiterait voir la réponse sous une forme ou une autre sur une carte routière: - où est la prochaine station? (amenity=fuel OK) - où est le prochain garage? - où est le prochain garage avec réparation des pneus? - où est le prochain endroit pour gonfler les pneus? - où est le prochain garage avec spécialité électrique? Pour les 4 dernières questions, je ne sais actuellement pas comment taguer ça. Accessoirement, les réponses pour les questions du début, c'est environ tous les 100 km. Et pour la spécialité électricité, il faut bien chercher... Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Gonflage
Ouiich ! Et svp prévoir d'indiquer la pression max' disponible, puisque pas mal de véhicules nécessitent des pressions de 3,5 bars, 4 bars, voire 6 bars parfois, donc si on se pointe "sous-gonflé" avec un tel engin à une station de supermarché réglée sur max 2,8 bars, ou sur une station autoroute limitée à 3,3 bars c'est l'inverse qui se passe : C'est le pneu sous-gonflé avec ses 3,6 bars, qui se déglonfe encore plus et remplit la cuve du compresseur, et là, t'est vraiment à plat, sur les jantes, plus que les yeux pour pleurer, à pied, on a "gagné sa journée"... :-( (et attendre qu'un autre engin de la sorte veuille bien passer par-là, et veuille bien s'arrêter, pour te filer un peu de pression (on a des tuyaux exprès pour ça) de chacun de ses pneus, ou, le "luxe total", de te brancher sur son compresseur 'pro' embarqué... J' avais acheté un, de ces compresseurs "six bars garantis" 220, 24 et 12, bas prix, pour découvrir qu'à 3,2 il chauffait au point de fondre, pchitt, -> poubelle...). Aussi, certaines stations sur autoroute, quoique souvent elles fournissent dans les 4,2 voire 5 bars, sont inaccessibles aux gros gabarits : Pour y arriver, ça demande des manœuvres pô possibles, et en manœuvrant on a peur d'écraser le pépé qui cherche son sandwich, ou la mémé, ou sa mercedes (quoique, les clk ou des Lambo sont tellement basses, que ça peut passer sous l'arrière de la caisse,sans rayures, si la caisse a encore un cul à l'ancienne, haut...). Et avec des attelages quarante-deux tonnes, 'faut dételer pour y arriver, donc durant un certain temps, sans en avoir l'intention, on est obligé de bloquer tout le passage "droit" de la Station... :-( Derrière, ça râle, à juste raison, mais comment faire autrement ? Un tag pour décrire une station de gonflage, avec des amendements pour ses détails d'utilisabilité, serait vraiment utile aux routiers/routards/campeurs, je pense... Amicalement Gerhard --- Le 30 sept. 09 à 10:54, Etienne Chové a écrit : > > Pieren a écrit : >> 2009/9/30 Jean-Francois Nifenecker > >: >>> Bonjour, >>> >>> je ne sais si cette question a déjà été posée ici... >> >> Jamais... >> >>> Comment étiqueter une station de gonflage comme on en trouve aux >>> entrées >>> d'autoroutes, par exemple ? >> >> highway=services (attention au 's') + inflation_station=yes ? >> ou amenity=tire_inflation_station ? >> ou amenity=fuel + inflation_station=yes si combiné avec une station >> essence ? >> >> Il faudrait aussi regarder avec tagwatch si le mot 'inflation' est >> déjà utilisé. > > On ne trouve pas de clé avec *inflate*. > > Cependant on trouve : > http://osmdoc.com/en/tag/amenity/air%20to%20inflate%20wheels > http://osmdoc.com/en/tag/amenity/air%20to%20inflate > http://osmdoc.com/en/tag/amenity/bicycle_tire_inflator > http://osmdoc.com/en/tag/amenity/air_fill > http://osmdoc.com/en/tag/amenity/bicycle%20air > http://osmdoc.com/en/tag/air_fill/yes > > Mais ces infos n'apparaissent respectivement que 2, 1, 1, 6, 5, 2 > fois. > > C'est peut être l'occasion de proposer une nouvelle feature ? > > -- > Etienne > > ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Annonce] Conférence-débat " La Terre vue du Web", le 7 octobre 2009
Joaquin Keller a écrit : > Bonjour, > Les contributeurs et fans d'open street map auront leur mot à dire... > A bientôt, > -- Joaquin > _ Quelques réalisations perso ici : http://wiki.openstreetmap.org/wiki/User:FrViPofm/BestOf (Bon ce sera encore mieux après l'import Corine et remise en place des landuse's et autres) -- Vincent alias FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Gonflage
Pieren a écrit : > 2009/9/30 Jean-Francois Nifenecker : >> Bonjour, >> >> je ne sais si cette question a déjà été posée ici... > > Jamais... > >> Comment étiqueter une station de gonflage comme on en trouve aux entrées >> d'autoroutes, par exemple ? > > highway=services (attention au 's') + inflation_station=yes ? > ou amenity=tire_inflation_station ? > ou amenity=fuel + inflation_station=yes si combiné avec une station essence ? > > Il faudrait aussi regarder avec tagwatch si le mot 'inflation' est déjà > utilisé. On ne trouve pas de clé avec *inflate*. Cependant on trouve : http://osmdoc.com/en/tag/amenity/air%20to%20inflate%20wheels http://osmdoc.com/en/tag/amenity/air%20to%20inflate http://osmdoc.com/en/tag/amenity/bicycle_tire_inflator http://osmdoc.com/en/tag/amenity/air_fill http://osmdoc.com/en/tag/amenity/bicycle%20air http://osmdoc.com/en/tag/air_fill/yes Mais ces infos n'apparaissent respectivement que 2, 1, 1, 6, 5, 2 fois. C'est peut être l'occasion de proposer une nouvelle feature ? -- Etienne ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Gonflage
2009/9/30 Jean-Francois Nifenecker : > Bonjour, > > je ne sais si cette question a déjà été posée ici... Jamais... > Comment étiqueter une station de gonflage comme on en trouve aux entrées > d'autoroutes, par exemple ? highway=services (attention au 's') + inflation_station=yes ? ou amenity=tire_inflation_station ? ou amenity=fuel + inflation_station=yes si combiné avec une station essence ? Il faudrait aussi regarder avec tagwatch si le mot 'inflation' est déjà utilisé. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
