Re: [OSM-talk-fr] Limites de communes
J'espère que tu n'a pas eu trop de casse ! Si tu te sens le courage, tu peux ajouter ton épreuve : http://wiki.openstreetmap.org/wiki/Mapping_accidents 2009/2/27 Laurent DELAGE > J'ai eu un accident sur un double way hier ... Les noeuds était communs à > une route et à une limite ... Je suis repassé, j'ai rajouté un noeud à la > route pour bien suivre les traces GPS ... Resultat la limite n'a pas eu > droit à ce noeud, du coup tout cassé ! > ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites de communes
> Une relation a été créée, formée des ways qui entourent la commune. Quand > tu passes à la suivante, rebelotte, de sorte qu'un way appartiendra, à la > fin à deux communes. Pas de duplication des way et ça peut aussi bien être > une rivière, qu'une côte, qu'une route ou qu'une bordure de forêt. > C'est vrai que tant qu'à faire des relations autant aller au bout je te rejoins ... Mais ... Je prends un tronçon de route, et je l'ajoute à ma relation ... Si quelqu'un par la suite le coupe en deux ... (avec potlach, ou josm par ex ...) Est-on bien garanti que la relation sera mise à jour ??? Quelqu'un qui se fout des limites de communes peut ne pas se rendre compte que son travail va tout casser ailleurs ... En fait je n'ai pas fait l'essai ... J'imagine que JOSM fait bien le boulot, mais comme je n'utilise jamais potlach ... En tout cas, après vous avoir lu tous pas de soucis, relation dès qu'on peut !!! J'ai eu un accident sur un double way hier ... Les noeuds était communs à une route et à une limite ... Je suis repassé, j'ai rajouté un noeud à la route pour bien suivre les traces GPS ... Resultat la limite n'a pas eu droit à ce noeud, du coup tout cassé ! -- Laurent DELAGE Comité Départemental du Tourisme de la Charente www.lacharente.com www.visitcharente.com ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites de communes
Merci à tous pour toutes ces informations ... Pour le source="cadastre", je pensais le mettre sur les way decalqués du cadastre,(je le mettrais meme sur les points), mais effectivement pas sur les relations ... J'ai oublié de préciser qu'effectivement, mon besoin n'était pas dans un 1er temps d'exploiter l'image générée par osm, mais de rééxploiter les données en local chez moi ... (Marre d'avoir des bouts de cartes que je n'ai même pas le droit de regarder ... ) Mon besoin était une vue "administrative" du département (communes, communautés de communes, pays ...) Ne vous inquiétez pas, à d'autres moments je publie de la trace, et j'avance sur le réseau routier ;-) ... Tiens en passant une autre question "légale". Je génère une map uniquement depuis les données d'Osm. Je l'intègre dans un document quelconque. Si je mets "Données issues d'openstreetmap", et que je mets une notice expliquant que les données de la carte et la carte sont sous licence "BY-NC- SA", est-ce suffisant pour distribuer le document par la suite ?? J'ai un doute pour le "BY"... On dit qu'il faut créditer les auteurs, mais est-ce que créditer le projet est suffisant ? La question est posée sur la faq légale mais est restée sans réponse... (J'aimerais pas trop devoir mettre une notice avec 272 auteurs ...) > > Tu veux ré-exploiter les relations avec osm2pgsql ? alors j'ai le patch > qu'il te faut, qui a été intégré puis désintégré (il me semble) > > et il te les mettra direct dans planet_osm_polygon si ils sont bien fermés > > http://lists.openstreetmap.org/pipermail/dev/2009-February/013971.html > et la réponse qui suit Alors là merci !!! Je venais juste d'ouvrir le svn d'osm2pgsql, et je m'appretais à réinventer la roue ! -- Laurent DELAGE Comité Départemental du Tourisme de la Charente www.lacharente.com www.visitcharente.com ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Re : Rond-point en plusieurs morceaux
Sans être d'un désintéret total cette question se résoud facilement à condition de ne pas vouloir être plus royaliste que le roi. Si le rond point est en élévation sur l'autoroute le mettre ainsi que une partie de ses bretelles d'accès en "bridge". Si le rond point est au niveau du sol et que l'autoroute est dans une tranchée la tagger en tunnel. 2 Facile, et surtout simple. A vouloir trop en faire, comment allez vous tagger lorsque des tronçons entier du périphérique ou de la francillienne vont se retrouver sous dalle? Si vous voulez être précis c'est chaque élément sur cette dalle qui va se retrouver en bridge. Si vous voulez être efficace vous tagerez le troncon de voie en tunnel. Je sais pas pour vous, mais une dizaine de "building=yes; bridge=yes" ça me tente moyen-moyen. D'ailleurs, ça commence où un pont? Dès qu'on est en élévation ou au premier joint de dilatation? Ou plus prozaïquement dès que c'est opportun de le tagger comme tel? Moi je vote pour l'opportunité et le pratique. - Message d'origine De : g.d À : Discussions sur OSM en français Envoyé le : Jeudi, 26 Février 2009, 23h53mn 14s Objet : Re: [OSM-talk-fr] Rond-point en plusieurs morceaux Vu le non-intérêt, cette question est-elle "out" ? Le 26 févr. 09 à 07:55, g.d a écrit : > > Là, on est à la bonne page :-) > > Cette relationship me paraît complexe. > > D'autre part, ça introduit les notions d'un way "outline" = contour > et d'un way "edge" = bord, de l'ouvrage d'art. Tiens, tiens... ;-) > Ça revient à ce que je proposais ! > > Au risque de me répépéter, pour les ponts : > Si, déjà, on mettait le way qui passe sur le pont sur layer +2, > et intercalait au layer +1 les ways qui décrivent l'ouvrage d'art ? > > - Pour un pont simple, juste un way "bridge" sous la voie de > circulation, > avec deux nodes ou plus, > - Pour un ouvrage complexe, un area "ouline", > - Et pourquoi pas, comme ils proposent, > pour des trucs plus compliqués, le dessin concret des bords, > avec un way "edge" (= la bonne vieille méthode des dessinateurs), > - en conservant en parallèle la méthode classique ? > > et cela avec des tags tout-à-fait classiques. > Procédure similaire pour les tunnels. > > Pour les autres features proposés, on a déjà des tags classiques : > tunnel/bridge, layer, name, ref, toll, maxheigth/weight, operator... > > Rien n'empêchera, > qu'une relation ultérieurement pourrait regroupe ça. > > Mais il me semble, > qu'il "faudra" d'abord dessiner ces ways bridge, outline ou edge, > avant de pouvoir les fourrer dans une relation. > > On ajouterait deux tags classiques, > un pour "outline" = contour, un pour "edge" = bord, > et le tour serait joué (?). Est-ce que j'ai raté une marche ? > > Gerhard > --- > > Pour économiser le nombre de layers, on pourrait discuter, > s'il est utile d'intercaler un layer pour l'ouvrage d'art, > ou s'il suffit, > de mettre l'ouvrage d'art simplement sur le layer du dessous, > ensemble avec le way qu'il enjambe > (Cette version "simplifiée" pourrait même faciliter la recherche des > "crossings" de laquelle parle jenesaisplusqui sur la page de > discussion). > > Le 25 févr. 09 à 23:24, Marc SIBERT a écrit : > >> >> Et oui, le copier / coller c'est facile, mais quand je ne regarde >> pas le >> texte de la proposition, je tappe à côté. Alors que juste à côté >> justement : >> http://wiki.openstreetmap.org/wiki/Relations/Proposed/ >> Bridges_and_Tunnels >> J'imagine que l'url sera encore coupée... >> -- >> Marc >> >> g.d a écrit : >>> Ah oui, ça change :-) >>> Mais tout de même, >>> cette propo ne semble pas intervenir au niveau de "notre" question, >>> au contraire, elle semble de clairement s'en distancer : >>> >>> There should not be an assumption that adjacent ways of a dual carriageway share a common bridge structure when crossing a bridge. This may or may not be the case - dual carriageways often have separate bridges carrying each carriageway. The commonality of a bridge can be indicated with the Bridge relation. >>> >>> Donc, par déduction, >>> quelque part il y aurait déjà une "relation bridge", >>> qui relierait plusieurs voies en un seul pont. >>> Mais où ? Comment ? >>> Pardon, question idiote, d'un béta... :-( >>> >>> >>> Le 25 févr. 09 à 22:25, Marc SIBERT a écrit : >>> >>> une retour de ligne malheureux peut-être : http://wiki.openstreetmap.org/wiki/Relations/Proposed/ Dual_carriageways -- Marc g.d a écrit : > Page vide, > page de discussion vide aussi :-( > > Le 25 févr. 09 à 20:27, Marc SIBERT a écrit : > > > >> Dominique Rousseau a écrit : >> >> >>> Si il s'agit d'une route à plusieurs voies, les tag name=* >>> sont là >>> pour >>> ça :-) >>> Mais je suppose que tu penses à un cas où il y aurait un seul >>> pont, >>> supportant des voies séparées pour des "routes" séparées (ie >>> les 2 >>> sens >>> de circulation
Re: [OSM-talk-fr] Rond-point en plusieurs morceaux
Vu le non-intérêt, cette question est-elle "out" ? Le 26 févr. 09 à 07:55, g.d a écrit : > > Là, on est à la bonne page :-) > > Cette relationship me paraît complexe. > > D'autre part, ça introduit les notions d'un way "outline" = contour > et d'un way "edge" = bord, de l'ouvrage d'art. Tiens, tiens... ;-) > Ça revient à ce que je proposais ! > > Au risque de me répépéter, pour les ponts : > Si, déjà, on mettait le way qui passe sur le pont sur layer +2, > et intercalait au layer +1 les ways qui décrivent l'ouvrage d'art ? > > - Pour un pont simple, juste un way "bridge" sous la voie de > circulation, > avec deux nodes ou plus, > - Pour un ouvrage complexe, un area "ouline", > - Et pourquoi pas, comme ils proposent, > pour des trucs plus compliqués, le dessin concret des bords, > avec un way "edge" (= la bonne vieille méthode des dessinateurs), > - en conservant en parallèle la méthode classique ? > > et cela avec des tags tout-à-fait classiques. > Procédure similaire pour les tunnels. > > Pour les autres features proposés, on a déjà des tags classiques : > tunnel/bridge, layer, name, ref, toll, maxheigth/weight, operator... > > Rien n'empêchera, > qu'une relation ultérieurement pourrait regroupe ça. > > Mais il me semble, > qu'il "faudra" d'abord dessiner ces ways bridge, outline ou edge, > avant de pouvoir les fourrer dans une relation. > > On ajouterait deux tags classiques, > un pour "outline" = contour, un pour "edge" = bord, > et le tour serait joué (?). Est-ce que j'ai raté une marche ? > > Gerhard > --- > > Pour économiser le nombre de layers, on pourrait discuter, > s'il est utile d'intercaler un layer pour l'ouvrage d'art, > ou s'il suffit, > de mettre l'ouvrage d'art simplement sur le layer du dessous, > ensemble avec le way qu'il enjambe > (Cette version "simplifiée" pourrait même faciliter la recherche des > "crossings" de laquelle parle jenesaisplusqui sur la page de > discussion). > > Le 25 févr. 09 à 23:24, Marc SIBERT a écrit : > >> >> Et oui, le copier / coller c'est facile, mais quand je ne regarde >> pas le >> texte de la proposition, je tappe à côté. Alors que juste à côté >> justement : >> http://wiki.openstreetmap.org/wiki/Relations/Proposed/ >> Bridges_and_Tunnels >> J'imagine que l'url sera encore coupée... >> -- >> Marc >> >> g.d a écrit : >>> Ah oui, ça change :-) >>> Mais tout de même, >>> cette propo ne semble pas intervenir au niveau de "notre" question, >>> au contraire, elle semble de clairement s'en distancer : >>> >>> There should not be an assumption that adjacent ways of a dual carriageway share a common bridge structure when crossing a bridge. This may or may not be the case - dual carriageways often have separate bridges carrying each carriageway. The commonality of a bridge can be indicated with the Bridge relation. >>> >>> Donc, par déduction, >>> quelque part il y aurait déjà une "relation bridge", >>> qui relierait plusieurs voies en un seul pont. >>> Mais où ? Comment ? >>> Pardon, question idiote, d'un béta... :-( >>> >>> >>> Le 25 févr. 09 à 22:25, Marc SIBERT a écrit : >>> >>> une retour de ligne malheureux peut-être : http://wiki.openstreetmap.org/wiki/Relations/Proposed/ Dual_carriageways -- Marc g.d a écrit : > Page vide, > page de discussion vide aussi :-( > > Le 25 févr. 09 à 20:27, Marc SIBERT a écrit : > > > >> Dominique Rousseau a écrit : >> >> >>> Si il s'agit d'une route à plusieurs voies, les tag name=* >>> sont là >>> pour >>> ça :-) >>> Mais je suppose que tu penses à un cas où il y aurait un seul >>> pont, >>> supportant des voies séparées pour des "routes" séparées (ie >>> les 2 >>> sens >>> de circulation). >>> >>> >>> >> Il existe déjà une proposition pour regrouper les voies >> différentes >> (way) partageant le même pont ; cela utilise une relation >> évidemment :-) >> http://wiki.openstreetmap.org/wiki/Relations/Proposed/ >> Dual_carriageways >> A+ >> -- >> 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] Analyseur de la base
E. Chové a écrit : > Je rajouterai un bouton à coté de chaque erreur KeepRight pour > l'ignorer... On pourra alors ignorer une erreur fausse ou une erreur > qu'on vient de corriger pour qu'elle disparaisse le lendemain. Excusez-moi de vous demander encore du travail, mais ne vaudrait-il pas mieux ne pas lister les erreurs dèjà corrigêes et repêrables comme telles ? Par exemple : si erreur_KR == way_sans_tag et que le way a actuellement un tag dans la base, ne pas imprimer l'erreur. Un peu comme MS_bot vérifie, avant de faire un changement, que la base contient toujours le nom erroné qu'il a détecté. Art. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Analyseur de la base
Olivier Boudet a écrit : > La page me concernant était pareille : la moitié des choses étaient > déjà corrigées de la veille. Le problème est que KeepRight génère ses données à intervalle irrégulier. > Par contre je trouve vraiment polluantes les lignes du genre "This node is > tagged as place of worship and therefore needs a religion tag" Je rajouterai un bouton à coté de chaque erreur KeepRight pour l'ignorer... On pourra alors ignorer une erreur fausse ou une erreur qu'on vient de corriger pour qu'elle disparaisse le lendemain. -- Etienne ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Analyseur de la base
sylvain letuffe a écrit : >> Pour le moment les zones ne sont que des rectangles. Je peut facilement >> en rajouter. Si certains veulent leur village/ville... il n'y a pas de >> problème pour l'ajouter. > > "Savoie étendue" bbox : 5.5/45 et 7.3/46 si c'est possible ;-) > >> Je vais implémenter un algo pour avoir des zones polygonales quelconque, >> il me faut juste un peu de temps > > Oulla, selon comment tu vas le faire, ça peut devenir pas simple du tout. > Mais > osmosis doit pouvoir te venir en aide avec son option --bp > >> > Y-a-t-il un espoir d'un classement des erreurs par département ? >> >> Du coup bientôt si toutes les limites administratives sont tracées. > > ce serait top. > Merci pour cet outils ! Et voila le travail... osmosis met 40 minutes pour découper france.osm en 100 fichiers de département mais ça a l'air de bien marcher. -- Etienne ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites de communes
sly (sylvain letuffe) a écrit : >> Certains le mettent dans la relation, d'autres sur les ways, il >> faudrait aussi se mettre d'accord là-dessus (moi je préfère sur les >> ways puisque la relation est une création purement osm). > +1 > >> aussi pour faire deux ways qui se superposent (mêmes noeuds) sur les >> parties communes mais tout le monde n'est pas de cet avis > -1 > >> (j'ai vu des >> cas avec un way unique regroupant tous les tags). > -1 > >> Certains voudraient supprimer le noeud avec le tag >> "place" depuis que la relation boundary existe (sly). > NON ! > > ce tag à un sens si il pointe un village, et physiquement c'est valable. Ce > que je ne veux pas c'est dire : > "on place un point, au petit bonheur la chance, et il symbolise la commune" > La commune est une surface, il me semble plus logique de replacer les > attributs d'une surface dans ce qui symbolise la surface : > - un polygone fermé > ou > - une relation représentant un polygone fermé > > Le noeud place, peut être considéré comme ayant un sens pour les tout petits > village. Encore que la solution de pieren du landuse pour décrire "la zone où > il y a des maisons regroupées" me semble encore plus préférable. > > >> pas tout à fait la même chose et en plus, ce noeud peut servir à >> correctement placer le label sur une carte alors qu'un tag "name" de >> la relation sera géocentré sur le polygone > > Ceci est un problème de rendu, redéfinissons éventuellement une manière > d'aider les rendus pour ce qu'ils ne peuvent deviner, mais ne donner pas de > sens géographique à un "label" > >> , càd parfois très loin du >> lieu concerné. > > Pas d'accord, le nom d'une commune concerne une surface, c'est jusque que > trop > confondent, à mon avis, commune et ville. Bonsoir, Commune et ville sont deux dénominations désignant une même structure administrative. Seule l'importance de la population fait la différence. Il faut distinguer la structure administrative qui est une surface de la notion d'agglomération qui est une surface, aussi, mais beaucoup plus petite pour la majorité des cas. Quant à la localisation des lieux il faut se référer à la mairie principale de la commune comme étant le siège légal de la commune. La mairie centrale n'est pas forcément le lieu correspondant à la mairie de quartier où elle se trouve physiquement. Il peut donc arriver que le nom de la commune soit totalement excentré par rapport à son siège légal. Il faut donc bien servir les deux éléments. C'est pour cela qu'il faut impérativement indiquer la mairie comme élément indépendant et non pas lié à la surface. Rares sont les mairies qui soient exactement au centre de leur territoire. Pour les voies limites de structures administratives il faut respecter l'esprit du cadastre ET la réalité du terrain. Si les cotés de la voie sont sur deux communes différentes il est logique de mettre la limite au centre. Par contre si la limite de commune est clairement hors de la voie il faut mettre les deux cotés de la voie dans la commune concernée. La limite de la commune est liée au terrain (terre) donc nous avons l'information. Ce cas doit être quasi inexistant ou alors il y a un problème légal car aucune terre ne peut être enclavée sans accès à la voirie de la commune dont elle fait partie. Amitiés -- Yannick VOYEAUD http://www.voyeaud.org Créateur CimGenWeb: http://www.francegenweb.org/cimgenweb/ Actes En Vrac: http://www.francegenweb/actes/ Cercle Généalogique (EGE-PTT): http://www.cercle-genealogique.fr Inconnu de Saulcy: http://www.lced.org Antoine Payet de la Réunion: http://payet.voyeaud.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites de communes
> - il y a des rues qui sont des deux côtés à Paris, ou des deux côtés hors de > Paris ; dans ces conditions, on doit avoir un Way administratif à côté du Way > physique. Je reprends, donc. Quand on essaye de suivre les rues qui marquent la limite de Paris (rues au-delà du périphérique), on se rend compte que, - parfois, des côtés "pair" et "impair", il y a des plaques "Rue Machin, Paris" ; et dès qu'on franchit un croisement, on tombe dans une rue (perpendiculaire) marquée Autre Commune, ou une plaque d'agglomération - parfois, des deux côtés, on a "Rue Machin, Commune autre" ; et dès qu'on franchit le croisement, on a une rue de Paris, et une plaque "Paris" - parfois, un côté est marqué Paris et un autre "Autre commune" C'est mine de rien assez important pour la gestion des adresses. Il m'est arrivé de travailler Rue d'Oradour sur Glane, qui est à Paris des deux côtés de la rue, mais dès qu'on franchit le pas de l'immeuble, on entre à Issy les Moulineaux (et le maire d'Issy, M. Santini, était venu nous remercier de contribuer à l'économie de sa ville par nos taxes car nous étions sur son territoire, et de coûter à la ville de Paris pour la gestion de nos ordures ménagères ; mais là, je m'égare...) Schéma : la limite peut être au-dessus des signes "=", en-dessous, ou bien au milieu (si les signes représentent les sens de circulation) | == | Ce type de détail ne se voit que sur place. Le Cadastre n'est pas assez précis. Ce que je dis, c'est que : - si la limite est exactement sur le =, avec un côté "Paris" et l'autre "Autre commune", il faut absolument partager les noeuds. Sinon, mathématiquement, il y aura des endroits où l'on sera du mauvais côté. - si la limite est au-dessus ou en-dessous du "=", il faut créer un way différent qui longe le "=". C'est du travail d'orfèvre... - Mail Original - De: "Pieren" À: "Discussions sur OSM en français" Envoyé: Jeudi 26 Février 2009 18:14:05 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: Re: [OSM-talk-fr] Limites de communes 2009/2/26 : > Pierren (Le Grand Sage) "Le grand singe", tu veux dire ! Mon point de vue n'a pas plus de valeur que les autres. Ce qu'il faut, c'est des consensus et au final, une manière de procéder identique au moins sur le territoire français et le plus proche possible des autres pays pour que les outils développés pour OSM fonctionnent à peu près partout. Pour ce qui est des limites communales, pas grand chose a ajouter si ce n'est qu'on a encore oublié de mentionner le tag "source=cadastre..." qui est obligatoire si ça vient du cadastre. Certains le mettent dans la relation, d'autres sur les ways, il faudrait aussi se mettre d'accord là-dessus (moi je préfère sur les ways puisque la relation est une création purement osm). Pour ce qui est des limites qui suivent une route ou une rivière, moi je suis aussi pour faire deux ways qui se superposent (mêmes noeuds) sur les parties communes mais tout le monde n'est pas de cet avis (j'ai vu des cas avec un way unique regroupant tous les tags). Pour le noeud "place", s'il est déjà dans la base et créé par le script d'import d'Alban (created_by=editop)(ce qu'il a fait par départements mais je ne sais pas si tous sont fait aujourd'hui), alors il faudra très probablement le déplacer sur le centre de l'agglomération. Il faudra aussi éventuellement corriger une mauvaise orthographe (accents, typo). La notion de "centre" étant lui-même sujet à controverse, est-ce la mairie ou l'hôtel de ville (lorsque ce n'est pas le même bâtiment), le centre historique (la place du village, la place centrale en ville). Certains voudraient supprimer le noeud avec le tag "place" depuis que la relation boundary existe (sly). Mais ça n'est pas tout à fait la même chose et en plus, ce noeud peut servir à correctement placer le label sur une carte alors qu'un tag "name" de la relation sera géocentré sur le polygone, càd parfois très loin du lieu concerné. Charlie Echo a écrit: > - il y a des rues qui sont des deux côtés à Paris, ou des deux côtés hors de > Paris ; dans ces conditions, on doit avoir un Way administratif à côté du Way > physique. Je ne pas sûr de comprendre cette phrase. Il arrive que le cadastre place la limite communale au milieu de la voie (rue ou route) (on superpose), mais il arrive aussi que ça soit sur le bord de la route (je pense que c'est ce que tu veux dire par "les deux côtés") alors oui on trace deux ways séparés. Note qu'il arrive assez souvent que lorsqu'on regarde le cadastre sur les deux communes adjacentes, il arrive qu'une commune considère la limite au milieu de la voie et que l'autre considère la limite au bord. Dans ces cas de conflits à l'intérieur même du cadastre (fréquents), on pourrait décider de ne pas trancher et de dessiner les deux limites sans les rattacher. Moi, je préfère laisser une des deux versions (on parle de quelques mètres d'écart), en général la première que j'ai tracé. Pieren, le grand
Re: [OSM-talk-fr] Limites de communes
Le Thu, Feb 26, 2009 at 06:14:05PM +0100, Pieren [pier...@gmail.com] a écrit: [...] > Pour ce qui est des limites communales, pas grand chose a ajouter si > ce n'est qu'on a encore oublié de mentionner le tag > "source=cadastre..." qui est obligatoire si ça vient du cadastre. > Certains le mettent dans la relation, d'autres sur les ways, il > faudrait aussi se mettre d'accord là-dessus (moi je préfère sur les > ways puisque la relation est une création purement osm). +1 -- Dominique Rousseau Si cinquante millions de gens disent une sottise, ça n'en reste pas moins une sottise. -- Anatole France ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites de communes
> Certains le mettent dans la relation, d'autres sur les ways, il > faudrait aussi se mettre d'accord là-dessus (moi je préfère sur les > ways puisque la relation est une création purement osm). +1 > aussi pour faire deux ways qui se superposent (mêmes noeuds) sur les > parties communes mais tout le monde n'est pas de cet avis -1 > (j'ai vu des > cas avec un way unique regroupant tous les tags). -1 > Certains voudraient supprimer le noeud avec le tag > "place" depuis que la relation boundary existe (sly). NON ! ce tag à un sens si il pointe un village, et physiquement c'est valable. Ce que je ne veux pas c'est dire : "on place un point, au petit bonheur la chance, et il symbolise la commune" La commune est une surface, il me semble plus logique de replacer les attributs d'une surface dans ce qui symbolise la surface : - un polygone fermé ou - une relation représentant un polygone fermé Le noeud place, peut être considéré comme ayant un sens pour les tout petits village. Encore que la solution de pieren du landuse pour décrire "la zone où il y a des maisons regroupées" me semble encore plus préférable. > pas tout à fait la même chose et en plus, ce noeud peut servir à > correctement placer le label sur une carte alors qu'un tag "name" de > la relation sera géocentré sur le polygone Ceci est un problème de rendu, redéfinissons éventuellement une manière d'aider les rendus pour ce qu'ils ne peuvent deviner, mais ne donner pas de sens géographique à un "label" > , càd parfois très loin du > lieu concerné. Pas d'accord, le nom d'une commune concerne une surface, c'est jusque que trop confondent, à mon avis, commune et ville. ( le seul cas que j'imagine ou un placement automatique du label commune est mauvais, est dans le cas d'une commune à forme de banane, mais là aussi, encore une fois, c'est un problème de rendu ) -- 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] Limites de communes
> Ok ! J'avais mal compris ... La présence de code_insee dans "place=village" > me > confusionnait. Il me semble plus logique que le code insee d'une commune soit. dans la commune ;-) et pas dans le village principal de la même commune (mais ça ne mange pas de pain de le mettre aussi, et ça permet à pieren de faire ses requêtes sur namefinder ) > Ma difficulté étant maintenant de savoir comment je vais retrouver les > relations > boundary=administrative après un passage de osm2pgsql Tu veux ré-exploiter les relations avec osm2pgsql ? alors j'ai le patch qu'il te faut, qui a été intégré puis désintégré (il me semble) et il te les mettra direct dans planet_osm_polygon si ils sont bien fermés http://lists.openstreetmap.org/pipermail/dev/2009-February/013971.html et la réponse qui suit -- 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] Limites de communes
> Pour repondre à ta question sur le partage de points, je reprends mon mail > récent (qui n'a eu aucune réponse... sniff) et ré-affirme qu'il est BON que > les ways physiques partagent les mêmes points que les ways administratifs > quand c'est le cas : Pas de réponse ? alors voilà la mienne ;-) C'est bon, car moins pire que deux ways parallèles, mais c'est pas terrible : tu perds du temps à re-cliquer node après node pour au final créer un way superposé qui est en fait le même way que le premier, sauf que tu veux lui attribuer des propriétés différentes. Une rivière qui fait frontière, c'est la rivière qui fait frontière ! tu dédouble l'information alors que c'est le même chemin, et ça devient pénible à sélectionner ensuite dans les editeurs. La relation résoud ce problème, elle permet de dire : ce tracé physique est : - une frontière de commune - une frontière de département - une frontière de région - une frontière de pays - une rivière - une bordure de forêt (tant qu'on y est) One way to rule them all and in the relation, bind them > Dans ces conditions, le Way administratif DOIT avoir les mêmes Nodes que le > Way physique Oui ! Mais en fait, on peut aller un cran au dessus, la frontière doit avoir le même way que la route, et la route doit avoir le même way que la frontière. node (physique) > way (physique) > relation (logique)> relation of relation > Ces ways n'ont pas vraiment besoin de tag, mais il faut mieux en mettre un : > boundary=administrative > admin_level=8 (8 pour commune) Discutable, mais on peut, si c'est un way de type rivière, laisser le fait que ce soit une rivière > - Puis il faudra relier ces trois ways en une relation ; et là, la procédure > de création dépend de l'outil (Potlatch, JOSM, ...) > La relation aura comme tag : > type=boundary > boundary=administrative > admin_level=8 > name=Nom de la commune Impecable, dans ton dernier example, pas besoin de dé-doubler les ways ;-) -- 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] Limites de communes
Evidement, sur un sujet de ce type, il faut bien que je fasse chier mon monde ;-) Mais je présente comment il me semble, selon moi, et mon avis propre uniquement sur ce qui me semble être mieux à moi : > J'ai plusieurs moyen de faire les choses : > -Je fais des surfaces avec des way, en les taggant avec le place qui va > bien . > Dans ce cas, les way vont partager des points ... (Y compris forcément avec > des boundary de région / département). Bof, tu va vite t'apercevoir que c'est super chiant à taguer, car tu va aussi devoir superposer deux way en re-cliquant, sur toute la longueur de la bordure de la commune d'a coté, point par point, pour faire coïncider. Mais disons que c'est tout de même moins pire que de faire deux ways parallèles espacés de 1 mètre. > -J'essaye de faire avec des relations, mais là je vois pas bien comment m'en > sortir .. Et pourtant, une fois qu'on à perdu 20 minutes à comprendre, on gagne 5 minutes par commune, c'est rentable au bout de 5 ;-) Une relation, c'est un ensemble d'objet (node, way ou même autre relations) Tu sélectionnes les ways qui forme un ensemble cohérent (une commune) et tu les utilises dans JOSM en bas à droite dans le menu des relations : tu fais "nouvelle relation", tu donnes le name=nom de la commune, admin_level=8, type=boundary, boundary=administrative puis tu cliques sur "ajouter les ways sélectionnés à la relation" et hop ! Une relation a été créée, formée des ways qui entourent la commune. Quand tu passes à la suivante, rebelotte, de sorte qu'un way appartiendra, à la fin à deux communes. Pas de duplication des way et ça peut aussi bien être une rivière, qu'une côte, qu'une route ou qu'une bordure de forêt. > Je préfère l'option 1 dans la mesure ou je peux récupérer des polygon > directement Comment fais tu pour récupérer le polygon "directement" ? si oui, alors coupe le en morceaux de sorte qu'il ne se superpose pas à celle d'a coté, et fait les reliures nécessaires à deux endroits puis ajoute le à la relation. -- 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] Limites de communes
2009/2/26 : > Pierren (Le Grand Sage) "Le grand singe", tu veux dire ! Mon point de vue n'a pas plus de valeur que les autres. Ce qu'il faut, c'est des consensus et au final, une manière de procéder identique au moins sur le territoire français et le plus proche possible des autres pays pour que les outils développés pour OSM fonctionnent à peu près partout. Pour ce qui est des limites communales, pas grand chose a ajouter si ce n'est qu'on a encore oublié de mentionner le tag "source=cadastre..." qui est obligatoire si ça vient du cadastre. Certains le mettent dans la relation, d'autres sur les ways, il faudrait aussi se mettre d'accord là-dessus (moi je préfère sur les ways puisque la relation est une création purement osm). Pour ce qui est des limites qui suivent une route ou une rivière, moi je suis aussi pour faire deux ways qui se superposent (mêmes noeuds) sur les parties communes mais tout le monde n'est pas de cet avis (j'ai vu des cas avec un way unique regroupant tous les tags). Pour le noeud "place", s'il est déjà dans la base et créé par le script d'import d'Alban (created_by=editop)(ce qu'il a fait par départements mais je ne sais pas si tous sont fait aujourd'hui), alors il faudra très probablement le déplacer sur le centre de l'agglomération. Il faudra aussi éventuellement corriger une mauvaise orthographe (accents, typo). La notion de "centre" étant lui-même sujet à controverse, est-ce la mairie ou l'hôtel de ville (lorsque ce n'est pas le même bâtiment), le centre historique (la place du village, la place centrale en ville). Certains voudraient supprimer le noeud avec le tag "place" depuis que la relation boundary existe (sly). Mais ça n'est pas tout à fait la même chose et en plus, ce noeud peut servir à correctement placer le label sur une carte alors qu'un tag "name" de la relation sera géocentré sur le polygone, càd parfois très loin du lieu concerné. Charlie Echo a écrit: > - il y a des rues qui sont des deux côtés à Paris, ou des deux côtés hors de > Paris ; dans ces conditions, on doit avoir un Way administratif à côté du Way > physique. Je ne pas sûr de comprendre cette phrase. Il arrive que le cadastre place la limite communale au milieu de la voie (rue ou route) (on superpose), mais il arrive aussi que ça soit sur le bord de la route (je pense que c'est ce que tu veux dire par "les deux côtés") alors oui on trace deux ways séparés. Note qu'il arrive assez souvent que lorsqu'on regarde le cadastre sur les deux communes adjacentes, il arrive qu'une commune considère la limite au milieu de la voie et que l'autre considère la limite au bord. Dans ces cas de conflits à l'intérieur même du cadastre (fréquents), on pourrait décider de ne pas trancher et de dessiner les deux limites sans les rattacher. Moi, je préfère laisser une des deux versions (on parle de quelques mètres d'écart), en général la première que j'ai tracé. Pieren, le grand singe trop long comme gd-i ;-) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rond-point en plusieurs morceaux
J'ai regardé la proposition. Ça me semble globalement aller dans le bon sens. Par exemple, ça répond à ma question d'il y a a quelques jours, à savoir comment indiquer le nom d'un tunnel qui n'est pas celui de son autoroute. Pour le point de départ de cette discussion, ça permet aussi de définir des ponts sur mon rond-point. Maintenant, il faut voir avec différents cas un peu capillo-tracté ce que ça peut donner. Je vais essayer de faire différents schémas pour les intégrer à la discussion de la proposition. Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites de communes
Tu as bon. Je crois que quelqu'un a déjà rentré (automatiquement) tous les Noeuds "centres des communes" (place=village, code insee, code postal, population, ...) mais la localisation n'est pas toujours parfaite. Idéalement, il faudrait ré-utiliser ces noeuds pour éviter des duplications, quitte à le déplacer au bon endroit. place=* ne doit pas être confondu avec landuse=*. place concerne le nommage et n'est pas physique, landuse concerne l'utilisation de l'espace. Pierren (Le Grand Sage) m'avait dit d'utiliser landuse pour les agglomérations. En fait, sur les plans du cadastre, on ne trouve pas (toujours) la limite du panneau et du "50 km/h" (qui marquent l'entrée en agglomération), donc le Cadastre ne t'aidera guère. Ceci étant, comme place peut s'appliquer à une surface, il n'est pas inconcevable que l'on ait une Area avec landuse=* et place=* ; mais personnellement, je préfère avoir Place qui définit le centre-ville, ou le centre historique... Bref, je crois que tout ceci n'est pas encore bien figé, mais que tu as les grands principes ! - Mail Original - De: "Laurent DELAGE" À: "Discussions sur OSM en français" Envoyé: Jeudi 26 Février 2009 16:38:05 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: Re: [OSM-talk-fr] Limites de communes > Une tendance que j'ai notée (mais je n'ai rien lu d'officiel sur le sujet) > est de mettre, dans la relation : - les ways décrits > - un Node au centre-ville (ou ailleurs dans le village), et qui a comme tag > place=village, name=..., le code_insee, etc. Ok ! J'avais mal compris ... La présence de code_insee dans "place=village" me confusionnait. -place="*" C'est plutôt pour les "agglomérations" -Pour les communes administratives, c'est boundary=administrative, admin_level=8, en faisant des relations entre des ways avec un way pour chaque "frontière". J'ai bon ? Si c'est ok je vais corriger ce que j'ai déjà (mal) fait, et je me lance sur la totalité du département... Ma difficulté étant maintenant de savoir comment je vais retrouver les relations boundary=administrative après un passage de osm2pgsql -- Laurent DELAGE Comité Départemental du Tourisme de la Charente www.lacharente.com www.visitcharente.com ___ 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] Limites de communes
> Une tendance que j'ai notée (mais je n'ai rien lu d'officiel sur le sujet) > est de mettre, dans la relation : - les ways décrits > - un Node au centre-ville (ou ailleurs dans le village), et qui a comme tag > place=village, name=..., le code_insee, etc. Ok ! J'avais mal compris ... La présence de code_insee dans "place=village" me confusionnait. -place="*" C'est plutôt pour les "agglomérations" -Pour les communes administratives, c'est boundary=administrative, admin_level=8, en faisant des relations entre des ways avec un way pour chaque "frontière". J'ai bon ? Si c'est ok je vais corriger ce que j'ai déjà (mal) fait, et je me lance sur la totalité du département... Ma difficulté étant maintenant de savoir comment je vais retrouver les relations boundary=administrative après un passage de osm2pgsql -- Laurent DELAGE Comité Départemental du Tourisme de la Charente www.lacharente.com www.visitcharente.com ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites de communes
La commune n'est pas un village ; le village occupe en général une petite partie de la commune ; parfois, il y a plusieurs villages dans la commune (un village principal qui porte le nom de la commune, et des villages secondaires) Une tendance que j'ai notée (mais je n'ai rien lu d'officiel sur le sujet) est de mettre, dans la relation : - les ways décrits - un Node au centre-ville (ou ailleurs dans le village), et qui a comme tag place=village, name=..., le code_insee, etc. Par ailleurs, si tu veux délimiter le village ou une zone industrielle ou autre, une area avec name= et landuse=... convient. - Mail Original - De: "Laurent DELAGE" À: "Discussions sur OSM en français" Envoyé: Jeudi 26 Février 2009 16:04:16 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: Re: [OSM-talk-fr] Limites de communes > - Puis il faudra relier ces trois ways en une relation ; et là, la > procédure de création dépend de l'outil (Potlatch, JOSM, ...) La relation > aura comme tag : > type=boundary > boundary=administrative > admin_level=8 > name=Nom de la commune Ben du coup, je mettrais plus "place=village" (ou ce qui va bien) sur la relation ... Je me trompe ? Map features précise que les places peuvent s'appliquer à des points ou des zones ... Je trouverais logique que la ligne sont de type boundary, mais que la relation/zone soit de type Hamlet/town..., et reprenne les elements code_insee et tout ce qui va bien, non ??? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites de communes
Le jeudi 26 février 2009 15:41:03 Charlie Echo, vous avez écrit : > Bonjour, et bienvenue ! Merci !!! > > Pour repondre à ta question sur le partage de points, je reprends mon mail > récent (qui n'a eu aucune réponse... sniff) et ré-affirme qu'il est BON que > les ways physiques partagent les mêmes points que les ways administratifs > quand c'est le cas : Entièrement d'accord ! Si la limite est materialisée par une rivière, un chemin de fer ou une route, il est évident que les points devront être communs ! > - créer des ways indépendants : si la commune A est entourée de 3 communes > B1, B2, B3, il faudra 3 ways qui marqueront les frontières entre A-B1, A-B2 > et A-B3. Ces ways n'ont pas vraiment besoin de tag, mais il faut mieux en > mettre un : boundary=administrative > admin_level=8 (8 pour commune) Va pour ça ... > - Puis il faudra relier ces trois ways en une relation ; et là, la > procédure de création dépend de l'outil (Potlatch, JOSM, ...) La relation > aura comme tag : > type=boundary > boundary=administrative > admin_level=8 > name=Nom de la commune Ben du coup, je mettrais plus "place=village" (ou ce qui va bien) sur la relation ... Je me trompe ? Map features précise que les places peuvent s'appliquer à des points ou des zones ... Je trouverais logique que la ligne sont de type boundary, mais que la relation/zone soit de type Hamlet/town..., et reprenne les elements code_insee et tout ce qui va bien, non ??? -- Laurent DELAGE Comité Départemental du Tourisme de la Charente www.lacharente.com www.visitcharente.com ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites de communes
Bonjour, et bienvenue ! Pour repondre à ta question sur le partage de points, je reprends mon mail récent (qui n'a eu aucune réponse... sniff) et ré-affirme qu'il est BON que les ways physiques partagent les mêmes points que les ways administratifs quand c'est le cas : - il y a des rues en "bordure" de la ville qui servent de limite entre Paris et une autre commune ; d'un côté, on a un panneau "Rue Machin, Paris", et de l'autre "Rue Machin, autre commune". Dans ces conditions, le Way administratif DOIT avoir les mêmes Nodes que le Way physique (car s'il y a un décallage, mathématiquement, on considèrera que le Way physique est d'un côté...) - il y a des rues qui sont des deux côtés à Paris, ou des deux côtés hors de Paris ; dans ces conditions, on doit avoir un Way administratif à côté du Way physique. Puis vient la question : comment les relier ? Un consensus semble se dégager ; mais rien, à ma connaissance, n'est figé. Si tu fais des surfaces/polygones (area), c'est embêtant, car ce n'est pas la norme; qui plus est, UNE bordure entre deux communes sera tracée DEUX fois, ce qui peut, à terme, créer des trous. Donc il faut mieux : - créer des ways indépendants : si la commune A est entourée de 3 communes B1, B2, B3, il faudra 3 ways qui marqueront les frontières entre A-B1, A-B2 et A-B3. Ces ways n'ont pas vraiment besoin de tag, mais il faut mieux en mettre un : boundary=administrative admin_level=8 (8 pour commune) - Puis il faudra relier ces trois ways en une relation ; et là, la procédure de création dépend de l'outil (Potlatch, JOSM, ...) La relation aura comme tag : type=boundary boundary=administrative admin_level=8 name=Nom de la commune Voilà... - Mail Original - De: "Laurent DELAGE" À: "Discussions sur OSM en français" Envoyé: Jeudi 26 Février 2009 15:14:52 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: [OSM-talk-fr] Limites de communes Bonjour à tous, Je suis en train de travailler sur les limites de communes en Charente depuis le cadastre ... Je suis nouvel inscrit sur la liste, mais j'ai fouillé dans les archives, et je n'ai pas trouvé de positions arrétée sur le sujet ... J'ai plusieurs moyen de faire les choses : -Je fais des surfaces avec des way, en les taggant avec le place qui va bien . Dans ce cas, les way vont partager des points ... (Y compris forcément avec des boundary de région / département). -J'essaye de faire avec des relations, mais là je vois pas bien comment m'en sortir .. Je préfère l'option 1 dans la mesure ou je peux récupérer des polygon directement Vous en pensez quoi ? -- Laurent DELAGE Comité Départemental du Tourisme de la Charente www.lacharente.com www.visitcharente.com ___ 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] Limites de communes
Bonjour à tous, Je suis en train de travailler sur les limites de communes en Charente depuis le cadastre ... Je suis nouvel inscrit sur la liste, mais j'ai fouillé dans les archives, et je n'ai pas trouvé de positions arrétée sur le sujet ... J'ai plusieurs moyen de faire les choses : -Je fais des surfaces avec des way, en les taggant avec le place qui va bien . Dans ce cas, les way vont partager des points ... (Y compris forcément avec des boundary de région / département). -J'essaye de faire avec des relations, mais là je vois pas bien comment m'en sortir .. Je préfère l'option 1 dans la mesure ou je peux récupérer des polygon directement Vous en pensez quoi ? -- Laurent DELAGE Comité Départemental du Tourisme de la Charente www.lacharente.com www.visitcharente.com ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Analyseur de la base
La page me concernant était pareille : la moitié des choses étaient déjà corrigées de la veille. Par contre je trouve vraiment polluantes les lignes du genre "This node is tagged as place of worship and therefore needs a religion tag" Lorsque l'on cartographie beaucoup de villes différentes, dans des régions différentes (via les mapping parties par exemple), on se retrouve avec beaucoup de ligne de ce genre. Alors certes il faut un nom à ces choses mais les signaler dans une liste d'erreur est à mon avis pas trop valable. A la limite faire une 2e page ne contenant que des "warnings" pourrait être bien. (par exemple, en ayant fait quelques mapping parties, je me retrouve avec des erreurs pour les eglises, les cinemas, les pharmacies, les écoles, les banques, les bibliothèques, les bars, les restaurants, etc ca me semble bien bourrin !) On Thu, 26 Feb 2009 14:54:31 +0100, Art Penteur wrote: > Bonjour, > >Avec cette nouvelle version, j'ai constaté beaucoup de faux positifs, >de > signalement de choses déjà corrigées, ... >Est-ce du au délai de la base "dumpée" par le concepteur de KeepRight, >ou > est-ce un bug de jeunesse ? > >A titre d'exemple : node 250665868, *religion*=Catholic > *amenity*=place_of_worship > *name*=Eglise Sainte-Germaine-des-Pradettes, > signalé comme : > TEST KeepRight 110 (This node is tagged as place_of_worship and therefore > needs a name tag) > TEST KeepRight 100 (This node is tagged as place of worship and therefore > needs a religion tag) > > et plein d'autres sur : > http://colocb3.hd.free.fr/OsmErrors/ParUtilisateur/a/Art%20Penter.html > > Si c'est lié au délai de la base KeepRight, je trouve que c'est un peu > dommage. J'aimais bien le run quotidien, on parcourt la liste le soir, on > corrige, et le lendemain la liste est propre. >Maintenant, il est un peu démotivant d'aller voir tous les éléments >d'une > liste dont la moitié vont vous orienter vers des pb déjà corrigés. >Les délais KeepRight sont sûrement justifié (lourdeur de son >traitement, > ...), mais c'est un peu gênant. D'ailleurs, sur son interface, il vient de > mettre en place une possibilité d'effacer les erreurs jusqu'au prochain > run, > pour éviter que retourner voir une erreur déjà corrigée. > > Art. > > Le 25 février 2009 17:19, Etienne Chové a écrit : > >> Salut tous, >> >> Voila, pour ne pas refaire ce qui a déja été fait mais centraliser les >> informations, j'ai ajouté dans l'analyseur les erreurs détectées par >> KeepRight. Ca n'a pas été évident mais le concepteur de KeepRight a >> été >> hyper sympa et diffuse automatiquement le dump de sa base ainsi que les >> informations utiles (merci à lui). >> >> Cela m'a permis de corriger pas mal d'erreur d'intersection mal faites. >> Cependant son analyse contient de nombreux faux positifs, je vais voir >> avec lui ce qu'on peut faire pour eux. >> >> Les dictionnaires de correction ont été vidés et vont être remplis à >> la >> main pour plus de sûreté. Beaucoup de corrections ont disparues mais >> réapparaitront au fur et à mesure du remplissage des dico. >> >> http://colocb3.hd.free.fr/OsmErrors/ >> >> -- >> Etienne >> >> ___ >> 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] Analyseur de la base
Bonjour, Avec cette nouvelle version, j'ai constaté beaucoup de faux positifs, de signalement de choses déjà corrigées, ... Est-ce du au délai de la base "dumpée" par le concepteur de KeepRight, ou est-ce un bug de jeunesse ? A titre d'exemple : node 250665868, *religion*=Catholic *amenity*=place_of_worship *name*=Eglise Sainte-Germaine-des-Pradettes, signalé comme : TEST KeepRight 110 (This node is tagged as place_of_worship and therefore needs a name tag) TEST KeepRight 100 (This node is tagged as place of worship and therefore needs a religion tag) et plein d'autres sur : http://colocb3.hd.free.fr/OsmErrors/ParUtilisateur/a/Art%20Penter.html Si c'est lié au délai de la base KeepRight, je trouve que c'est un peu dommage. J'aimais bien le run quotidien, on parcourt la liste le soir, on corrige, et le lendemain la liste est propre. Maintenant, il est un peu démotivant d'aller voir tous les éléments d'une liste dont la moitié vont vous orienter vers des pb déjà corrigés. Les délais KeepRight sont sûrement justifié (lourdeur de son traitement, ...), mais c'est un peu gênant. D'ailleurs, sur son interface, il vient de mettre en place une possibilité d'effacer les erreurs jusqu'au prochain run, pour éviter que retourner voir une erreur déjà corrigée. Art. Le 25 février 2009 17:19, Etienne Chové a écrit : > Salut tous, > > Voila, pour ne pas refaire ce qui a déja été fait mais centraliser les > informations, j'ai ajouté dans l'analyseur les erreurs détectées par > KeepRight. Ca n'a pas été évident mais le concepteur de KeepRight a été > hyper sympa et diffuse automatiquement le dump de sa base ainsi que les > informations utiles (merci à lui). > > Cela m'a permis de corriger pas mal d'erreur d'intersection mal faites. > Cependant son analyse contient de nombreux faux positifs, je vais voir > avec lui ce qu'on peut faire pour eux. > > Les dictionnaires de correction ont été vidés et vont être remplis à la > main pour plus de sûreté. Beaucoup de corrections ont disparues mais > réapparaitront au fur et à mesure du remplissage des dico. > > http://colocb3.hd.free.fr/OsmErrors/ > > -- > Etienne > > ___ > 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] hexagone and geofabrik - et bots
Le Wed, Feb 25, 2009 at 06:42:51PM +0100, sly (sylvain letuffe) [sylv...@letuffe.org] a écrit: > Ben à pas bon, on s'est fait envahir par allemands et italiens et on a perdu > les départements frontaliers > > http://beta.letuffe.org/?zoom=6&lat=46.83052&lon=3.38765&layers=B0FFFT Et pour les régions, c'est encore plus fort que Baladur, c'est réduit à 12 : http://beta.letuffe.org/?zoom=6&lat=46.83052&lon=3.38765&layers=B0TFFF -- Dominique Rousseau Si cinquante millions de gens disent une sottise, ça n'en reste pas moins une sottise. -- Anatole France ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
