Re: [OSM-talk-fr] Plusieurs questions
Le 04/03/2011 10:34, Vincent de Chateau-Thierry a crit: De : "Romain MEHUT" (...) Mais, en contexte urbain o la plupart des btiments sont aligns, dans le cas o le numro est sur un node qui appartient par ailleurs au way "building" (comme le dit Vincent), les notions de point de situation et point d'accs sont bien lies? Dans ce contexte, elles seront trs souvent confondues, oui. vincent Bonjour, C'est toujours la question des adresses postales vs btiments. La notion d'adresse recouvre et l'un et l'autre. Tant qu'il n'y aura pas distinction entre les deux interprtations dans OSM, tout n'est qu'usage admis ; ni juste ni faux. Il y a des adresses sans btiment. Des btiments dtruits qui conservent une BAL et une adresse postale et "fiscale", ... Il suffirait (iakafokon) d'ajouter une prcision sur le type d'adresse et dfinir (2 fois iakafokon) les relations ncessaires obligatoires pour mettre tout le monde d'accord. Le "routing" se fait de toutes manires par relation sur les noms de rue. Si la rue est en plusieurs ways, il y a plusieurs pratiques, genre c'est le way principal qui prime mme si un autre way de la mme rue est plus proche, ... Bon courage :). Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Présentation
Bonsoir, La rue Jean Jaurès, le boulevard Solférino, ou la partie centre ville du la Voie Malraux ne pourraient-ils pas descendre en tertiary ? Ils ne doivent pas tellement servir à traverser le centre, mais à le desservir. Le centre-ville (le Plateau chez nous) n'est de toutes manières plus "traversable". Pour ma part, en ce qui concerne ces quatre axes (La voie Malraux étant l'axe de pénétration Est), je les surclasserai en "primary" de bout en bout. Aujourd'hui, la structuration "dorsale" de la circulation à Poitiers est claire : - les axes de pénétrations E/O/N/S, - le boulevard circulaire, - la rocade, - la rocade extérieure. Je ne comprendrai pas que les voies qui composent cette dorsale ne soient pas classées "primary". Le classement au jugé est hasardeux car laissé à l'interprétation de chacun. Un bonjour à Mickaël au passage, j'essaie de venir au prochain "jeudi". Benoît. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] import automatique de données
Bonjour, Pour les numros de rue, faut-il les entrer manuellement oui il y a dans le plugin cadastre une fonction qui est fort pratique pour ca ou il y a t'il un script en cours de prparation ? aussi mais on sait pas si il sera pret dans un delai raisonnable Le script n'est pas en prparation, un programme fonctionne pour importer les n de rue. Il tlcharge les lments du cadastre, dtecte et reconnait les n de rue depuis le cadastre, les lient entre eux les rorganise le long des rues et leur donne une note de fiabilit et ajoute les fixme en consquence. Le tout est export en .osm qui peut tre ouvert par josm. Je l'ai tester l'chelle d'une ville, sur Poitiers, a fonctionne. Reste que les discussions n'ont jamais abouties sur comment tagguer. Bien sr je peux tout importer massivement selon mes rgles qui finiront pas devenir un standard par le nombre, mais je n'ai aucune envie d'imposer la chose. Cherchez dans les archives de la liste Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] import automatique de données
Le 17/12/2010 21:03, Nicolas LECOINTE a écrit : Pas facile à lire le HTML !! Certe ! En texte : Bonjour, Pour les numéros de rue, faut-il les entrer manuellement oui il y a dans le plugin cadastre une fonction qui est fort pratique pour ca ou il y a t'il un script en cours de préparation ? aussi mais on sait pas si il sera pret dans un delai raisonnable Le script n'est pas en préparation, un programme fonctionne pour importer les n° de rue. Il télécharge les éléments du cadastre, détecte et reconnait les n° de rue depuis le cadastre, les lient entre eux les réorganise le long des rues et leur donne une note de fiabilité et ajoute les fixme en conséquence. Le tout est exporté en .osm qui peut être ouvert par josm. Je l'ai tester à l'échelle d'une ville, sur Poitiers, ça fonctionne. Reste que les discussions n'ont jamais abouties sur comment tagguer. Bien sûr je peux tout importer massivement selon mes règles qui finiront pas devenir un standard par le nombre, mais je n'ai aucune envie d'imposer la chose. Cherchez dans les archives de la liste Benoît R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Votes sur le wiki - était:clé pour un resto
Le 09/10/2010 18:33, sylvain letuffe a crit: Hehe, a me fait bien marr quand je lis que le tag a t rejet (par 7 personnes : http://wiki.openstreetmap.org/wiki/Proposed_features/Phone) et qu'il y en a 53.000 dans la base (http://taginfo.openstreetmap.de/keys/phone) Sans rapport aucun avec les propositions dont on parle ici, je trouve fallacieux cette approche que l'on voit de plus en plus qui consiste considrer le contenu de la base comme une quasi preuve de la qualit d'un tag. j'ai comme avis que les gens cherchent d'abord ce qu'il y a sur le wiki, et s'il tombent sur une proposition mme mdiocre qui s'approche de ce qu'ils veulent ils vont l'utiliser parce qu'ils n'ont que a. De sorte qu'un tag entr abruptement dans les map features va tre rapidement utilis alors qu'il est peu tre mal pens, ou insuffisant ou en conflit avec un autre. -- sly +1 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Votes sur le wiki - était:clé pour un resto
Le 09/10/2010 19:26, sylvain letuffe a crit: Le samedi 9 octobre 2010 18:47:45, Pieren a crit : Ca n'est pas ce que j'ai cris. Je disais "on", c'est juste que j'ai vu a plusieurs fois revenir sur tagging@ et sur le wiki (proposition type=boundary par exemple) et que je m'inquite que a prenne tant d'ampleur. (Je m'inquiterais aussi qu'on se fiche de ce que l'on trouve dans la base ceci dit) Mais le simple fait de sortir un gros chiffre 5 mis cot d'un autre 7, ressemble bigrement une comparaison mis sur le mme pied d'galit, et, une lecture rapide de ce type de message pourrait mener la conclusion : "l'avis des 7 ne vaut rien en comparaison", alors qu'il est difficile de savoir quelle valeur donner l'un et l'autre. [...] Je trouve que le ton de Pieren (tantinet dsabus mais objectif) tait juste et son propos aussi. Cela t mon ressenti la lecture. [...] Et qu'au bout d'un certain temps (quelques mois), on s'arrte un peu pour faire le point sur le succs de tel ou tel version et en profiter pour nettoyer le wiki et, si quelqu'un s'en sent le courage, la base (comme le rcent highway=incline ou les plus anciens noname) L'un des problmes de cette mthode c'est qu'on "sacrifie" le travail de ceux qui ont taggu avec un truc moyen au dbut et que a fait un peu trahison : a Mais heu, j'ai suivi une page du wiki, et c'est toujours pas sur la carte b Ben ouais, tu utilises un tag pourri, hop j'enlve la page en question a Fais chier, et quelqu'un va faire le programme magique qui converti automatiquement mon travail ? b ha non dsol, le tag est tellement mal fichu qu'il n'y a pas bijection possible avec le nouveau, on peut rien en faire, il faut refaire ou il fallait rflchir avant a pas cool ;-( Toute ressemblance avec une discussion ou un ressenti rl ne serait que fortuite Pour reprendre la discussion "boundary" qui laisse les choses se tasser un peu. La discussion arrive voquer l'ide qui la "bijection" doit tre une priorit pour chaque nouveau tag (mettre tous les lments qui permettront de les distinguer coup sr) et l'ide qu'une bonne chose serait de prendre en considration des arguments valables (recevables) avant de rpondre grosso modo un besoin immdiat sans faire abstraction de l'existant (bijection) mais en ne le prenant pas comme base intangible (donner un sens aux tag et ne pas les vider de leur sens). Quand la translation de l'existant n'est pas possible, se coordoner pour ne pas mettre en place le nouveau tag avant la translation des anciens. L'argument "le tag n'est pas reconnu ou utilis par les logiciels tiers." est un non sens. -- sly Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] J'ai perdu les Iles de la Loire
Le 09/10/2010 12:39, Pen Beuz a crit:
Je
n'arrive pas comprendre, mais je pense avoir fait une mauvaise
manip, les les de la Loire n'apparaissent plus entre Amboise et
Tours. J'ai voulu en rajouter et les anciennes ont disparu!
Pourtant sur JOSM elles sont bien l.
Une bonne me pourrait elle se pencher sur le problme et me dire
o est l'erreur?
J'ai aussi l'impression que la Loire est assez bizarrement
dfinie, il existe au moins deux multipolygones
river("La Loire") , cours deau("La loire") cela est il normal?
Pen Beuz aka Eric
Peut tre aucune relation, je n'ai pas pouss les recherches, mais
les les que j'avais traces sur la Gartempes Quincay (86) ont
elles aussi disparues. Compltement disparues, plus sous JOSM.
Benot R.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mise à disposition des données S POTMaps France à la communauté OpenStreetMap par Spot Image
Le 05/10/2010 20:51, Jean-Guilhem Cailton a crit: Bonsoir, On peut aussi, dans Prfrences / WMS, slectionner le rglage par dfaut "SPOTMaps (France)" ( la fin de la deuxime liste) et le copier dans la liste des serveurs affiche, avec le bouton ad hoc (comme indiqu par Jean-Franois), et viter ainsi les suppressions. Cordialement, Jean-Guilhem Pas d'URL SpotX o que ce soit dans les listes et ailleurs. Si qqun pouvait m'envoyer l'URL en priv je lui en serai reconnaissant. Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] qualité de la carte
Le 30/09/2010 09:49, Guilhem Bonnefille a crit: Le 30 septembre 2010 09:33, Jean-Francois Nifenecker jean-francois.nifenec...@laposte.net a crit : Le 30/09/2010 00:24, Benot ROUSSEAU a crit : La seule solution c'est de bosser : - faire UN vrai tutoriel, sans esprer cela des CUM format A5 destins aux expriments, - chercher des rfrences, - discuter des solutions argumentes, - mettre jour le wiki, - le tout sans illres en gardant un esprit critique face l'existant. je partage compltement ces ides. Moi aussi. Mais je n'attend pas que TOUS les contributeurs OSM participent ces actions. A mon sens, cela incombe une lite que je classerait dans le groupe QA. "lite" est peut tre stigmatisant :p et ce n'est peut tre pas une bonne ide que de mettre des personnes part dans un groupe QA. Je pense que les discussions qualit ne doivent en aucun cas tre traites par un groupe "fixe" en dehors de la communaut globale. Les discussions QA doivent pouvoir bnficies de l'exprience de tous dans des domaines qui vont bien au del de la cartographie : politique, informatique, statistiques, hydrographie, ... Et a permet tous de s'enrichir de tous. Moi j'ai beaucoup appris lire des discussions QA. Je m'explique... Si on cre un groupe QA, il risque d'tre fort orient par sur reprsentation d'une spcialit (Cratographes, Hydrographes, fortes gueules, ...) ou de "secteurs gographiques" (Les villes). Il y a des chances que ce ne soit pas le cas, mais on ne peux le garantir puisqu'on n'en a pas la matrise. Pour prendre l'exemple de la discussion des limites administratives fr. Si elle avait eu lieu part en petit comit, le groupe aurait-il bnficier des connaissances de tous ? Je pense au signalement de l'existence des Conseils de quartier avec une certaine autonomie et des communes associes. Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] qualité de la carte
Le 30/09/2010 12:36, sly (sylvain letuffe) a crit: On jeudi 30 septembre 2010, Pieren wrote: Pour le reste, les outils surveillant la qualit des contributions, il y en a dj beaucoup (mme trop). Et bien moi, je ne pense pas. Je dirais pas vraiment qu'il n'y en a pas assez, mais je dirais qu'il leur manque surtout quelques fonctionnalits, et cela influe ( mon avis) sur le problme suivant : Mais ils ne servent rien si personne ne s'en sert pour corriger les erreurs signales. Rflchir raliser un agrgateur des avertissements des d'outils de surveillance. Un programme qui regroupe sur une carte l'ensemble des erreurs repres par les diffrents outils. Les cartes pourraient faire peur, mais il serait pratique de n'avoir et de ne donner qu'une adresse pour voir les avertissements sur une zone. Je vais tenter un programme d'essai pour valuer les pb (faut-il dfinir un format d'change commun ?, ...). Pour les imports et corrections (semi-)automatiques, il faudrait au moins un semblant de coordination. Dans ce cas, un groupe et une liste part, mais qui passe l'info digre, sur la liste principale serait peut-tre utile. J'ai en tte le revert de suppression de points orphelins ou j'ai foir un import CLC de Simon. Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Tag:boundary=administrative / limites en France
Le 30/09/2010 12:44, Vincent Pottier a crit: On 30/09/2010 11:50, LEON Frdric wrote: Bienvenu Lon Le 29/09/2010 08:52, Vincent Pottier a crit : Il me semble qu'il existe une extension OpenOffice pour exporter en format mediawiki. Je n'ai jamais test. Je ne savais pas, je vais chercher. Merci. Accessoirement je m'occupe galement du site wiki-brest et je peux donc confirmer l'existence de cette fonctionnalit, il ne s'agit pas d'une extension mais bien d'une Option d'exportation de votre document en utilisant la syntaxe mediawiki. On la trouve sous le menu "Fichier" "Exporter", puis dans la boite de dialogue slectionner le "format de fichier" mediawiki. a n'est pas natif dans OOo. L'extension est ici : http://extensions.services.openoffice.org/fr/node/738? Voila, en esprant ne pas polluer la discussion avec cette info qui n'est pas directement Lie OSM. Si a encourage l'criture de doc/tuto en franais dans le wiki osm, c'est le bienvenu ! -- FrViPofm Merci pour toutes ces infos. Oui a va encourager la doc ! Benot. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Tag:boundary=administrative / limites en France
Le 30/09/2010 11:50, LEON Frdric a crit: Bonjour, [...] Voila, en esprant ne pas polluer la discussion avec cette info qui n'est pas directement Lie OSM. A bientt. Fred Merci. C'est directement li OSM qui ne ncessite pas que JOSM pour arriver ses fins. C'est directement li OSM, au fil de discussion et absolument pas une pollution. Benot. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] qualité de la carte
Le 30/09/2010 14:33, Pieren a crit: 2010/9/30 Christophe Merlet red...@redfoxcenter.org Et je vote pour la mise en place d'une quipe charg de l'Assurance Qualit charg de rappeler rgulirement les bonnes mthodes de contribution, et le cas chant d'engueuler les gougnafiers ! Ben, a sert rien de trpignier sur place en serrant ses petits poings et en criant "je veux ! je veux !" comme Joe Averell. Si tu veux utiliser les outils de contrle et parler ceux qui font des erreurs videntes (pas les points discutables), vas-y. Si tu le souhaites, tu peux mme crer un wikiProject et t'autoproclamer "QA group leader for France" en mettant ton nom en haut de la liste, personne ne te retiendra. Les "yaka, fokon" n'ont jamais fait avancer ce projet. Pieren Grrr... :p Christophe veux tu coordonner et suivre les initiatives qualit. Comme tu le dis ce serait une bonne chose, rien n'empche d'essayer. Si a ne fonctionne pas on laissera tomber sans t'incriminer car tu auras essay. Comme l'arrt du tabac, on sait qu'il faut arrter mais il faut parfois rater plusieurs essais. Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nouvelle page pour la réflexion su r les communautés de commune
Le 30/09/2010 21:56, Vincent de Chateau-Thierry a crit: Bonsoir, La synthse des discussions rcentes sur les EPCIs a t dplace cette adresse : http://wiki.openstreetmap.org/wiki/WikiProject_France/Tracer_les_limites_administratives/Mise_au_point_du_modele_des_EPCI L'adresse a chang, mais le but reste le mme : laborer le modle de tags et de relation pour ces entits. Tous les grains de sel sont les bienvenus :-) vincent Donc on garde les deux pages avec une spcifique aux EPCI et je peux continuer sur : http://wiki.openstreetmap.org/wiki/User:Vincent_95/draft/synthese_limites_administratives pour la discussion gnrale ? Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nouvelle page pour la réflexion su r les communautés de commune
Le 30/09/2010 23:52, Vincent de Chateau-Thierry a crit: Le 30/09/2010 23:36, Benot ROUSSEAU a crit : Donc on garde les deux pages avec une spcifique aux EPCI et je peux continuer sur : http://wiki.openstreetmap.org/wiki/User:Vincent_95/draft/synthese_limites_administratives pour la discussion gnrale ? Pour l'instant, la nouvelle page reprend intgralement le contenu de celle hberge sous mon compte. C'est vrai que les sujets abords dpassent les EPCI, mais ce point me parat suffisamment "massif" pour hriter d'une page avec un titre explicite. Pour les sujets connexes, comme par exemple les arrondissements dpartementaux, je ne sais pas s'il faut crr un espace diffrent, les choix pour les EPCI auront a priori des consquences sur le choix des tags des arrondissements. Pour la discussion sur les quartiers et les communes associes, et celle sur les cantons, je suis favorable l'amorce d'autres pages, dbarrasses du verbatim sur les EPCI, et qui permettraient d'y voir plus clair et de faire avancer les sujets en propre, chacun leur rythme. vincent Ok. Ne voyant rien non loggu sur http://wiki.openstreetmap.org/wiki/WikiProject_France/Tracer_les_limites_administratives/Mise_au_point_du_modele_des_EPCI j'ai cru qu'il n'y avait rien (je viens de vrifier en me loguant en voyant ton mail) donc j'ai continu mettre jour http://wiki.openstreetmap.org/wiki/User:Vincent_95/draft/synthese_limites_administratives. Zuteu zuteu zut ! Est-ce normal que rien n'apparaisse sur la page quand on est pas loggu ? Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Tag:boundary=administrative / limites en France
Le 29/09/2010 08:52, Vincent Pottier a crit: On 29/09/2010 05:10, Benot ROUSSEAU wrote: Le 29/09/2010 02:27, THEVENON Julien a crit: De : Benot ROUSSEAU adressepossi...@free.fr J'ai chang l'objet de la discussion. Vous trouverez ici la premire partie de la synthse : http://adresseimpossible.free.fr/fichiers/osm/Synth%C3%A8se%20BA.pdf Indiquez moi les erreurs, les oublis et les traitements partisans des sujets. Beau travail de synthese vu le nombre de mails echanges ! Par contre est ce qu une page wiki ne serait pas plus simple pour permettre aux differentes intervenants d eventuellement completer la synthese, avec commentaires dans la partie discussion. Cela a aussi l avantage de laisser une trace dans la doc My 2 cents Julien Merci. Oui c'est long, une copie bout a bout des messages (doublons textes, bla bla des anti-virus, ...) c'est 65 pages A4 en 12pt. D'accord pour le wiki, mais une mise en forme s'impose avec un traitement de texte d'abord. Le navigateur sous Writer est par exemple pratique pour isoler les liens, ... J'ai peur que travailler directement sur une page du wiki soit galre. Si nous l'avions complte au fur et mesure oui. Benot R. Il me semble qu'il existe une extension OpenOffice pour exporter en format mediawiki. Je n'ai jamais test. Je ne savais pas, je vais chercher. Merci. -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr Ce message entrant est certifi sans virus connu. Analyse effectue par AVG - www.avg.fr Version: 9.0.856 / Base de donnes virale: 271.1.1/3164 - Date: 09/28/10 08:34:00 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Tag:boundary=administrative / limites en France
Le 29/09/2010 08:05, Vincent de Chateau-Thierry a crit: Bonjour, Le 29/09/2010 05:10, Benot ROUSSEAU a crit : Le 29/09/2010 02:27, THEVENON Julien a crit : *De :* Benot ROUSSEAU adressepossi...@free.fr ** J'ai chang l'objet de la discussion. Vous trouverez ici la premire partie de la synthse : http://adresseimpossible.free.fr/fichiers/osm/Synth%C3%A8se%20BA.pdf Indiquez moi les erreurs, les oublis et les traitements partisans des sujets. Beau travail de synthese vu le nombre de mails echanges ! Par contre est ce qu une page wiki ne serait pas plus simple pour permettre aux differentes intervenants d eventuellement completer la synthese, avec commentaires dans la partie discussion. Cela a aussi l avantage de laisser une trace dans la doc My 2 cents Julien Merci. Oui c'est long, une copie bout a bout des messages (doublons textes, bla bla des anti-virus, ...) c'est 65 pages A4 en 12pt. D'accord pour le wiki, mais une mise en forme s'impose avec un traitement de texte d'abord. Le navigateur sous Writer est par exemple pratique pour isoler les liens, ... J'ai peur que travailler directement sur une page du wiki soit galre. Si nous l'avions complte au fur et mesure oui. Benot R. Merci Benot pour tout ce boulot. J'ai amorc une mise en forme sommaire en m'appuyant sur ton PDF. Pour l'instant la page est ici : http://wiki.openstreetmap.org/wiki/User:Vincent_95/draft/synthese_limites_administratives Il faudrait la placer ailleurs (mais o ? je n'ai pas pris l'initiative) puis faire voluer le contenu de la page. Super ! Merci. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr Ce message entrant est certifi sans virus connu. Analyse effectue par AVG - www.avg.fr Version: 9.0.856 / Base de donnes virale: 271.1.1/3164 - Date: 09/28/10 08:34:00 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] qualité de la carte
Dsol mais je remets ma cape de ronchon rleur. Le 29/09/2010 22:18, Pierre BOIZOT a crit: Merci pour cette Belle intervention. qui mon sens nous ramne plusieurs point dj dbattu dans diverses interventions. [...] Ma rponse : parce que le processus est itratif, que l'organisation doit tre souple pour intgrer de nouveaux contributeurs, parce qu'aujourd'hui il est plus important d'engranger des donnes mme partielles, mme fausses que de qualifier finement. Itratif n'implique pas de ne jamais s'arrter pour regarder en arrire et corriger. Donc, pour ma part : - l'itratif bon dos, parlez en avec les Matres des mthodes agiles, il y en a sur la liste. Itratif n'implique pas foutoir ; - l'intgration est pour le moins souple mais elle ne facilite pas l'intgration (certains ont t reus de manire trs souple sur la liste) ; - jouer celui "qu'a la plus grande" en comparant la taille des fichiers Allemagne/France/Angleterre, remplir la pelle puis rflchir en 2020, n'est pas une solution. La seule solution c'est de bosser : - faire UN vrai tutoriel, sans esprer cela des CUM format A5 destins aux expriments, - chercher des rfrences, - discuter des solutions argumentes, - mettre jour le wiki, - le tout sans illres en gardant un esprit critique face l'existant. [...] Une mailling liste qui soit clater en au moins 5 traffics: Dev Debutant Question Mapping general Question mapping France Info diverse, annonces. La liste "dev" dj un pied dans la tombe. La dernire discussion prog s'est tenue sur cette liste. La mailling liste "dbutants" reviendrait passer ses journes rpondre aux mme questions, autant faire LE tutoriel ou au moins une FAQ ferai trs bien l'affaire. Quant aux autres... Salut a tous. Pierre Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Tag:boundary=administrative / limites en France
Le 29/09/2010 23:08, Vincent de Chateau-Thierry a crit: Le 29/09/2010 09:17, sly (sylvain letuffe) a crit : On mercredi 29 septembre 2010, Vincent de Chateau-Thierry wrote: J'ai amorc une mise en forme sommaire en m'appuyant sur ton PDF. Pour l'instant la page est ici : http://wiki.openstreetmap.org/wiki/User:Vincent_95/draft/synthese_limites_administratives Il faudrait la placer ailleurs (mais o ? je n'ai pas pris l'initiative) puis faire voluer le contenu de la page. J'ai dj des trucs dire fond/forme ;-) On la place quelque part de rang ? Lie depuis cette page par exemple : http://wiki.openstreetmap.org/wiki/WikiProject_France/Limites_administratives/Tracer_les_limites_administratives ? Benot a plac un lien, qui pour l'instant pointe vers la page dj cite [1]. La page peut changer de place ou rester, je n'ai pas trop d'avis, tant entendu que c'est en soi une page de discussion / maturation du sujet. Que les experts en organisation de wiki n'hsitent pas mettre de l'ordre. Quand le contenu de la page sera stabilis, on aura (esprons) un consensus sur une manire de grer les EPCI, ou au moins des argumentaires lisibles et synthtiques pour que d'autres que les participants la discussion puissent se faire un avis. Enfin, le moment venu, il faudra augmenter la page de mthodo sur les limites administratives, voire crr une section ddie aux EPCI. La discussion est ouverte, sur la forme ET sur le fond :-), pour l'instant donc ici [1]. Merci pour vos contributions, vincent [1] : http://wiki.openstreetmap.org/wiki/User:Vincent_95/draft/synthese_limites_administratives ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr Bonjour, T'es le bienvenu pour les remarques Sly. J'ai mis jour la page, mais je suis loin d'avoir termin, c'est encore en chantier. Maintenant c'est dodo. N'hsitez pas ajouter vos remarques, ou les exprimer sur la liste. Il est parfois difficile de ne pas tre partisan au moment de la synthse, mme avec de la bonne volont. Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)
Le 27/09/2010 22:10, Christian Rogel a crit: Le 27/09/10 21:52, Benot ROUSSEAU a crit : Cette catgorie de commune souvent oublie dans les dcomptes de communes ncessite, elle-seule, d'avoir un chelon infra-communal. Je ne connais pas, je vais chercher une source. As-tu un exemple ? Le Wikipdia est une source souvent de valeur : http://fr.wikipedia.org/wiki/Commune_associe Les communes associes ont t cres en 1971 710 communes associes (a a tendance diminuer) 2 communes ont 9 communes associes (Isigny-le-Buat et Val-de-Meuse) et 2 autres en ont huit! Certains dpartements doivent n'en avoir aucune. En Finistre, il n'y a que Kernvel, commune associe de Rosporden. Christian Je dirai oui en tant que limite administrative au vu de "un officier d'tat civil et officier de police judiciaire,"... Je ne souponnais mme pas l'existence de ces communes associes ! Merci Christian pour cette info. Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)
Le 27/09/2010 22:43, Pieren a crit: 2010/9/27 Benot ROUSSEAU adressepossi...@free.fr Stop au suivi systmatique ! Est-ce que le sens des quartiers Allemands est le mme que celui en France ? ? ? Connaissant la rputation Allemande face a la latine, je pense quelle est cohrente. Pour autant, sans nous mettre des illres,et ne pas allez voir autour ce qui se fait, on peux aussi rflchir par nous mme. Par exemple, quand milie nous parle des usages de subarea dans le dcoupage en Espagne elle ne semble franchement prte l'appliquer en France. Si on regarde le tableau ici: http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative j'ai rapidement compt les admin_level correspondant la municipalit: 1 pays au niveau 5, 2 au niveau 6, 5 au niveau 7, 40 au niveau 8, 1 au niveau 9 (l'Australie), 1 au niveau 10. Le solde contient ceux que je n'ai pas pu dterminer (comme la Chine) ou qui est inapplicable ou indtermin. Le niveau administratif infrieur est souvent le "suburb" qui se trouve mieux rpartit entre les admin_level 9 et 10. Bonne ide ton tableau. Merci. Notez tout en bas de la page "Current import of US states has begun to use an extension, border_type=* to give the name of the boundary's type." qui a la mme vocation ma proposition d'ajouter "nature". Mais cela exite t'il encore ou est-ce une trace archologique ? Je n'ai pas vrifi. En tous cas d'autres pays se posent des questions sur l'usage de boundary=administrative pour des entits de mme niveau administratif. Donc, part quelques cas qui se distinguent, on a conserv une structure peu prs cohrente de niveau 8 pour les municipalits (NUTS 5, y compris en Allemagne), 6 pour les dpartements (NUTS 3) et 4 pour les rgions (NUTS 2) (http://en.wikipedia.org/wiki/Nomenclature_of_Territorial_Units_for_Statistics). Les allemands sont deux fois dans le tableau avec 10 ou 11 niveaux. J'en conclus qu'il y a controverse chez-eux aussi (pour ce qui concerne les niveaux infrieurs au Gemeinde). Merci pour le lien NUTS. Ma remarque est que comme pour l'INSEE, c'est un dcoupage vocation statistique. Il sert beaucoup comme rfrence un dcoupage administratif et peux conduire des aberrations et des contresens. Alors, c'est vrai, on peut adapter les tags nos particularismes mais j'aimerais que nous conservions au moins les niveaux 2,4,6,8 comme ils sont actuellement. Pour le reste, la discussion est ouverte (et ne m'intresse pas beaucoup, je dois avouer). Les spcification "fr" actuelles pour 2,4,6 et 8 ne posent de pb personne sous l'tiquette boundary=administrative avec le seul tag admin_level, telles quelles sont dfinies actuellement. Les discussions actuelles pose la question des EPCI en 7, qui devraient tre en 8, des quartiers qui ne devraient pas tres tiquetes systmatiquement en divisions administratives, des arrondissements dpartementaux et communes associes qui ne sont pas reprsents et de l'usage qui y inclus parfois les cantons. Pieren Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Tag:boundary=administrative / limites en France
J'ai chang l'objet de la discussion. Vous trouverez ici la premire partie de la synthse : http://adresseimpossible.free.fr/fichiers/osm/Synth%C3%A8se%20BA.pdf Indiquez moi les erreurs, les oublis et les traitements partisans des sujets. Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Tag:boundary=administrative / limites en France
Le 29/09/2010 02:27, THEVENON Julien a crit: De : Benot ROUSSEAU adressepossi...@free.fr J'ai chang l'objet de la discussion. Vous trouverez ici la premire partie de la synthse : http://adresseimpossible.free.fr/fichiers/osm/Synth%C3%A8se%20BA.pdf Indiquez moi les erreurs, les oublis et les traitements partisans des sujets. Beau travail de synthese vu le nombre de mails echanges ! Par contre est ce qu une page wiki ne serait pas plus simple pour permettre aux differentes intervenants d eventuellement completer la synthese, avec commentaires dans la partie discussion. Cela a aussi l avantage de laisser une trace dans la doc My 2 cents Julien Merci. Oui c'est long, une copie bout a bout des messages (doublons textes, bla bla des anti-virus, ...) c'est 65 pages A4 en 12pt. D'accord pour le wiki, mais une mise en forme s'impose avec un traitement de texte d'abord. Le navigateur sous Writer est par exemple pratique pour isoler les liens, ... J'ai peur que travailler directement sur une page du wiki soit galre. Si nous l'avions complte au fur et mesure oui. Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)
Le 26/09/2010 22:45, Vincent de Chateau-Thierry a crit: Le 26/09/2010 02:30, Benot ROUSSEAU a crit : Selon moi, le niveau 7 correspondrait aux arrondissements dpartementaux. Voir : http://fr.wikipedia.org/wiki/D%C3%A9concentration#Cadre chapitre "Cadre" Je suis d'accord avec toi, et mme avec moi :-), sachant que je proposais ceci au dbut du fil. Il reste pour appliquer a statuer sur les com'com qui occupent cet admin_level [1]. Comment continuer sur le sujet des com'com ? Il y a -au moins- deux propositions de modlisation de la relation, par boundary=* et par region=*, ainsi que des tags spcifiques tablir (typologie des EPCI, etc). Une nouvelle page de wiki et son onglet discussion ? :-). Pour ma part sans enlever les rfrences au COG, je me baserai sur le dcoupage du chapitre "Cadre" de http://fr.wikipedia.org/wiki/D%C3%A9concentration#Cadre avec les communes et les arrondissements municipaux en plus. Il y aurait ainsi seulement 6 niveaux administratifs : A - Pays, B - Rgions, C - Dpartements(Prfectures), D - Sous-Prfectures (sachant qu'elles sont "sous tutelle" de la Prfecture au niveau dpartemental), E - Communes, F- Arrondissements municipaux. Avec une hsitation pour les Sous-prfectures... Avec ce dcoupage, les territoires s'emboitent, les limites communales sont partages entre les niveaux et il me semble que le sens premier de boundary=administative est respect et comprhensible. +1 vincent [1] : http://wiki.openstreetmap.org/wiki/WikiProject_France/Tracer_les_limites_administratives#En_proposition_:_.C3.89tablissements_publics_de_coop.C3.A9ration_intercommunale Je vais dj prparer une synthse avec des exemples pour que tout le monde puisse suivre et voir, si, se rpondre sur des points de dtail on ne s'est fourvoys globalement. Un vote serait ensuite une bonne chose... Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)
Le 27/09/2010 20:34, Pierre-Alain Dorange a crit: Le 26 sept. 10 14:25, Benot ROUSSEAU a crit : Du coup je suis all voir la source :http://www.legifrance.gouv.fr/affichCodeArticle.do?cidTexte=LEGITEXT06070633idArticle=LEGIARTI06390128dateTexte=categorieLien=cid. Pourquoi pas. Mais strictement parlant, en boundary=administrative, nous ne devrions tracer que les contours que des quartiers ayant un Conseil de quartier qui a obtenu des dlgations de la Mairie. Admin_level poserait alors le mme problme que pour les EPCI puisque ce n'est pas un sous-niveau administratif la Commune mais un dcoupage territorial. Les quartiers sont ce qu'on appelle des lieux-dit dans les communes rurales, il devraient tre traits en tant que tel mme si la densit de population est plus leve en ville. Je ne suis pas sur du bien comprendre cette "obligation" de voir un systme strictement hirarchique dans les diffrents niveaux des boundary=administrative. Rien n'oblige a suivre cette ide. boundary=administrative ne dfinit que des frontires administratives. Un quartier avec conseil local et budget autonome entre priori dans ce cadre, de mme qu'un arrondissement prfectoral ou mme un EPCI... Euh, j'attends de faire la synthse, mais personne n'a dit a. C'est venu dans la discussion essentiellement comme des questionnements. Ce qui a t dit c'est qu'on ai un systme qui puisse intgrer l'ordre tabli au niveau international sans le bouleverser. Donc implmenter le schma boundary=administrative pour tout ce qui y entre naturellement. Ce qui bloque rellement, mon avis, c'est l'usage des admin_level (3 10)... laissant pas assez de places actuellement pour y insrer d'autres frontires administratives. On notera que quelques pays (allemagne et pays-bas) ont dj tendu au admin_level=11 pour les quartiers. Stop au suivi systmatique ! Est-ce que le sens des quartiers Allemands est le mme que celui en France ? ? ? Connaissant la rputation Allemande face a la latine, je pense quelle est cohrente. Pour autant, sans nous mettre des illres,et ne pas allez voir autour ce qui se fait, on peux aussi rflchir par nous mme. Par exemple, quand milie nous parle des usages de subarea dans le dcoupage en Espagne elle ne semble franchement prte l'appliquer en France. Sur la discussion actuelle on voit bien que les dfinitions sont dlicates et que certains niveaux admin ne sont pas compatible avec la rgle "implicite" d'inclusion dans les niveaux suprieurs et infrieurs (les cantons par exemple). Les cantons ne sont pas des limites administratives mais lectorales. Voir les discussions prcdentes ou la synthse venir. Donc effectivement ils sont dlicats intgrer car ils ne devraient pas y tre intgrs. J'aurai tendance a dire qu'il faudrait conserver les systme actuels des boundary pour les niveaux dj utiliss (rgion, dpartement, commune) y dfinir 7 plutt pour les arrondissements prfectoraux. Et exprimenter le systme propos de relation region pour les EPCI par inclusion des relation de communes. Les deux ne sont pas incompatibles. On peux passer de l'un l'autre donc il faudra trancher mais les consquences seront minimes si l'usage le choix s'avrait tre le moins pratique. On pourrait passer l'autre modle par traitement automatique. Mais on pourrait aussi imaginer de n'utiliser la relation frontire que pour les communes et les cantons et de construire les autres niveaux par addition (relation type region) des communes qui constitue. Evidemment a pose certains problmes (voqu par d'autres) puisque toutes les communes ne sont pas dfinis ce jour, mais c'est thoriquement un modle conforme. Toutefois je suis d'accord qu'il ne puisse s'appliquer que pour un nombre restreint de communes (EPCI par exemple). C'est dans le tas des propositions. Je ne comprends pas le sens donner "Toutefois je suis d'accord qu'il ne puisse s'appliquer que pour un nombre restreint de communes (EPCI par exemple).".
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)
Le 27/09/2010 21:31, Christian Rogel a crit: Le 26/09/10 14:25, Benot ROUSSEAU a crit : Du coup je suis all voir la source : http://www.legifrance.gouv.fr/affichCodeArticle.do?cidTexte=LEGITEXT06070633idArticle=LEGIARTI06390128dateTexte=categorieLien=cid http://www.legifrance.gouv.fr/affichCodeArticle.do?cidTexte=LEGITEXT06070633idArticle=LEGIARTI06390128dateTexte=categorieLien=cid . Pourquoi pas. Mais strictement parlant, en boundary=administrative, nous ne devrions tracer que les contours que des quartiers ayant un Conseil de quartier qui a obtenu des dlgations de la Mairie. Admin_level poserait alors le mme problme que pour les EPCI puisque ce n'est pas un sous-niveau administratif la Commune mais un dcoupage territorial. Les quartiers sont ce qu'on appelle des lieux-dit dans les communes rurales, il devraient tre traits en tant que tel mme si la densit de population est plus leve en ville. Benot R. Je n'ai pas eu le courage d'aller voir la source, mais je signale que le territoire infra-communal qui doit tre trac en premier lieu, c'est celui de la commune associe, car elle seule a une existence administrative indiscutable : son corps lectoral lit des conseillers particuliers qui s'intgrent au conseil municipal gnral. Cette catgorie de commune souvent oublie dans les dcomptes de communes ncessite, elle-seule, d'avoir un chelon infra-communal. Je ne connais pas, je vais chercher une source. As-tu un exemple ? Si un niveau 11 a dj t mis en place dans le monde, prenons-le, mais en vrifiant que l'chelon "communal" allemand correspond bien nos communes, i.e. tre l'avant-dernier chelon de la pyramide. Par ailleurs, je redis que la notion de quartier est floue (sauf Paris) : dans ma ville, on a pris la mauvaise habitude d'appeler "quartier" les anciennes communes fusionnes (qui ont un adjoint spcial),a fait de beaux "quartiers" de 3000 ha, mais quid des quartiers rels, au raz de la vie des gens? A la campagne, au moins par ici, il y avait (a?) des quartiers regroupant un nombre variable de hameaux desservis par une chapelle; En tout cas, je ne vois pas la correspondance quartier/lieu-dit. Christian Habitant d'un immense "quartier", 1/4 urbain - 3/4 rural Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)
Le 26/09/2010 11:51, Vincent Pottier a crit: On 26/09/2010 02:30, Benot ROUSSEAU wrote: Pour garder homogne le "grand tableau mondial" ok. Selon moi, le niveau 7 correspondrait aux arrondissements dpartementaux. Voir : http://fr.wikipedia.org/wiki/D%C3%A9concentration#Cadre chapitre "Cadre" pour ce qui est du thme de l'administration. Pour ce qui est des quartiers en niveau 10, je ne sais pas quoi en penser, car je ne sais pas s'il existe "lgalement" des organismes d'administration des quartiers. Les Conseils de quartier par exemple, n'ont qu'un avis consultatif selon http://fr.wikipedia.org/wiki/Conseil_de_quartier. Les conseils de quartiers peuvent avoir un petit bout d'administration local, particulirement en animation : "l'initiative locale" un budget vot en amont par le conseil municipal. Et, en lien avec un adjoint, prendre des dcisions mineurs sur l'amnagement, l'entretien... L'importance dpend de la politique municipale. Du coup je suis all voir la source : http://www.legifrance.gouv.fr/affichCodeArticle.do?cidTexte=LEGITEXT06070633idArticle=LEGIARTI06390128dateTexte=categorieLien=cid . Pourquoi pas. Mais strictement parlant, en boundary=administrative, nous ne devrions tracer que les contours que des quartiers ayant un Conseil de quartier qui a obtenu des dlgations de la Mairie. Admin_level poserait alors le mme problme que pour les EPCI puisque ce n'est pas un sous-niveau administratif la Commune mais un dcoupage territorial. Les quartiers sont ce qu'on appelle des lieux-dit dans les communes rurales, il devraient tre traits en tant que tel mme si la densit de population est plus leve en ville. -- FrViPofm Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)
Le 25/09/2010 14:16, Vincent de Chateau-Thierry a crit: Bonjour, Le 25/09/2010 13:27, Benot ROUSSEAU a crit : Pour les subarea je n'est remarqu aucun consensus, Pierre Quenee nous a propos, comme base de travail, l'adaptation sur un modle existant et milie voqu subarea en nous disant "ca ne me plait pas mais a existe par ailleurs". Oui, tout fait. Mais hier soir je disais : "_si_ il y a consensus". Je reformule :p avec avoir en prime : je n'ai pas remarqu qu'on se dirigeai vers un consensus... Mis a part le modle proposer qui reste affiner, renommer les tags, le complter, il n'y a pas incohrence avec le modle actuel bien au contraire c'est un complment indispensable ! C'est le modle actuel qui nous amne l'incohrence. Soit en hirarchisant de haut en bas : des lments qui pour certains ne sont pas des limites administratives ou des lment qui devraient tre au mme niveau administratif sur des niveaux diffrents. Mme si nous rajoutions une numrotation de niveau a plus de 10 chelons, ce serait faux ! Ce n'est pas parce que le modle qui fait consensus dans la base est limit que nous devons le reproduire btement l'infini en entrant des donnes dedans au chausse pied en considrant que c'est un fourre tout. Tagguer un admin level 7 pour une communaut de commune est une erreur si les communes sont en 8 ! Ou alors il faut complter le modle actuel en ajoutant des complments d'information pour distinguer les limites administratives places au mme niveau. Je viens de relire ce que je disais hier, et a prte confusion, je comprends ta rponse. Je ne parlais (ne voulais parler) que de la manire de construire l'objet com'com : par une relation de type boundary=*, ou par une autre de type region=*. Il est clair pour moi que dans un cas comme dans l'autre, le tag admin_level=* n'a rien faire dans cette relation. En revanche, il est prsent dans chacun des membres de la relation. En essayant de reformuler : "quand on agrge des communes pour construire un dpartement, on utilise boundary=*, pourquoi ne pas utiliser aussi boundary="autre chose" pour agrger des communes l'chelle d'une com'com." L, il va me falloir du temps pour simuler avec un cas concret pour bien comprendre avant de rpondre. La solution de la relation est trs pratique et flexible puisqu'elle vite d'avoir ncessairement ressaisir les contours en incluant les contours des communes. L'argument comment on fait s'il n'y pas de contours de communes ne tient pas, il faut les tracer. Facile dire, et j'aimerais tre d'accord avec a, mais il faut tre lucide, la courbe de croissance des limites admin est plutt faible. Construire une version temporaire de com'com, avec les nodes place=* permet dj d'identifier la com'com et ses communes constituantes (via leur ref:INSEE) ainsi que, au mieux, ses domaines de comptence. Le jour o les contours de commune existent, on remplace le node place=* par la relation boundary=administrative, mais au moins comme a on ne cr pas d'adhrence entre les objets com'com et limite admin. Utiliser le node place=* est une suggestion pour grer une situation transitoire, pas ce qui devrait tre le modle dfinitif. Courbe de croissance faible oui. Je m'loigne du sujet prcis pour illustration mavie Pour exemple je vais prendre mon comportement face aux adresses et aux rivires. Les rivires j'ai essay, j'ai arrt aprs avoir lu le wiki et ses 50 (exagr) manires de faires et les discussions sur la liste qui en amenaient encore d'autres. Les adresses c'est en stanby alors que j'ai les moyens d'importer des millions d'adresses (j'ai fait les essais) automatiquement car le modle "Karl", est pass de proposition norme et aujourd'hui standard indboulonnable. Il me semble inappropri, car lui aussi mlange diffrents type d'adresses (administrative, gographique, postales), dans quelque chose qui devient systmatiquement contradictoire entre ceux qui militent pour l'administrative, la postale et la gographique. Soit je fais le forcing en imposant un nouveau standard en important plus d'adresses que tous les autres sur un schma perso, soit j'attends un
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)
Le 25/09/2010 15:09, Vincent de Chateau-Thierry a crit: Le 25/09/2010 14:38, Vincent Pottier a crit : Il me semble qu'il y a une diffrence de nature entre un dpartement et une communaut de commune. Un dpartement n'est pas une agrgation de commune, mais un territoire, une collectivit territoriale dont les limites concident avec elles de M, N Une communaut de commune, quant elle, est une agrgation de communes laquelle adhrent M, N... Posons-nous la question : si on voulait un jour rcuprer ces informations de dcoupage administratif comment voudrions nous les voir reprsentes ? Je ne parle pour l'instant que du dcoupage, ensuite on verra comment intgrer les informations connexes. Le dcoupage administratif de manire gnral est un arbre, pas une pile. On sait dcrire un arbre en XML. Commenons par la structure avec des tags fictifs pour dbuter, piochons dans l'existant puis nous dfinirons ce qui manque. Oui. Mon raisonnement pour parler d'agrgation est voir sous l'angle des primaires gomtriques dans la base, avec en tte une question : comment rendre la base cohrente en terme de construction, la fois pour ceux qui la constituent (nous) et pour ceux qui s'en servent/serviront (nous aussi, entre autres). Dans les 2 cas, depts et com'com, la construction _dans osm_se fait en assemblant un puzzle dont les pices sont des communes (*). Et je ne trouve pas d'argument pour dire : en fonction du nombre de pices du puzzle, je vais prendre des pices "limites" ou des pices "surfaces". Sous l'angle des primaires gomtriques, difficile de trancher, car dans le cas des limites administratives puisque dfinissons des limites (frontires) de surfaces (territoires), qui donc doivent boucler. Ces limites donc pourraient trs bien tre des dfinies en surfaces sans en changer le sens. Pour ma part je prfrerai des area en place des boundary, mais dfinir des boundary n'est pas moins illogique.. Mais bon, je ne suis pas spcialiste... Alors on est 2 :-) vincent (*) Je mets de ct la dmarche "Cartographes Associs" qui partait directement de l'chelle "dpartement" pour les constituer, vu qu'on supprime cette source doucement mais srement, pour lui substituer une gomtrie et un maillage plus fins. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr Ce message entrant est certifi sans virus connu. Analyse effectue par AVG - www.avg.fr Version: 9.0.856 / Base de donnes virale: 271.1.1/3158 - Date: 09/25/10 08:34:00 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)
Autre proposition : Actuellement pour les limites administratives des communes ont utilise quelque chose : des way dcrits comme suit : way id="34630977" visible="true" timestamp="2009-05-17T13:35:16Z" version="1" changeset="1221617" user="monsieur a" uid="97101" nd ref="393099429" / nd ref="393099430" / nd ref="393099441" / nd ref="393099442" / nd ref="393099443" / tag k="admin_level" v="8" / tag k="boundary" v="administrative" / tag k="source" v="cadastre-dgi-fr source : Direction Gnrale des Impts - Cadastre ; mise jour : 2008" / /way des relations d'appartenance dcrites comme suit : relation id="132343" visible="true" timestamp="2009-12-10T20:34:46Z" version="6" changeset="3344785" user="MrsPeel" uid="206119" member type="way" ref="34283363" role="" / member type="way" ref="34283360" role="" / member type="way" ref="34330022" role="" / member type="way" ref="34393976" role="" / member type="way" ref="34630977" role="" / tag k="admin_level" v="8" / tag k="boundary" v="administrative" / tag k="name" v="Quinay" / tag k="ref:INSEE" v="86204" / tag k="source:ref:INSEE" v="COG" / tag k="type" v="boundary" / /relation relation id="145018" visible="true" timestamp="2009-11-09T11:58:47Z" version="4" changeset="3072415" user="EtienneChoveBot" uid="183561" member type="way" ref="34330016" role="" / member type="way" ref="34630977" role="" / member type="way" ref="34517049" role="" / member type="way" ref="34330421" role="" / member type="way" ref="34517047" role="" / member type="way" ref="34630990" role="" / tag k="addr:postcode" v="86580" / tag k="admin_level" v="8" / tag k="boundary" v="administrative" / tag k="name" v="Vouneuil-sous-Biard" / tag k="ref:INSEE" v="86297" / tag k="source:addr:postcode" v="source of postcode is from osm nodes" / tag k="source:ref:INSEE" v="source of ref is from osm nodes" / tag k="type" v="boundary" / /relation Pourquoi ne pas simplement ajouter des relations com2com comme suit avec un tag "nature" (les anglophones traduiront) pour les distingues des communes au mme niveau et ca rsout le pb : relation id="145019" visible="true" timestamp="2009-11-09T11:58:48Z" version="4" changeset="30724185" user="quidam" uid="1883561" member type="way" ref="34630977" role="" / member type="way" ref="" role="" / member type="way" ref="" role="" / member type="way" ref="" role="" / member type="way" ref="" role="" / member type="way" ref="" role="" / tag k="admin_level" v="8" / tag k="boundary" v="administrative" / tag k="name" v="Communaut de communes du val machin" / tag k="ref:INSEE" v="xxx" / tag k="type" v="boundary" / tag k="nature" v="ECPI" / /relation Ca ne change quasiment rien au schma actuel puisque c'est de la mme veine que le tag natural=coastline. Pas de region pas de subarea, ... et si j'ai bien compris c'est la proposition exprime par Vincent de Chteau-Thierry. Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)
compris. Le 25/09/2010 19:10, Emilie Laffray a crit: Petite clarification. Ce qui me gne c'est l'utilisation qu'il en fait en Espagne et en Pologne o les donnes gomtriques sont mlanges avec des relations avec le rle subarea. Pour moi cela n'a aucun sens. Dans le cas d'une relation boundary, si les donnes go ne sont pas mlanges, a ne me gne pas. Emilie Laffray On 25 Sep 2010 12:28, "Benot ROUSSEAU" adressepossi...@free.fr wrote: ___ 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 Ce message entrant est certifi sans virus connu. Analyse effectue par AVG - www.avg.fr Version: 9.0.856 / Base de donnes virale: 271.1.1/3158 - Date: 09/25/10 08:34:00 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites,, communales)
Le 25/09/2010 17:24, Vincent de Chateau-Thierry a crit: Le 25/09/2010 16:51, Benot ROUSSEAU a crit : Autre proposition : Actuellement pour les limites administratives des communes ont utilise quelque chose : des way dcrits comme suit : way id="34630977" visible="true" timestamp="2009-05-17T13:35:16Z" version="1" changeset="1221617" user="monsieur a" uid="97101" nd ref="393099429" / nd ref="393099430" / nd ref="393099441" / nd ref="393099442" / nd ref="393099443" / tag k="admin_level" v="8" / tag k="boundary" v="administrative" / tag k="source" v="cadastre-dgi-fr source : Direction Gnrale des Impts - Cadastre ; mise jour : 2008" / /way des relations d'appartenance dcrites comme suit : relation id="132343" visible="true" timestamp="2009-12-10T20:34:46Z" version="6" changeset="3344785" user="MrsPeel" uid="206119" member type="way" ref="34283363" role="" / member type="way" ref="34283360" role="" / member type="way" ref="34330022" role="" / member type="way" ref="34393976" role="" / member type="way" ref="34630977" role="" / tag k="admin_level" v="8" / tag k="boundary" v="administrative" / tag k="name" v="Quinay" / tag k="ref:INSEE" v="86204" / tag k="source:ref:INSEE" v="COG" / tag k="type" v="boundary" / /relation relation id="145018" visible="true" timestamp="2009-11-09T11:58:47Z" version="4" changeset="3072415" user="EtienneChoveBot" uid="183561" member type="way" ref="34330016" role="" / member type="way" ref="34630977" role="" / member type="way" ref="34517049" role="" / member type="way" ref="34330421" role="" / member type="way" ref="34517047" role="" / member type="way" ref="34630990" role="" / tag k="addr:postcode" v="86580" / tag k="admin_level" v="8" / tag k="boundary" v="administrative" / tag k="name" v="Vouneuil-sous-Biard" / tag k="ref:INSEE" v="86297" / tag k="source:addr:postcode" v="source of postcode is from osm nodes" / tag k="source:ref:INSEE" v="source of ref is from osm nodes" / tag k="type" v="boundary" / /relation Pourquoi ne pas simplement ajouter des relations com2com comme suit avec un tag "nature" (les anglophones traduiront) pour les distingues des communes au mme niveau et ca rsout le pb : relation id="145019" visible="true" timestamp="2009-11-09T11:58:48Z" version="4" changeset="30724185" user="quidam" uid="1883561" member type="way" ref="34630977" role="" / member type="way" ref="" role="" / member type="way" ref="" role="" / member type="way" ref="" role="" / member type="way" ref="" role="" / member type="way" ref="" role="" / tag k="admin_level" v="8" / tag k="boundary" v="administrative" / tag k="name" v="Communaut de communes du val machin" / tag k="ref:INSEE" v="xxx" / tag k="type" v="boundary" / tag k="nature" v="EPCI" / /relation Ca ne change quasiment rien au schma actuel puisque c'est de la mme veine que le tag natural=coastline. Pas de region pas de subarea, ... et si j'ai bien compris c'est la proposition exprime par Vincent de Chteau-Thierry. Euh...:-) Une diffrence avec ce que je propose, c'est que dans une relation com'com base sur des limites, il faut le tag type=boundary (puisqu'on parle de limites), mais il ne faut surtout pas boundary=administative. D'o ma proposition de boundary=local_authority. Aprs oui, si on regarde par exemple la dfinition actuelle de Saint-Quentin-en-Yvelines : relation id="49584" visible="true" timestamp="2010-07-18T18:53:48Z" version="24" changeset="5253787" user="ToineToine" uid="313558"
Re: [OSM-talk-fr] Carte de grasse
Le 26/09/2010 02:03, Vincent Meurisse a crit: bonjour, Profitant d'un peu de temps libre ce WE, je me suis amus faire une petite carte interactive de Grasse. Au menu: - Carte OSM - Orthophotos - Intgration avec openstreetbug pour permettre au plus grand nombre de signaler les erreurs Les utilisateurs de navigateurs modernes (chrome, opera ou safari) aurons la joie de pouvoir changer l'opacit de la couche OSM avec un slider. Les autres devrons se contenter d'un champ texte. Amusez vous bien sur http://map.meurisse.org/grasse.html Beau boulot ! J'ai not quelques dcalages de btiments juste pour tester. Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites communales)
Dans ce cas on arrte les routes :p "avec le nombre de projets de dviations et de constructions, ca ne sert rien". La rforme territoriale elle se fera, mais a ne rsoudra pas nos pb pour autant de prendre des dcisions quant comment l'arbre. Les mmes problmes se poseront. Benot R. Le 23/09/2010 10:09, g.d a crit: me demande s'il est utile Hm, ouaipch, probablement tu n'as pas tort... Peut-tre vaudrait-il mieux, d'attendre voir ce qui adviendra, et s'atteler dcrire le rsultat ensuite, une fois qu'ils auront dcid, au lieu de maintenant y engager la sueur du front, pour dans quelque temps devoir re-modifier ? Parfois, il peut tre urgent, d'attendre. L'nergie des osm'eurs est tellement prcieuse, et nous avons dj tellement faire, re-caoutchouter les ways (and means...) suite aux imports en masse, viter que les rues traversent les maisons, viter que l'arrt de bus se retrouve dans l'arrire-cour, viter que des hameaux se retrouvent dans du landuse:forest, "port du casque obligatoire" ? , il y a du boulot sur la planche... Oups, pardon ! c'est juste my two cents ! En aucun cas je voudrais empcher qui que ce soit, de faire ce qu'il veut faire ! C'est simplement, que je trouverais triste, si de l'nergie prcieuse soit engage l o probablement dans deux, trois ans il faudra reprendre, et que personne pour l'instant encore ne sait ni quoi ni comment... Amicalement Gerhard --- Le 23 sept. 2010 00:44, Christian Rogel a crit : Dans une discussion similaire, j'ai rappel que l'actuelle rforme territoriale a pour ambition de supprimer le canton et de le remplacer par un territoire dans lequel serait lu un conseiller territorial. Il a t avanc que les communauts de communes (aprs des fusions obligatoires aprs 2013) pourraient tre cette circonscription. De mauvaises langues disent que la rforme sera finalement saborde. En attendant la fin de ce suspense, je me demande s'il est utile de s'intresser une bagarre canton versus communaut. Christian ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr Ce message entrant est certifi sans virus connu. Analyse effectue par AVG - www.avg.fr Version: 9.0.851 / Base de donnes virale: 271.1.1/3152 - Date: 09/22/10 08:34:00 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites, communales)
Le 23/09/2010 09:40, Pierre Quenee a crit: Bonjour, Est ce que le codage des Communauts de Communes peut tre cod en relation pre ? par exemple : http://www.openstreetmap.org/api/0.6/relation/1187442 auquel cas l'intret d'un niveau 7 devient relatif. En effet, si (long) terme les communauts devait se substituer aux communes l'application du mme niveau 8 pour cette structure se rvlerait pertinente. Par ailleurs j'ai cru comprendre que les outils de rendu avait des problmes avec ces structures complexes, mais est ce une raison pour ne pas les utiliser ? Quelles rles (au sens JOSM) doit t'on appliquer chaque membre (Validator ne semble pas aimer les roles vides) Merci pour vos clairages ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr +5 L'ide de relation pour les communauts de communes, les communauts d'agglomrations, ... est une bonne ide qui reprsente bien la structure. Ca me semble cohrent. Le mme niveau d'admin rend bien compte de la situation actuelle ou ces communaut se substutuent sur certains point de gestion, le ramassage des ordures, les transports en commun, ... Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Possibilité d'extraction des lim ites de départements avec la XAPI OSM ?
J'ai charg cette zone sous JOSM et a premire vue JOSM ne charge
pas d'admin_level 6 sur cette zone. J'ai trouv des 4 et des 8 ...
Essai avec l'un de ces niveaux administratif. Il n'y a peut tre
simplement pas de niveau 6.
Benot R.
Le 23/09/2010 12:13, Nicolas Moyroud a crit:
sly (sylvain letuffe) a crit :
Couche vectorielle ou bitmap ?
Une couche vectorielle.
En fait je viens de tester avec une toute petite zone, et a me
fait toujours la mme erreur. a n'a pas l'air li la taille de
la zone. Du coup, je ne comprends pas vraiment pourquoi a ne
marche pas...
Voici un extrait de mon code js utilisant OpenLayers :
var dept = new OpenLayers.Layer.Vector(
"Dpartements",
{
strategies:[
new OpenLayers.Strategy.Fixed(),
],
protocol: new OpenLayers.Protocol.HTTP({
url:
"http://xapi.openstreetmap.org/api/0.6/way[admin_level=6][bbox=2.98899,43.70518,3.17507,43.85118]",
format: new OpenLayers.Format.OSM()
}),
projection: new OpenLayers.Projection("EPSG:4326"),
styleMap:new OpenLayers.StyleMap({
"default": {
strokeColor: "#00"
}
})
}
);
map.addLayer(dept);
J'ai aussi essay en ajoutant dans l'URL
[boundary=administrative], mais a ne change rien.
je ferais comme a :
- rcupration d'un fichier france-large.osm
- import avec osm2pgsql des frontires uniquements
- utilisation de la fonction st_simplify de postgis pour
pr-calculer plusieurs niveaux de dtails
Au choix, utilisation de mapnik pour faire un rendu bitmap, ou
utiliser les fonctions openlayers d'affichage de polygones
En fait mon ide c'tait d'viter d'utiliser un serveur postgres
juste pour a. Mais si je n'arrive pas le faire directement avec
la XAPI je m'y rsoudrais...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
Ce message entrant est certifi sans virus connu.
Analyse effectue par AVG - www.avg.fr
Version: 9.0.856 / Base de donnes virale: 271.1.1/3153 - Date: 09/22/10 20:40:00
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites, communales)
Le 23/09/2010 13:25, Pierre-Alain Dorange a crit: Pierre Quenee pierre.que...@sfr.fr wrote: Est ce que le codage des Communauts de Communes peut tre cod en relation pre ? par exemple : http://www.openstreetmap.org/api/0.6/relation/1187442 auquel cas l'intret d'un niveau 7 devient relatif. En effet, si (long) terme les communauts devait se substituer aux communes l'application du mme niveau 8 pour cette structure se rvlerait pertinente. C'est une excellente proposition. Reste dterminer l'tiquetage ? Des propositions ? Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Possibilité d'extraction des lim ites de départements avec la XAPI OSM ?
Ptet utiliser la liste dev...@openstreetmap.org la prochaine fois pour qu'elle ne meure pas :p. Benot R. Le 23/09/2010 11:27, Nicolas Moyroud a crit: Bonjour tous, Pour un projet de webmapping utilisant OpenLayers, j'aurai besoin d'afficher la couche des dpartements franais. J'ai essay d'utiliser la XAPI d'OSM pour les rcuprer. J'ai trouv quelques exemples et je m'en suis inspir, mais j'obtiens une erreur. Je pense en fait que la zone est trop grande (France entire) et que du coup la requte est refuse. Avec Firebug j'obtiens un status "200 OK" mais la rponse retourne est vide. Y a t'il un moyen de rcuprer les limites administratives en tenant compte du niveau de zoom ? Du style rcuprer des limites plus grossires l'affichage de la France entire puis de plus en plus dtailles en zoomant sur une zone prcise. Je ne sais pas comment faire a avec OpenLayers. Quelqu'un aurait-il une ide ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr Ce message entrant est certifi sans virus connu. Analyse effectue par AVG - www.avg.fr Version: 9.0.856 / Base de donnes virale: 271.1.1/3153 - Date: 09/22/10 20:40:00 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites, communales)
Le 23/09/2010 14:44, Pieren a crit: 2010/9/23 Benot ROUSSEAU adressepossi...@free.fr Reste dterminer l'tiquetage ? Des propositions ? Benot R. Je suis d'accord qu'il faut revoir l' "tiquetage". Avec la proposition actuelle: http://www.openstreetmap.org/browse/relation/1187442 je vois quelques problmes dont le principal est de mlanger des relations dfinissant des limites (somme de frontires extrieures formant une surface) avec des regroupements de communes (somme de surfaces) en utilisant la mme famille de tags (type=boundary; boundary=administrative). Donner un "role=relation" n'est pas suffisament distinctif ce qui pourrait compliquer leur exploitation par logiciel, amha (on ne tague pas pour les logiciels mais il faut garder une certaine cohrence tout de mme; la question s'est dj pose pour les dpartements, rgions, etc). Un autre problme dans cette proposition est d'y avoir ajouter le code postal qui se trouve dj dans les sous-relations. Je ne sais pas si la cration de communauts de communes implique toujours la fusion en un seul code postal mais les codes postaux devraient figurer dans une seule relation la fois pour viter les risques d'incohrences ultrieures. Pieren Tout a fait d'accord, le type "boundary" ne convient pas. Pour les surfaces il y aurait "area". De mme pour le code postal qui n'a rien faire ici. Par contre l'INSSE donne un code EPCI pour ces regroupement dans le document tlchargeable ici : http://www.statistiques-locales.insee.fr/esl/baseTelechProduit.asp?strProd=1637IdSousTheme=2IdSource=NomThemeOuSource=R%C3%A9gions%2C+d%C3%A9partements+et+villes+de+France. Ce code pourrait tre inclu. Il faudrait, a discuter, voir en terme de groupement, car relation exprime un regroupement administratif de territoires. Ce n'est pas une description gomtrique qui est dj dfinie par les limites des communes concernes. Je ne pense donc pas qu'il faille dfinir un contour pour les communauts de communes car 1- il est intrinsque 2 - les communaut de communes changes relativement rapidement. Utiliser une relation permet d'inclure ou d'exclure des communes facilement. J'arrte le franglish = un truc type=groupe ou groupement_administratif seraient ils trop simples et pas assez descriptif ? Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâtiments en France
Le 22/09/2010 09:19, Julien Balas a crit: Pour vrifier que je ne dtruit pas de donnes, je regarde si le fond de cadastre correspond aux "buildings" extraits... Et l, SURPRISE ! Mon extraction SVG de rfrence, faite au dbut de l'apparition du script, comporte plus de btiments que le fond Cadastre sous JOSM ! Alors qui quoi o comment ? ? ? Ma voiture tant en panne je ne pourrais pas rapidement aller vrifier si les btiments existent en "vrai". Certaines batiments sont dupliqus 4-5-6 fois dans le cadastre, c'est peut-etre l'explication. Tes btiments "en plus" sont peut-etre dans cette catgorie. -- JB L c'est l'inverse ils n'existent plus sur le Cadastre en ligne. Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâtiments en France
Le 22/09/2010 03:33, Benot ROUSSEAU a crit: Le 21/09/2010 17:29, Jean-Francois Nifenecker a crit: Le 21/09/2010 14:25, Vincent Pottier a crit : +1. Et la sparation building - water est pertinente. Les travaux de contrle sur le layer building n'ont rien voir avec les retouches de polygones water. +1 sur a aussi. Waterway et building sont des entits diffrentes qu'il faut traiter diffremment. Il serait donc (trs) utile de sparer les fichiers les contenant. Suite aux messages, je bosse sur un logiciel d'extraction des diffrents lments depuis les fichiers existants. Ca extrait dj les "buildings" dans un fichier spar, autant dire que les "river" et les "swinming-pool" vont arriver trs vite. Pour vrifier que je ne dtruit pas de donnes, je regarde si le fond de cadastre correspond aux "buildings" extraits... Et l, SURPRISE ! Mon extraction SVG de rfrence, faite au dbut de l'apparition du script, comporte plus de btiments que le fond Cadastre sous JOSM ! Alors qui quoi o comment ? ? ? Ma voiture tant en panne je ne pourrais pas rapidement aller vrifier si les btiments existent en "vrai". La mise jour me parat bien rapide... et c'est la moiti d'un hameau, a me parat bizarre. Encore que... QQun a t'il remarqu des pb similaires ? Benot R. Le logiciel d'clatement des fichiers d'import bti est prt en v0.1. Si qqun veux tester : http://adresseimpossible.free.fr/ Il fonctionne sous Windows en .Net Framework 4 Il y a pas mal de limitations pour l'instant comme : - extension des fichiers en minuscules ".osm" ; - ne travaille que sur un dossier, pas de ftp ; - extrait les amenity=swimming_pool mais le script je crois volu vers "leisure" ; - ... Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâtiments en France
Le 22/09/2010 17:07, Etienne Trimaille a crit: Le 22 septembre 2010 16:36, Benot ROUSSEAU adressepossi...@free.fr a crit : Le logiciel d'clatement des fichiers d'import bti est prt en v0.1. Si qqun veux tester : http://adresseimpossible.free.fr/ Il fonctionne sous Windows en .Net Framework 4 Il y a pas mal de limitations pour l'instant comme : - extension des fichiers en minuscules ".osm" ; - ne travaille que sur un dossier, pas de ftp ; - extrait les amenity=swimming_pool mais le script je crois volu vers "leisure" ; - ... Benot R. Ton logiciel clate un fichier .osm en sparant les buildings, piscines,.. ? Oui. Juste pour information, osmosis permet de le faire le tag filter : http://wiki.openstreetmap.org/wiki/Osmosis/Detailed_Usage#--tag-filter_.28--tf.29 Bien vu. Pourquoi la question n'a pas t trait avant ? Mystre... Ca m'a fait travailler les neurones c'est dj a. Donc aucun pb a fractionner les fichiers d'imports... Bon, surement que osmosis est moins accessible que ton outils. Oui, quoi que la bta est rudimentaire. Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites communales)
Le 22/09/2010 20:26, Pierre-Alain Dorange a crit: Vincent de Chateau-Thierry v...@laposte.net wrote: Le problme, c'est que la logique "arborescente" des niveaux adminsitratifs en France ne colle pas avec les regroupements de communes types CA/CU. Rien n'empche des communes de dpartements diffrents de se regrouper au sein d'une communaut. En effet mais il en va un peu de mme pour les cantons par exemple. De plus cette "logique" arborescente qui existe pour certains admin_level n'est pas dfinit (je n'en trouve pas de traces dans le wiki). Certes c'est pratique et a parait logique et plus simple, mais est-ce une ncessit des admin_level ? Mais (voir mon autre message dans l'ancienne enfilade) les intercommunalits ont aussi des caractristiques diffrentes des autres : les reprsentants ne sont pas lus au suffrage direct (mais a pourrait changer un jour), la division ne me semble pas administrative (dans le sens dcid par l'administration) ; il s'agit de regroupement autour de comptences. L'autre problme c'est de placer les cantons et arrondissement qui vont aussi entre le dpartement et la commune... A mon sens les cantons ne sont pas des "admin_level" au sens administratif, mais lectoral. La partie administrative est le dpartement pour les cantons, car les conseillers gnraux sigent au Conseil gnral. Ce sont des reprsentants politiques, pas des des fonctionnaires dans cette fonction (mme s'il peuvent l'tre par ailleurs). C'est le Conseil gnral qui gre administrativement, selon ses prrogatives, le dpartement dont la population est reprsente par des lus de fractions lectorales de ce territoire. Mme si les conseillers municipaux sont lus sur des secteurs lectoraux ont ne tag pas ces secteurs en admin_level mais on tag les quartiers qui n'y correspondent pas... et qui d'ailleurs ne sont pas a proprement parler des admin_level, sauf si les conseils de quartiers... sont lgalement obligatoires et on un rle administratif (je ne sais pas vrifier). Les Sous-prfectures avec leurs arrondissements administratifs oui, c'est une fraction de territoire de police, avec des fonctionnaires. A ce titre, les Acadmies auraient plus leur place, en admin_level, que les cantons. Les Acadmies sont bien des fractions administratives de l'tat, elles dterminent, par exemple, par ricoch les priodes de congs scolaires, l'endroit o inscrire les enfants l'cole publique, ... Le dcoupage lectoral ne suit pas le dcoupage administratif, nous sommes tous d'accord. Mais c'est mon avis une erreur de vouloir les intgrer au niveau d'admin_level il faudrait un dcoupage lectoral part, qui existe je crois. D'ailleurs on risque d'avoir le mme pb l'inverse quand on voudra monter le dcoupage lectoral, des morceaux seront en admin_level, les autres en "electoral_level", ... Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites communales)
Le 22/09/2010 21:32, Benot ROUSSEAU a crit: Le 22/09/2010 20:26, Pierre-Alain Dorange a crit: Vincent de Chateau-Thierry v...@laposte.net wrote: Le problme, c'est que la logique "arborescente" des niveaux adminsitratifs en France ne colle pas avec les regroupements de communes types CA/CU. Rien n'empche des communes de dpartements diffrents de se regrouper au sein d'une communaut. En effet mais il en va un peu de mme pour les cantons par exemple. De plus cette "logique" arborescente qui existe pour certains admin_level n'est pas dfinit (je n'en trouve pas de traces dans le wiki). Certes c'est pratique et a parait logique et plus simple, mais est-ce une ncessit des admin_level ? Mais (voir mon autre message dans l'ancienne enfilade) les intercommunalits ont aussi des caractristiques diffrentes des autres : les reprsentants ne sont pas lus au suffrage direct (mais a pourrait changer un jour), la division ne me semble pas administrative (dans le sens dcid par l'administration) ; il s'agit de regroupement autour de comptences. L'autre problme c'est de placer les cantons et arrondissement qui vont aussi entre le dpartement et la commune... A mon sens les cantons ne sont pas des "admin_level" au sens administratif, mais lectoral. La partie administrative est le dpartement pour les cantons, car les conseillers gnraux sigent au Conseil gnral. Ce sont des reprsentants politiques, pas des des fonctionnaires dans cette fonction (mme s'il peuvent l'tre par ailleurs). C'est le Conseil gnral qui gre administrativement, selon ses prrogatives, le dpartement dont la population est reprsente par des lus de fractions lectorales de ce territoire. Mme si les conseillers municipaux sont lus sur des secteurs lectoraux ont ne tag pas ces secteurs en admin_level mais on tag les quartiers qui n'y correspondent pas... et qui d'ailleurs ne sont pas a proprement parler des admin_level, sauf si les conseils de quartiers... sont lgalement obligatoires et on un rle administratif (je ne sais pas vrifier). Les Sous-prfectures avec leurs arrondissements administratifs oui, c'est une fraction de territoire de police, avec des fonctionnaires. A ce titre, les Acadmies auraient plus leur place, en admin_level, que les cantons. Les Acadmies sont bien des fractions administratives de l'tat, elles dterminent, par exemple, par ricoch les priodes de congs scolaires, l'endroit o inscrire les enfants l'cole publique, ... Le dcoupage lectoral ne suit pas le dcoupage administratif, nous sommes tous d'accord. Mais c'est mon avis une erreur de vouloir les intgrer au niveau d'admin_level il faudrait un dcoupage lectoral part, qui existe je crois. D'ailleurs on risque d'avoir le mme pb l'inverse quand on voudra monter le dcoupage lectoral, des morceaux seront en admin_level, les autres en "electoral_level", ... Benot R. Je poursuis avec un complment... Quant au n de niveau administratif, vouloir "emboiter" les niveaux comme des poupes russes avec un seul type par niveau est une erreur. Si on prends Acadmie et prfecture (sauf erreur - mais qu'importe pour la dmo) elle devrait tre au mme niveau, l'une est juste sous l'tat France par le Ministre de l'ducation, l'autre par le Ministre de l'intrieur. Et il existe d'autres dcoupages administratifs, comme par exemple celui des centres d'impts, qui ne correspond aucun autre, ... Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] niveaux admin_level=7 (était : Limites communales)
Le 22/09/2010 22:56, Vincent de Chateau-Thierry a crit: Le 22/09/2010 21:43, Benot ROUSSEAU a crit : Le 22/09/2010 21:32, Benot ROUSSEAU a crit : Le 22/09/2010 20:26, Pierre-Alain Dorange a crit : Vincent de Chateau-Thierry v...@laposte.net wrote: Le problme, c'est que la logique "arborescente" des niveaux adminsitratifs en France ne colle pas avec les regroupements de communes types CA/CU. Rien n'empche des communes de dpartements diffrents de se regrouper au sein d'une communaut. En effet mais il en va un peu de mme pour les cantons par exemple. De plus cette "logique" arborescente qui existe pour certains admin_level n'est pas dfinit (je n'en trouve pas de traces dans le wiki). Certes c'est pratique eta parait logique et plus simple, mais est-ce une ncessit des admin_level ? Mais (voir mon autre message dans l'ancienne enfilade) les intercommunalits ont aussi des caractristiques diffrentes des autres : les reprsentants ne sont paslus au suffrage direct (maisa pourrait changer un jour), la division ne me semble pas administrative (dans le sens dcid par l'administration) ; il s'agit de regroupement autour de comptences. L'autre problme c'est de placer les cantons et arrondissement qui vont aussi entre le dpartement et la commune... A mon sens les cantons ne sont pas des "admin_level" au sens administratif, mais lectoral. La partie administrative est le dpartement pour les cantons, car les conseillers gnraux sigent au Conseil gnral. Ce sont des reprsentants politiques, pas des des fonctionnaires dans cette fonction (mme s'il peuvent l'tre par ailleurs). C'est le Conseil gnral qui gre administrativement, selon ses prrogatives, le dpartement dont la population est reprsente par des lus de fractions lectorales de ce territoire. Mme si les conseillers municipaux sont lus sur des secteurs lectoraux ont ne tag pas ces secteurs en admin_level mais on tag les quartiers qui n'y correspondent pas... et qui d'ailleurs ne sont pas a proprement parler des admin_level, sauf si les conseils de quartiers... sont lgalement obligatoires et on un rle administratif (je ne sais pas vrifier). Les Sous-prfectures avec leurs arrondissements administratifs oui, c'est une fraction de territoire de police, avec des fonctionnaires. A ce titre, les Acadmies auraient plus leur place, en admin_level, que les cantons. Les Acadmies sont bien des fractions administratives de l'tat, elles dterminent, par exemple, par ricoch les priodes de congs scolaires, l'endroit o inscrire les enfants l'cole publique, ... Le dcoupage lectoral ne suit pas le dcoupage administratif, nous sommes tous d'accord. Mais c'est mon avis une erreur de vouloir les intgrer au niveau d'admin_level il faudrait un dcoupage lectoral part, qui existe je crois. D'ailleurs on risque d'avoir le mme pb l'inverse quand on voudra monter le dcoupage lectoral, des morceaux seront en admin_level, les autres en "electoral_level", ... Benot R. Je poursuis avec un complment... Quant au n de niveau administratif, vouloir "emboiter" les niveaux comme des poupes russes avec un seul type par niveau est une erreur. Si on prends Acadmie et prfecture (sauf erreur - mais qu'importe pour la dmo) elle devrait tre au mme niveau, l'une est juste sous
Re: [OSM-talk-fr] Utilisation de bulk_upload bulk_upload_sax
Le 21/09/2010 12:06, Tenshu a crit: Visiblement JOSM semble trop instable pour les imports, je pense que certain comme moi en ont fait les frais. Par ailleurs j'ai moi mme tent d'utiliser bulk_upload_sax.py sur la commune de Corbeil-Essonnes, le script a commenc envoyer des nodes dupliqus en 10 20 exemplaires. Est qu'il serait envisageable de dtailler la doc sur ce script, voir de le prsenter dans le wiki comme une mini-formation l'import de gros documents? -- Mon weblog - http://www.tenshu.fr/ Je soutiens le Logiciel Libre, j'adhre l'APRIL ! Je repose la question du ct serveur... Sommes nous certains que les serveurs tiennent la charge et respectent leur engagement protocolaires ? C'est une histoire deux bouts les transactions d'import ! - Je veux bien accepter que JOSM dconne mais il a fait ces preuves par le pass - mais cela peut tre simplement un pb de temps de rponse exig pour le serveur par JOSM qui devrait tre allong ; - je veux bien croire que bulk_upload_sax.py dconne mais mme sans documentation je ne le l'imagine pas, spontanment ou par dfaut, tre configur pour gnrer des doublons ; - lors de mes connexions l'API sur, par exemple 45 000 points traits en 6-8 heures, il y a rgulirement quelques requtes non satisfaites, ... - je note qu'on ne parle de ce type de pb qu'avec l'apparition d'une charge importante des serveurs depuis l'import bti et srement la mise en branle de nouveaux pays. Je veux bien mettre en accusation JOSM, BULK_UPLOAD et d'autres clients API si on me prouve qu'effectivement il ne respectent pas l'API, les protocoles, ... Cela devrait tre faisable par des programmeurs dans ces langages, tant donn qu'ils sont open-source. Sommes nous sr que la bases, le matriel, ... ct serveur tiennent la charge tout moment ? A ton test, prouv, ... ? Peux t-on reproduire ces pb sur des serveurs "perso" ? Peux t'on rpter exactement et coup sr ces pbs ? Si on refait un import "merd" a t'on les mmes pbs ? ... Ces investigations et/ou des essais pourraient trs bien tre mens en coordination avec l'quipe OSM en charge des serveurs en attaquant la vraie base avec des objets gnrs sur des zones de "tirs" (pourquoi pas les champs de tirs militaires inscrits dans la base), ... Dans un premier temps, milie, pourrais-tu nous obtenir l'avis de l'quipe qui gre les serveurs sur l'origine possible ou avre de tous ces doublons d'aprs eux ? Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Utilisation de bulk_upload bulk_upload_sax
Le 21/09/2010 13:11, Emilie Laffray a crit: 2010/9/21 Benot ROUSSEAU adressepossi...@free.fr Ces investigations et/ou des essais pourraient trs bien tre mens en coordination avec l'quipe OSM en charge des serveurs en attaquant la vraie base avec des objets gnrs sur des zones de "tirs" (pourquoi pas les champs de tirs militaires inscrits dans la base), ... Dans un premier temps, milie, pourrais-tu nous obtenir l'avis de l'quipe qui gre les serveurs sur l'origine possible ou avre de tous ces doublons d'aprs eux ? J'en parlerais. Je ne sais pas quand forcement mais la semaine prochaine il y a une runion du Technical Working Group (les admins et les devs), donc il est certain qu'on aura une discussion la dessus, puisqu'un des sujets est comment amliorer les performances. Il faut noter qu'un nouveau serveur va tre bientt achet. Emilie Laffray Merci :p. En esprant qu'on y verra plus clair. Il est pratique d'avoir des francophones au sein des instances dirigeantes. Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] La France, lanterne rouge des erre urs dans OSM ? (était: Route non connectée)
+1 Le 21/09/2010 13:44, Guilhem Bonnefille a crit: Je ne suis pas vraiment actif dans la communaut OSM. Toutefois, en suivant quelques changes, je ne peux que constater que l'quipe QA-fr semble exister, au moins informellement. En effet, il y a dj pas mal de personnes qui relaye ce type d'information sur la liste, ou qui mette au point des outils. Pour exemple, il n'y a qu' regarder quelques jours en arrire, lorsqu'un outil de mesure de l'avancement des autoroutes a t annonc, instantanment plusieurs contributeurs se sont attach ce projet d'amlioration de la "qualit" des reprsentations des autoroutes dans OSM/France. Du coup, mon avis est qu'il manque simplement concrtiser ce groupe QA-fr : * une ML ?-), * une page wiki, * un code pour les titres de mails, * une signature insrer dans les mails des membres de ce groupe. Pourquoi concrtiser ? Simplement parce que parfois, l'appartenance un groupe reconnu et clairement identifi par les autres peut aider contribuer. Il serait certainement utile de rorganiser les informations du wiki autour de ce thme QA-fr, commencer par une traduction de http://wiki.openstreetmap.org/wiki/Quality_Assurance Mais bon, c'est mon regard de gugusse qui parle beaucoup et qui fait rien. Le 20 septembre 2010 13:28, Emilie Laffray emilie.laff...@gmail.com a crit : 2010/9/20 Guilhem Bonnefille guilhem.bonnefi...@gmail.com Comme dans les gros projets, va falloir monter une team "QA" pour veiller la qualit des donnes et remdier aux erreurs (ou du moins, mettre en oeuvre des plan d'actions pour les rsorber). Je pense qu'une team QA sera assez difficile a mettre en oeuvre meme si c'est une tres bonne idee. Je pense que certains d'entre nous passont deja un certain nombre de temps a corriger de nombreuses erreurs mais l'essentiel serait dj d'avoir des outils qui vitent de crer les erreurs en premier lieu. Emilie Laffray ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr Ce message entrant est certifi sans virus connu. Analyse effectue par AVG - www.avg.fr Version: 9.0.851 / Base de donnes virale: 271.1.1/3149 - Date: 09/21/10 08:34:00 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Utilisation de bulk_upload bulk_upload_sax
Le 21/09/2010 15:30, Tenshu a crit: 2010/9/21 Vincent Pottier vpott...@gmail.com Quoi qu'il en soit du respect des protocoles, je trouve JOSM peu clair au moment de la transaction ou de son chec. Il me semble que dans des versions prcdentes de JOSM (il y a 6 mois environ), lors d'un upload par paquet, les objets en local taient mis jour paquet par paquet (id et statut), ce qui, me sembl-t-il n'est plus le cas. Lors d'un upload de 20 paquets, si la transaction est interrompue (volontairement ou non) au 10e, j'ai l'impression que les 9 paquets envoys ne sont pas mis jour dans JSOM, ce qui fait qu'une relance de la transaction renvoie les nouveaux objets en double. Mais, bon, je n'ai pas de certitude... C'est exactement a le problme. -- On a avanc : 1 - il y a un pb ct JOSM a coup sr = donc avertir l'quipe de JOSM ; 2 - les serveurs sont PROBABLEMENT surchargs et donc ce pb est plus frquent et ne passe plus inaperu = SIMILI pb ct charge serveur. note : en gras, termes prudents, mme si cela semble confirmes par milie, mais... Reste rdiger une note destination de l'quipe JOSM pour ceux qui ont une exprience du pb et leur transfrer : "Il y a 6 mois on n'avait pas ce pb parce que mise jour locale des paquets. Aujourd'hui ce n'est plus le cas mais a pose pb avec les imports massifs quand pb en cours d'export vers le serveur..." Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Utilisation de bulk_upload bulk_upload_sax
Le 21/09/2010 17:17, Emilie Laffray a crit: 2010/9/21 Benot ROUSSEAU adressepossi...@free.fr On a avanc : 1 - il y a un pb ct JOSM a coup sr = donc avertir l'quipe de JOSM ; 2 - les serveurs sont PROBABLEMENT surchargs et donc ce pb est plus frquent et ne passe plus inaperu = SIMILI pb ct charge serveur. note : en gras, termes prudents, mme si cela semble confirmes par milie, mais... Oui surtout que je n'ai rien confirm :) J'ai juste parle que l'on allait avoir une nouvelle machine plus puissante, mais je ne suis pas sure de l'utilisation de la machine (pas sure qu'elle soit la pour la base de donne). Comme je l'ai indiqu plutt, je demanderais aux admins s'ils sont au courant d'un quelconque problme. Les problmes rencontrs par les serveurs rcemment taient lis a un contrleur RAID dfectueux, qui a t chang depuis. Emilie Laffray Ouaip je n'ai pas t assez prudent sur les termes... +1 dsol tes propos taient clairs. Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâtiments en France
Le 21/09/2010 17:29, Jean-Francois Nifenecker a crit: Le 21/09/2010 14:25, Vincent Pottier a crit : +1. Et la sparation building - water est pertinente. Les travaux de contrle sur le layer building n'ont rien voir avec les retouches de polygones water. +1 sur a aussi. Waterway et building sont des entits diffrentes qu'il faut traiter diffremment. Il serait donc (trs) utile de sparer les fichiers les contenant. Suite aux messages, je bosse sur un logiciel d'extraction des diffrents lments depuis les fichiers existants. Ca extrait dj les "buildings" dans un fichier spar, autant dire que les "river" et les "swinming-pool" vont arriver trs vite. Pour vrifier que je ne dtruit pas de donnes, je regarde si le fond de cadastre correspond aux "buildings" extraits... Et l, SURPRISE ! Mon extraction SVG de rfrence, faite au dbut de l'apparition du script, comporte plus de btiments que le fond Cadastre sous JOSM ! Alors qui quoi o comment ? ? ? Ma voiture tant en panne je ne pourrais pas rapidement aller vrifier si les btiments existent en "vrai". La mise jour me parat bien rapide... et c'est la moiti d'un hameau, a me parat bizarre. Encore que... QQun a t'il remarqu des pb similaires ? Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâtiments en France
Le 20/09/2010 18:07, Tenshu a crit: 2010/9/20 Emilie Laffray emilie.laff...@gmail.com Quant a l'utilisation de JOSM pour un import quelconque, je ne commenterais pas mais je n'en pense pas moins. C'est toutefois l'outil le plus pratique a l'heure actuelle. Emilie Laffray C'est bien beau de dire a, j'utilise Linux au quotidien et je me dit youpi utilisons bulk_upload pour importer les btiments depuis le cadastre. Et bien totu semblait rouler mais sur Corbeil-Essonnes ils c'est mis en tte de crer chaque lments en 10-20-30-50 exemplaires. J'ai su sang et eau pour revert tout ce foutoir. Et pendant ce temps personne n'a t capable de me dcrire comment cet outil fonctionne etc. Alors j'ai utilis JOSM sur Draveil, mais il m'a dupliqu 1700 way et leur nodes. Depuis je n'ai plus import de btiments en me disant que j'attendrais que le bon outil soit disponible. Et c'est pas la dcouverte des (centaines) de milliers d'overlap entre btiments qui va me faire changer d'avis. -- Mon weblog - http://www.tenshu.fr/ Je soutiens le Logiciel Libre, j'adhre l'APRIL ! Pour faire suite la conversation dans son ensemble et pas ce courrier en particulier avec lequel je suis en accord... Pour ma part, je pense que a merdx au moins pour une part ct serveurs. Que les outils ne sont pas la cause et la source de tous les mots mais que la charge de travaille impose par l'import massif en France coupl l'mergence d'autres pays, les traitements massifs de diffrents sites, fait que a rvle des faiblesses au niveau serveurs. Quand je dis serveurs c'est prendre de manire gnrique, cela peut tre logiciel, matriel, ... J'ai pour la suppression des points orphelins, des requtes qui n'aboutissent jamais, ... Sans consquences dans ce cas, mais rvlateur. Il m'est difficile de croire que JOSM ne respecte pas les protocoles et ne gre pas correctement les erreurs mme si c'est possible. Je dis qu'il faudrait ptet voir ct serveur et protocoles avant de taper sur les clients. Et ce n'est pas Potlatch V2 qui va changer la face du monde OSM. Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Traces GPS orphelines - comment les dénicher ?
Le 14/09/2010 17:00, Bruno Cortial a crit: Bonjour, Existe-t-il un outil ou une carte qui nous indique les traces GPS remontes dans OSM et qui n'ont pas fait l'objet d'une dition dans OSM ? Par exemple des traces qui n'ont pas de highway OSM x mtres. Je fais des imports de bti dans des coins en peu dsoeuvrs ct carto, et il n'est pas rare que je dcouvre sous JOSM des traces non exploites. C'est bien domage de laisser ces contributions en friche etinvisibles parce qu'il n'y a pas de contributeur-diteur dans le coin. Ellepeuventsans doutetre tagues au moins en road, croises avec le cadastre... Pour trouver ce genre de trace je tlcharge une large zone jous josm avec les traces, jefiltre pour n'afficher que les highway et choisi une couleur bien contraste pour les traces. Avec le bti tlcharger une large zone sous JOSM devient impossible, mais l'import du bati n'est pas le sujet ;-) Autres questions: * il n'y a pas d'export global de traces faon planet.osm ? * On peut suivre les ditions OSM d'une zone via un flux RSS ou l'outil OSM Mapper. Et les traces ? * Quelqu'un a-t-il un avis positif sur le systme de tagassocis auxtraces ? A+ BrunoC C'est une bonne ide que de les dcouvrir et les les indiquer. Les passer automatiquement en "road" je suis moins sr. Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] chemin recouvert à marée haute
Le 14/09/2010 21:33, Vincent de Chateau-Thierry a crit: Le 14/09/2010 20:54, g.d a crit : Il y a eu dj une discussion ce sujet, ne sais plus quand, ni qu'en est sorti. Par exemple il y a ceci : http://www.openstreetmap.org/?lat=46.927lon=-2.1176zoom=14layers=O mais je trouve le "waterway:tidal" pas heureux. Ce n'est pas la D 948 qui par mare haute se transformerait en un canal navigable. La carte n'affiche pas la contrainte. Bien d'accord. "tidal" devrait concerner une zone de part et d'autre de la route, qui montre la surface approximativement dgage mare basse. Il nous faudrait peut-tre un tag qui indique, qu'une route n'est praticable que temporairement, dans le groupe des "restrictions", avec diffrents valeurs qui indiqueraient les causes. (...) Les Champs Elyses Paris les 14 juillet se laissent taguer avec date_on / date_off. Un centre ville impraticable chaque samedi cause du march se laisse taguer avec day_on / day_off. Mais, une route (passage du Gois) ou un chemin de fer (http://www.openstreetmap.org/?lat=54.679lon=8.7236zoom=12layers=O) peuvent tre inondables par la mare, (..) blubb-blubb sponge-bob. Dans le cas du Gois, qui ressemble ce que Ziva indiquait dans sa question, on ne peut pas indiquer d'horaire, sachant que le passage est possible 2 x 3 heures par tranche de 24 heures, et que les crneaux changent quotidiennement, puisqu'ils encadrent les heures de basse mer. On pourrait imaginer un tag relatif plutt qu'absolu, sur le principe des Access time restrictions : hour_on : 90 mn to low tide hour_off : 90 mn past low tide ou qqch du genre. vincent Juste une remarque l'abrviation de "minute" est "min" : http://www.industrie.gouv.fr/metro/aquoisert/si.htm#ut. Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Quelles évolutions pour une meille ure prise en charge des nouveaux venus (et des moins nou veaux) ? ( était : Changement de licence [etc .])
Emilie Laffray a crit: 2010/8/26 Eric eric...@sfr.fr +10 Moi j'avoue ne pas du tout aimer les Wikis au sens large sans vouloir troller on plus. Je trouve que trs souvent, ils se rsument un catalogue de liens et au bout de 2 ou 3 clicks sur des liens, on ne sait pas d'o on est parti donc impossible de revenir. Il est donc impossible de parcourir l'arbre, on peut passer 20x cot d'une page interessante. Il y a dej quelques mois, quelqu'un s'etait dvou pour faire un PDF pour le B-A-BA mais il avait eu des ractions trs froides (un PDF c'est pas bien, c'est fig, ...) mais ce dbut de tutorial m'avait bien aid. Des pages dont 20% de l'espace en haut et gauche sont "perdus" en habillage et dont le contenu et une liste de liens vers d'autres points du wiki, c'est frustrant je trouve. Donc, en rsum, pour moi, Wiki:0 PDF:1 Je partage ton analyse :) Donc +1 Emilie Laffray +1. Un bon vieux PDF imprimable. Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] [Tech] Noeuds orphellins
J'ai effac tous les nuds orphelins trouvs jusqu'au 27 juillet 2010. Soit moins de 56.089 nuds en 3-4 jours. J'ai arrt au 27 juillet car je suis tomb sur un import CLC a cette date et dont les points ne sont toujours pas relis. J'ai crit l'auteur sans rponse pour l'instant. Est-ce un import abandonn ? Je n'ai pas compris ce qui t en cours, pas en cours et depuis quand sur la page wiki d'import des CLC. Donc si qqun sait... Il y a d'autres imports bizarres mais comme les serveurs OSM ont l'air sur les rotules, "wait and see" les points seront peut-tre connects un jour. Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Tech] Noeuds orphellins
Ce sont les nuds dupliqus en France uniquement ? Xinfe Ewalavir a crit: Hummm, c'est sur la bonne voie : http://matt.dev.openstreetmap.org/dupe_nodes/dupe_nodes.png Bien jou ! 2010/8/18 Benot ROUSSEAU adressepossi...@free.fr J'ai effac tous les nuds orphelins trouvs jusqu'au 27 juillet 2010. Soit moins de 56.089 nuds en 3-4 jours. J'ai arrt au 27 juillet car je suis tomb sur un import CLC a cette date et dont les points ne sont toujours pas relis. J'ai crit l'auteur sans rponse pour l'instant. Est-ce un import abandonn ? Je n'ai pas compris ce qui t en cours, pas en cours et depuis quand sur la page wiki d'import des CLC. Donc si qqun sait... Il y a d'autres imports bizarres mais comme les serveurs OSM ont l'air sur les rotules, "wait and see" les points seront peut-tre connects un jour. Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Diff import bâti [Tech]
Steven Le Roux a crit: 2010/8/6 Christophe Merlet red...@redfoxcenter.org: Bonjour, J'ai constat que depuis mes derniers imports semi-auto du bti, le cadastre avait tait mis jour et que de nouveaux btiments avait fait leur apparition. Existe t'il une mthode qui me permettrait de dterminer les nouveaux btiments et de les importer ? Sachant que, pour simplifier la cration de diff, je possde les pdf de mes prcdents imports et je peux recrer les .osm correspondants. Ce script va devenir indispensable, voire primordiale avec le temps... Si la mthode du diff entre 2 fichiers .osm du bti cadastre s'avre la plus simple et facile pour grer les mises jour, il faut prvoir de conserver ces fichiers car il est ma connaissance impossible de demander l'tat du cadastre vectoriel une date t. Plutt que de conserver des osm ou pdf, il vaut mieux avant chaque diff, le faire sur la base existante. Ce que tu avais dans ton fichier originel a pu tre modifi. Il faudra donc rcuprer un extrait du planet sur ta zone d'import, faire le diff, puis injecter les nouvelles donnes. Avant de tout jeter, pdf et osm, attendre de voir. Si une comparaison avec l'existant en base est ncessaire, un prtraitement sur des donnes plus lgres pourrait acclrer et faciliter les choses. Par exemple, plutt que d'attaquer le boulot sur Paris en entier pour 10 btiments, ne comparer avec l'existant que sur des zones plus restreintes. Benot R. Mais a va tre plus compliqu que pour du filaire, notament pour les extentions de batiments. Car on risque de ne pas voir facilement que les noeuds ne sont pas connects. Ou alors il faudra l'intgrer un script de vrif, ou faire un check posteriori avec les outils le permettant dj. Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr Ce message entrant est certifi sans virus connu. Analyse effectue par AVG - www.avg.fr Version: 9.0.851 / Base de donnes virale: 271.1.1/3052 - Date: 08/05/10 08:35:00 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Vote] Nouvelles listes de discussion
Christophe Merlet a crit: Cette liste existe dj. Elle s'appelle talk-fr ! Un sondage a eu lieu avec des questions parfaitement claires. Inutile d'essayer de donner un tout autre sens aux questions et aux rsultats du vote ! Crons la liste dev-fr et redirigeons y toutes les discussions minemment techniques. Librement, +1 sinon ce n'est pas la peine de faire un sondage. Tout le monde donn son avis et la majorit s'est orient vers "les devs l'cart". Si a ne fonctionne pas tant pis on en rediscutera. Mais personne n'empche personne de monter sa liste son blog, son service de news, ... Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Alerte ! Les doublons, ça grossi t sans arrêt
Marc Sibert a crit: Le 26/07/2010 11:52, Marc SIBERT a crit: Bonjour, Voil, j'ai envoy le dernier lot de suppressions ce matin : http://www.openstreetmap.org/browse/changeset/5318380 Enfin, pour Osmose, il en reste encore : http://osmose.openstreetmap.fr/cgi-bin/all-update.py?source=64 A+ -- Marc Sibert m...@sibert.fr Encore un petit 10k way de supprims : http://www.openstreetmap.org/browse/changeset/5343124 Bon, je vais insist, faut tuer le problme dans l'uf. Et pendant que j'y suis je suggre un coup de rteau sur les nuds orphelins. A+ -- Marc Sibert m...@sibert.fr Ok je lance le ratissage... ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Alerte ! Les doublons, ça grossi t sans arrêt
Benot ROUSSEAU a crit: Marc Sibert a crit: Le 26/07/2010 11:52, Marc SIBERT a crit: Bonjour, Voil, j'ai envoy le dernier lot de suppressions ce matin : http://www.openstreetmap.org/browse/changeset/5318380 Enfin, pour Osmose, il en reste encore : http://osmose.openstreetmap.fr/cgi-bin/all-update.py?source=64 A+ -- Marc Sibert m...@sibert.fr Encore un petit 10k way de supprims : http://www.openstreetmap.org/browse/changeset/5343124 Bon, je vais insist, faut tuer le problme dans l'uf. Et pendant que j'y suis je suggre un coup de rteau sur les nuds orphelins. A+ -- Marc Sibert m...@sibert.fr Ok je lance le ratissage... Le rteau demande aujourd'hui des capacits mmoire que je n'ai pas et qui sont indcentes. Je vais changer l'ago pour que a tourne dans des limites raisonnables. Nouveau ratissage au plus tard dimanche. Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Systèmes de numérotation des voi es en France. Suite, c'est moins tranché.
Benot ROUSSEAU a crit: Re... Selon : http://fr.wikipedia.org/wiki/Num%C3%A9rotation_des_voies#France ce sont bien les btiments qui sont numrots en France. Ni les parcelles, ni la rue elle mme. Donc je revois ma copie sur l'import semi-auto des adresses pour associer les adresses aux btiments "wall=yes" quand c'est possible, sinon limite parcellaire la plus proche et dfaut sa position dans la voie sur le Cadastre. Benot R. Suite mon prcdent message, j'ai continu mes recherches parce que pour moi ce sont les entres qui devraient tre numrote et non les immeubles tout en pensant que l'objectif du Cadastre est la perception de taxes sur l'immobilier. Donc une autre source jette le flou : http://www.laposte.fr/sna/IMG/pdf/BAT_LIVRET_comprendre_ladresse_2008.pdf. Effectivement les objectifs de ces deux institutions de l'adressage ne sont pas identiques, donc leur attentes diffrent. Mais il y est not dans ce document : "un numro : tous les accs donnant sur une voie doivent tre numrots." ce qui est en contradiction avec l'article de Wikipdia. Mais aussi "En France, seules les mairies ont autorit initier la dnomination dune voie ainsi que sa numrotation." et en dernier lieu en informe "[...] divers organismes : [...] et de manire obligatoire : le cadastre et la DGI (Direction Gnrale des Impts).". Ce qui laisse donc entendre que ce sont les accs qui numrots "par" la Mairie qui en informe le Cadastre. Pour ma part j'interprte "accs" comme l'interface entre voie et un btiment dans le sens limite parcellaire. Au final, les deux systmes semblent valables mme s'ils ne recouvrent pas les mme usages. Les relations type "associatedStreet" ne proposent que la prise en compte de la numrotation des btiments avec les membres "role=house". Vous avez deux rfrences diffrentes qui couvre l'ensemble de nos discussions passes et pointe un manquement dans le schma actuel : le simple positionnement d'un n de voie type accs. Si vous avez des propositions, ... Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Systèmes de numérotation des voi es en France. Suite, c'est moins tranché.
Pierre-Alain Dorange a crit: Le 25 juil. 10 10:08, Benot ROUSSEAU a crit : Vous avez deux rfrences diffrentes qui couvre l'ensemble de nos discussions passes et pointe un manquement dans le schma actuel : le simple positionnement d'un n de voie type accs. Si vous avez des propositions, ... Je suis pas sur d'avoir tout bien suivi, mais dans OSM l'intrt des adresses (numrotation) est de faire du routage. Donc de permettre un utilisateur de trouver l'adresse qu'il recherche, donc le point d'accs depuis depuis la rue. Le btiment a une moindre importance ici, ce qui compte c'est de tracer une route pour permettre a l'utilisateur de trouver l'accs qu'il cherche. Une fois devant, il n'a qu'a pousser la porte et entrer. Dans cette "vision", le numro doit se trouver en limite rue/parcelle par sur les btiments qui peuvent tre loign de la rue et conduire des erreurs de routage (si le btiment est loin de sa rue d'accs mais proche de celle de derrire ou il n'y a pas d'accs)... -- Pierre-Alain Dorange, Blog Citoyen de Cognac : http://cognac-citoyen.blogspot.com/ Twitter : https://twitter.com/padorange -Facebook : http://www.facebook.com/pa.dorange L'ide de base du premier message tait de dire que Pieren n'avait pas tord et du second que les partisans du "surtout routing, placement en limite de parcelle" non plus. Dans "la ralit", les deux conceptions se croisent aussi. C'est l'usage des utilisateurs qui dtermine le point de vue. Comme il n'y a pas de directives au sein d'OSM, aprs "On ne tag pas pour le rendu" on risque d'avoir "on ne tag pas que pour le routing." ou "on ne tag pas dresser un annuaire" :). Si personne n'a tord ou raison, le placement en limite de parcelle est celui qui offre le plus d'alternatives. Reste que le "tagguer" role=house dans une relationStreet me gne. M'enfin, ... Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Systèmes de numérotation des voi es en France. Suite, c'est moins tranché.
simon a crit: Le dimanche 25 juillet 2010 11:46 +0200, Pierre-Alain Dorange a crit : Le 25 juil. 10 11:35, simon a crit : Vous avez deux rfrences diffrentes qui couvre l'ensemble de nos discussions passes et pointe un manquement dans le schma actuel : le simple positionnement d'un n de voie type accs. Si vous avez des propositions, ... Je suis pas sur d'avoir tout bien suivi, mais dans OSM l'intrt des adresses (numrotation) est de faire du routage. Donc de permettre un utilisateur de trouver l'adresse qu'il recherche, donc le point d'accs depuis depuis la rue. Pas forcment, un immeuble peut avoir plusieurs numro dans une coure intrieur avec un ou deux accs sur la rue. Dans ce cas si utilise un rendu papier, la numrotation sur l'entre est plus utile (cela vite de faire trois fois le tours de la cours ou de prendre l'entre l'oppos. On est dans une situation de micromapping l, mais rien n'empche de tracer la voie qui mne la cour, voir la cour pour y apposer les numros. Ce serait mme indispensable pour du routage jusqu'au bout. Car sans voies (highway) pour accder numro le routage ne sera qu'approximatif. Pour que le routage soit pleinement oprationnel au niveau de numro il faut que ces numros soit sur (ou trs proche) une voie afin de lever les ambiguits. Je pensait a ce genre de cas http://maps.google.com/?ie=UTF8t=kll=47.380604,0.672038spn=0.001707,0.005284z=18 toutes les entres sont l'intrieur de la cour, interdite aux vhicule a moteur. Ca pose pas de pb en "manuel". Dans le cadre de la reco. semi auto., les points peuvent tre correctement placs et relis la rue s'il sont ni trop prs ni trop loin de celle-ci. Sinon, il faudra quand mme corriger des placements la main. On peut aussi imaginer considrer les "footway" et les alles prives comme faisant partie de la rue laquelle elle sont connectes et pour moiti si elle sont connecte 2 rues. Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Tech] Question sur l'aide à la saisie d'adresses du plugin Cadastre.
Pieren a crit: 2010/7/25 Benot ROUSSEAU adressepossi...@free.fr Mais elles sont finalement toutes regroupes dans la mme relation associe la voie en magenta. Pour moi c'est une erreur. Quand est-il rellement ? La doc sur la relation ne dit rien sur cette question. "Next to a street", "Next to a way", plus le petit schma dans "Associating a building-polygon with a street" me semble faire parties du concept global. Mais j'en ai une autre : la relation lie un noeud avec un numro et un way avec un nom. Quel intrt d'associer le bout de rue le plus proche du moment que l'association est correcte et que le noeud dsigne la bonne position ? Faciliter les ditions et les corrections manuelles par la suite. Il serait d'ailleurs plus logique d'utiliser une relation type http://wiki.openstreetmap.org/wiki/Relations/Proposed/Street qui lie l'ensemble des lments d'une rue et non des adresses un segment puis un un nom comme propos dans le schma commun. Pieren Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Systèmes de numérotation des voi es en France. Suite, c'est moins tranché.
julien balas a crit: Ca pose pas de pb en "manuel". Dans le cadre de la reco. semi auto., les points peuvent tre correctement placs et relis la rue s'il sont ni trop prs ni trop loin de celle-ci. Sinon, il faudra quand mme corriger des placements la main. On peut aussi imaginer considrer les "footway" et les alles prives comme faisant partie de la rue laquelle elle sont connectes et pour moiti si elle sont connecte 2 rues. Si on parle d'une chaine qui - extrait automatiquement les PDF du site du cadaste - les converti automatiquement en SVG - puis en OSM - puis cree les adresses des maisons - puis cree les relations sur les rues Est ce qu'on peut toujours parler de "semi" automatique ? Est ce qu'on est toujours dans ce fameux travail "composite" qui nous a autoris l'acces au cadastre ? Oui. 1 - Les adresses sont reconnues par leur forme graphique. 2 - Tout n'est pas parfaitement reconnu a, b, c, bis, ter, quater, ... 3 - Les adresses sont gnralement repositionnes et ne sont pas l'emplacement signifies par le cadastre, on change leur localisation. 4 - Parce qu'il faut ensuite corriger manuellement les erreurs et prendre des dcisions concernant les incertitudes. Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] [Tech] Question sur l'aide à la saisie d'adresses du plugin Cadastre.
Bonjour, J'ai class a en [Tech] parce que je pense que c'est plus une question technique qu'autre chose. Pour le contexte : afin de rendre interoprable les outils de gestion d'adresses avec la saisie semi auto je regardais comment le plugin d'aide la saisie du plugin Cadastre grait le nommage des relations associatedStreet pour les rues en plusieurs segments pour m'y conformer. L'exemple classique, c'est une rue qui comporte un pont, un tunnel, comporte une mini alle, une piste cyclable commence ou s'arrte, ... et de fait elle est dcompose en plusieurs segments pour le mme nom de rue. Concernant la gestion des relation d'adressage, la page de rfrence est, me semble t'il : http://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Karlsruhe_Schema. D'aprs ce que je comprends c'est une relation par segment de rue "street : one / house : one or more". Quand j'essaie avec l'aide la saisie d'adresses du plugin Cadastre de saisir des adresses sur plusieurs segments de la mme rue, seule une relation est cre pour le premier segment, une relation par nom de rue. Les autres adresses qui sont ajoutes par la suite sur d'autres segments d'une mme rue sont ensuite tous associs ce premier segment. Est-ce normal et conforme au Karlsruhe_Schema ? Illustration bidon pour l'exemple : Les deux segments portent le mme nom de rue "name". Les adresses encadres en vert ont t saisies en slectionnant la voie en magenta, celles encadres en rouge en slectionnant la voie en gris. Mais elles sont finalement toutes regroupes dans la mme relation associe la voie en magenta. Pour moi c'est une erreur. Quand est-il rellement ? Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Systèmes de numérotation des voi es en France.
Re... Selon : http://fr.wikipedia.org/wiki/Num%C3%A9rotation_des_voies#France ce sont bien les btiments qui sont numrots en France. Ni les parcelles, ni la rue elle mme. Donc je revois ma copie sur l'import semi-auto des adresses pour associer les adresses aux btiments "wall=yes" quand c'est possible, sinon limite parcellaire la plus proche et dfaut sa position dans la voie sur le Cadastre. Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Google copie sur OpenStreetMap
Etienne Chov a crit: Le 23/07/2010 10:31, Tanguy JACQ a crit : Bonjour, Je viens de m'apercevoir que google avait commenc a intgrer les btiments sur google map en pseudo 3d, je ne sais pas si a fait longtemps qu'ils ont commenc ... http://maps.google.com/maps?client=ubuntuchannel=fsq=montbeliardoe=utf-8ie=UTF8ei=8k9JTIiUKpa6jAfeiu3LDgved=0CBMQ_AUhq=hnear=Montb%C3%A9liard,+Doubs,+Franche-Comt%C3%A9,+Francell=47.510266,6.798327spn=0.0055,0.013894z=17 http://maps.google.com/maps?client=ubuntuchannel=fsq=montbeliardoe=utf-8ie=UTF8ei=8k9JTIiUKpa6jAfeiu3LDgved=0CBMQ_AUhq=hnear=Montb%C3%A9liard,+Doubs,+Franche-Comt%C3%A9,+Francell=47.510266,6.798327spn=0.0055,0.013894z=17 Ce qui montre que le calage de leur rues et/ou btiment n'est pas terrible. Ca a l'air d'tre fait partir du cadastre, car on voit des traits fins la limite wall=yes/no. Et des limites parcellaires qui coupent le bti :p ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Technique] Fwd: [OSM-dev] Help with implementation of multiplicatively weighted Voronoi diagram for nominatim
Vincent de Chateau-Thierry a écrit : C'est pour tendre vers cette unicité que Nominatim recourt à des polygones de Voronoï, en substitut de limites administratives ou postales. Le but reste de pouvoir associer sans trop d'ambiguïté un nom de rue à un nom de ville/village dont l'emprise, si elle n'existe pas, aura été approximée par un polygone dépendant de l'importance supposée de la place : c'est la pondération (weighted) recherchée dans le message initial. vincent Intéressant, je ne connaissais que la version points Delaunay/Voronoï. De quoi sont composés les limites des cellules ? D'une combinaison d'arcs de cercles et de segments de droites. Benoît R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Urgent][Serveurs FREE] Stoc kage/répartition des serveurs
Yoann ARNAUD a crit: Salut tous, Voil la problmatique qui se pose : Je stocke actuellement chez moi, dans mon garage, une dizaine de serveurs, qui ont t donns par la fondation free, il y a quelques mois. Je vais quitter Nantes la fin du mois de juillet pour rejoindre la "douce et charmante ville" de Montbliard. Donc je fais quoi de ces serveurs ? Certes, je pourrai tous les emmener avec moi, mais je ne vois pas trop l'utilit. Ce que je proposerai, c'est que l'on rpartisse les machines sur le territoire. L'avantage serait d'avoir de multiples interlocuteurs, si jamais un jour quelqu'un a besoin d'un serveur ou juste d'une pice de rechange (on a dj des disques qui ont claqu, a peut se reproduire) et ainsi d'agir avec plus d'efficacit. Je suis bien sr volontaire, pour en garder 2 ou 3 avec moi dans l'Est. Etienne en a aussi sous le coude. J'ai discut avec un membre de LOGIN, rcemment, qui va demander ce qu'il est possible de faire (pour rappel LOGIN est l'association qui a reu officiellement le don de serveurs). On a donc potentiellement 2-3 serveurs dans l'Est, 3-4 dans le grand Ouest. Qui serait volontaire pour en stocker sur Paris (j'y passe de temps en temps) ? Dans le Sud-Ouest (j'y passerai srement pendant l't) ? Ailleurs ? Je peux stocker sans limites sur Poitiers. Voir aussi avec Mickey86 si il a des ides ou des contacts pour une connexion dans le coin. Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Technique] Fwd: [OSM-dev] Help with implementation of multiplicatively weighted Voronoi diagram for nominatim
Bonjour, LA rfrence c'est http://www.cs.cmu.edu/~quake/triangle.html. Peut tre voir avec son auteur. Voir aussi pour info le site dans son ensemble (une des pages) : http://www.voronoi.com/wiki/index.php?title=Voronoi_Applications. Benot R. Sont adresse openstreet...@brian.quinion.co.uk n'est pas la bonne je vous laisse lui transfrer. Emilie Laffray a crit: Bonjour, je sais qu'il y a des gens tres pointus ici, donc je me permets de reposter. Le createur de Nominatim a besoin d'aide pour implementer un weighted Voronoi diagram utilisant CGAL. Donc s'il y a des gens qui peuvent aider, lui envoyer un message. Emilie Laffray -- Forwarded message -- From: Brian Quinion openstreet...@brian.quinion.co.uk Date: 21 July 2010 13:20 Subject: [OSM-dev] Help with implementation of multiplicatively weighted Voronoi diagram for nominatim To: d...@openstreetmap.org Hi, I've been trying to get a working implementation of a multiplicatively weighted Voronoi diagram written now for nearly a week and I'm really struggling. The intention is to use it to improve the the indexing quality and speed of nominatim with regards to mixing city, town and village points in some layers - I'm sure many of you have noticed the current problem were towns and villages end up inside city boundaries (producing weird addresses). I have a working implementation for a non-weighted algorithm using Fortune's algorithm [1] - if anyone has the time and maths skills to adapt that it would be wonderful (can Fortune's algorithm even do multiplicatively weighted Voronoi diagrams?) beyond that I've been looking at adapting the demo from cgal [2] but I'm struggling due to my poor C++ skills (and the fact that the c++ code makes use of insane numbers of templates). For someone who is really good with c++ or already familiar with cgal it would probably be fairly easy. Alternatively if anyone is aware of any other implementation or is able to implement anything based on a different library that would also be good. I think it really has to be c or c++ - anything else would be tricky to integrate. Potentially an implementation in R [3] using the postgresql module is another possibility. If anyone can help let me know - otherwise I will struggle onwards and hope to get somewhere! -- Brian [1] http://en.wikipedia.org/wiki/Fortune's_algorithm [2] http://www.cgal.org/Manual/latest/doc_html/cgal_manual/Apollonius_graph_2/Chapter_main.html [3] http://www.r-project.org/ ___ dev mailing list d...@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr Ce message entrant est certifi sans virus connu. Analyse effectue par AVG - www.avg.fr Version: 9.0.851 / Base de donnes virale: 271.1.1/3019 - Date: 07/21/10 08:36:00 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Entreprise de cartographie collabora tive basée sur OSM
Shnoulle a crit: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 21/07/2010 11:16, Franois Van Der Biest a crit : et je vais certainement m'installer en tant qu'auto entrepreneur Lionel RAUCH, co prsident de l'association C2iC Si je n'ai qu'un conseil donner, si possible viter le statut d'auto-entrepreneur. C'est un statut trop bancal qui amne plus de problmes au final que de solutions. Il est bien pour : les retraits, les personnes travaillant 3/4 temps 1/2 temps avec certitude de conserver leur poste jusque dmission. Sinon, trouver une autre solution avec l'aide d'organisme est sans doute la meilleure solution (ce tyoe d'organisme ne peut prendre en charge l'aide ncessaire que pour les entreprises dont le SIRET date de moins d'un an) :) +1 Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Technique] Fwd: [OSM-dev] Help with implementation of multiplicatively weighted Voronoi diagram for nominatim
Emilie Laffray a crit: 2010/7/21 Benot ROUSSEAU adressepossi...@free.fr Bonjour, LA rfrence c'est http://www.cs.cmu.edu/~quake/triangle.html. Peut tre voir avec son auteur. Voir aussi pour info le site dans son ensemble (une des pages) : http://www.voronoi.com/wiki/index.php?title=Voronoi_Applications. Benot R. Sont adresse openstreet...@brian.quinion.co.uk n'est pas la bonne je vous laisse lui transfrer. Tu peux me tutoyer :) Le lien que tu as donne ne permet pas de faire ce qu'il veut notamment de creer un poids pour chacun des noeuds. L'implementation que tu pointes est juste un diagramme de Voronoi de base. C'est pour cela qu'il regarde l'implementation dans CGAL, notamment une implementation de Appolinaris. Emilie Laffray Ouaip, bah je "m'a tromp" dans ces intentions, alors qu'il dit bien qu'il a une implmentation de base fonctionnelle. Halala lecture en diagonale, rponse trop rapide trafic inutile. Je sors le fouet... Mais j'aurai appris l'existence de ces graphs avec poids. Faut que je regarde la chose :) Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] extraction des lignes HT
hamster a crit: hamster a crit : dans le cadastre je suis tombe sur un trait pointille avec 2 traits une fleche, 2 traits une fleche (voir piece jointe) sur le terrain ca correspont a une ligne a haute tension peut etre quelqu'un qui sait pourrait coder ce qui va bien pour les extraire automatiquement ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr Bonjour Hamster, Pour extraire quelque chose des SVG du Cadastre, si on ne peux s'appuyer sur la couleur, il faut en connatre une particularit, comme par exemple l'attribut "style" du "path". Dans le SVG tu as des balises type path style="fill:none;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M -35407 -35581 L 36597 -35581 L 36597 [...]" /. Si tu me donnes le style correspondant je te fais l'extraction. Dans ton cas il est probablement vraiment spcifique. Pour ma part, pour trouver j'y vais ttons en supprimant des tags du SVG progressivement. Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Tech] Extraction des adresses...
Pieren a crit: [...] C'est justement ma crainte. C'est de faire faire la partie la plus utile mais la plus difficile par d'autres, plus tard. Il vaut mieux placer l'adresse au meilleur endroit au moment de sa cration que d'esprer que chaque application ira spculer sans trop se planter dans les relations entre adresses et autres POIs. Mais j'ai bien conscience que c'est un vrai challenge au niveau logiciel. Pieren Bonjour, J'aimerai bien que tu me dise ce qui est la "partie la plus utile" parce que j'ai beau chercher je ne vois pas. Un exemple ? Je vais attaquer la finalisation alors autant ne pas passer ct. Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] extraction des lignes HT
V a crit: Le 20 juillet 2010 06:10, Benot ROUSSEAU adressepossi...@free.fr a crit : Pour extraire quelque chose des SVG du Cadastre, si on ne peux s'appuyer sur la couleur, il faut en connatre une particularit, comme par exemple l'attribut "style" du "path". Dans le SVG tu as des balises type path style="fill:none;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M -35407 -35581 L 36597 -35581 L 36597 [...]" /. Si tu me donnes le style correspondant je te fais l'extraction. Dans ton cas il est probablement vraiment spcifique. L'attribut est 'style="fill:none;stroke-width:1.18;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:4;"' Cool ! mais chaque motif est sur un path spar. Challenge ! Pourrais t'on me joindre un petit svg par retour en priv (hors liste) ? Pour essayer. Pour ma part, pour trouver j'y vais ttons en supprimant des tags du SVG progressivement. Moi j'"imprime" la zone concerne sur le site du cadastre pour ne pas avoir un norme pdf comme cela peut l'tre sur tout un village, je la passe ensuite au pdf2svg et j'utilise l'diteur xml d'inkscape pour identifier rapidement les attributs correspondant ce que j'ai selectionn sur le dessin. Je fais pareil pour les petits SVG :p. Mais j'ai eu des diff entre impression interactive depuis le Cadastre et les exports SVG de ton script. Ais-je rv ? tait-ce li au changement de projection dans mon coin ? Je vais ressayer. Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] extraction des lignes HT
jul...@krilin.org a crit: Moi j'"imprime" la zone concerne sur le site du cadastre pour ne pas avoir un norme pdf comme cela peut l'tre sur tout un village, je la passe ensuite au pdf2svg et j'utilise l'diteur xml d'inkscape pour identifier rapidement les attributs correspondant ce que j'ai selectionn sur le dessin. Aprs reste a savoir si le cadastre est une "bonne" source pour les lignes a Haute Tension. Des taxes sont payes li a l'implantation des pylones ? O c'est une obligation lgale li la sant publique ou autre que d'tre informer quand tu achte un terrain qu'il est bti sur une ligne haute tension. O un pb d'organisation des travaux pour la ville. De toutes manires je ne pense pas que les agents de la DGI soient aller vrifier sous terre. La source doit tre un import de donnes avec pour source ERDF. Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Alerte ! Les doublons, ça grossi t sans arrêt - Était :Bâtiments se superposant
V a crit: Le 19 juillet 2010 11:52, Pieren pier...@gmail.com a crit : Sur le script, je suis d'accord qu'il faut d'avantage mettre en avant ces problmes. Personne ne semble vouloir faire l'effort d'en corriger les dfauts, en particulier son auteur original. Selon moi, le script n'a pas de dfaut, dans le sens o il remplit parfaitement son rle qui est de prendre les donnes vectoriels bruts du cadastre et d'en faire un fichier osm qui peut ensuite tre retrait comme bon semble son usager. Aprs s'il s'avre que les donnes en double sont cres par le script j'essaierai de corriger ce bug mais il me semble que les doublons sont dj dans le pdf (sur les rares exemples que j'ai pu voir). Aprs, le code est sur le svn, donc il est finalement assez facile de proposer un patch :-), 'V', si tu nous lis, est-ce que tu cherches corriger ces problmes de dublons dans le script ? Pas du tout, j'ai vu des cas tellement tordus (encore une fois surement pour privilgier le rendu) sur les quelques villages o j'ai pu chercher importer le bti, que je ne me risquerai pas essayer d'automatiser cela. Je pense qu'il risque d'tre difficile d'enlever le "semi" de "semi-automatique" et qu'il serait prfrable d'amliorer par exemple le validator de josm (certains ont parl de la mthode utilise pour CLC qui si j'ai bien compris calcule l'aire d'overlap entre deux polygones, je n'ai pas trouv de code mais peut tre cela peut il s'adapter pour amliorer le validator). Mme les auteurs du validator ne font pas d'effort pour corriger les erreurs des utilisateurs. _o_ ___ Juste concernant le Cadastre on voit dans les donnes pour tracer nombre de quadrilatres type parcelles, des squences comme : pt1 pt2 pt2 pt1 pt2 pt3 pt4 pt1. Ca explique peut-tre des duplications de points sur les btiments et d'autres choses. Tout ce qui sort du Cadastre sera SEMI-automatique et demandera un effort d'interprtation, qui plus est, conformment notre engagement de ne pas pomper sans retravailler. Tout a se transforme petit petit en avantages, la nature horreur du vide. Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Présentation
sacha bogdanov a crit: Bonjour, Je suis nouvel inscrit sur cette liste Je connais le projet depuis quelques temps car je travaille avec un serial mappeur (Marc Sibert). Je vis en Seine et Marne mais suis originaire de Guadeloupe pour qui la carte a t initie et qu' l'occasion de prochaines vacances, je compte complter. A bientt tous. Bienvenue, Avec un parrain pareil, on prsage du meilleur. :p Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] extraction des lignes HT
hamster a crit: sous terre ? en fait je parlais d'une ligne aerienne, avec des grands poteaux qu'on voit bien de loin et des cables qui font b quand y'a du brouillard :p le pointill ma tromp. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Tech] Extraction des adresses...
Pieren a crit: 2010/7/20 Benot ROUSSEAU adressepossi...@free.fr J'aimerai bien que tu me dise ce qui est la "partie la plus utile" parce que j'ai beau chercher je ne vois pas. Un exemple ? Je vais attaquer la finalisation alors autant ne pas passer ct. C'est le lien entre le node addr: et un polygone building qui peut contenir des POI. De nombreux btiments abritent plusieurs activits (restauration, commerce, services sociaux) et chacun est symbolis par un node. On ne place finalement l'information sur le polygone lui-mme que lorsque c'est l'ensemble du btiment qui est concern (ou lorsque c'est l'activit principale comme un htel avec juste un node pour le restaurant par exemple). Pour les applications qui n'utilisent qu'une adresse, il n'y a pas de problmes (navigation). Pour celles qui, par exemple, voudraient dresser la liste des pharmacies d'une ville avec leur addresse, il faut pouvoir retrouver ce lien. Pieren Donc l'ide serai, par exemple, de pouvoir monter un annuaire en plaant directement les adresses directement en tant que noeud sur les btiments quand ils existent. En automatique, je rponds non une nime fois. La qualit n'tant pas assure, ni si je le fais, ni si c'est fait aprs. Je prends l'exemple d'un centre commercial de Poitiers, l'lot des Cordeliers. Il occupe un pat de maisons et ouvre avec des adresses sur trois rues. Il inclut un parking souterrain, des magasins en galerie, des magasins en "faade" et des logements priv. Les btiments en faade ont une adresse et ne sont pas accessible depuis les autres. Les appartements ont une ou deux adresses, le parking, une adresse pour l'entre sortie, et les magasins de la galerie sont accessibles quelques adresses. Associer tout ce petit monde au btiment est exacte, associer tous ces commerces et rsidences toutes les adresses est faux, choisir pour chacun l'adresse la plus proche est faux aussi. Crer des relations entre les diffrents services et les adresses serait par contre une possibilit. Ou alors, ventuellement, rapprocher les POI services de leur adresse prfrentielle pour qu'un calcul de proximit puisse tre fait. Auquel cas le calcul peut tout aussi bien tre fait en direct. Dans le mme ordre d'ide, trouves-tu alors normal d'avoir calculer l'inclusion en temps rel de POI services (beaucoup plus couteux en temps) o places-tu les POI sur le way des btiments y compris pour ceux inclus (restaurant dans ton exemple). Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Tech] Extraction des adresses...
Pieren a crit:
2010/7/20 Benot ROUSSEAU adressepossi...@free.fr
Dans le mme ordre d'ide,
trouves-tu alors normal d'avoir calculer
l'inclusion en temps rel de POI services (beaucoup plus couteux en
temps) o places-tu les POI sur le way des btiments y compris pour
ceux inclus (restaurant dans ton exemple).
Les POI peuvent tre sur le way du btiment, sur un node attach au way
ou un node l'intrieur du polygone. Tous les cas de figures sont
possibles puisque personne n'est forc d'en respect un en particulier.
Mais la plupart des contributeurs vont utiliser le polygone comme point
de repre ("mon boulanger se trouve dans ce btiment-l"). Il faut donc
pouvoir lier ce polygone avec son adresse avec le moins de doute
possible, en y mettant les tags adresses soit sur le way, soit sur un
node, peu importe.
Je n'ai pas compris ta question sur l'inclusion de POI services. Mais
si tu parles de mon exemple de liste des pharmacies d'une ville, a
devrait pouvoir se faire dans un prtraitement automatique et non en
temps rel (mais pourquoi pas). Si les adresses ne sont pas lies aux
POIs travers le polygone du bti, cela devient plus compliqu et plus
incertain pour tous ceux qui voudront exploiter ces adresses dans le
futur (avec des rsultats qui pourront varier d'une appli l'autre).
Il restera toujours les cas plus complexes comme celui que tu cites qui
ncessiteront probablement d'avoir le tag addr sur chaque POI (une
pratique qu'il faudrait rserver ce genre de cas). Mais ces cas
seront ultra-minoritaires.
Pieren
Ok,
Pour simplifier mon propos, je pense que a passe par une relation
supplmentaire pour tre gnrique. Ce qui permettrai d'avoir le
routage tout de suite et les relations supp par dessus ds maintenant
ou plus tard. Faut-il attendre que toutes les pharmacies soient
"tagguer" pour importer des adresses et ainsi de suite si qqun veux :
un annuaire des boulangeries, ... ? Ce n'est pas un troll pour discuter
de l'utilisation des relations ou de leur multiplication. Quant
l'incertitude, elle ne peut tre leve qu'humainement, je ne ferai pas
mieux en pr traitement qu'en traitement temps rel et je ne veux pas
ajouter des erreurs supplmentaires. J'ai presque l'impression qu'on
est d'accord, mais reste un truc, un quiproquo, va falloir laisser un
peu d'eau couler sous les ponts ce sujet. J'ai testerai sur Quincay
(86), on verra l'usage quelles solutions peuvent tre apportes pour
satisfaire le plus grand nombre.
Donc veux tu bien qu'on regarde ensemble la procdure d'import
SEMI-auto des adresses ? Vous tes tous invits, il y a pas mal
dblayer.
A- Il faut des rues pour y attacher les panneaux d'adresses.
Deux possibilits :
1 - on ne monte que les adresses pour les voies nommes ;
2 - on nomme la voie avec un nom particulier "Voie non nomme X"
plus fixme et on monte les adresses, c'est reprable et prt pour celui
qui trouvera le nom.
B - Une ou des relations existent dj pour la voie en base.
1 - on crase si plus d'adresses ;
2 - on propose une fusion en compltant avec les n manquants ;
3 - on en ajoute une avec les n manquants ;
4 - on n'importe rien.
C - Faut-il proposer une importation par rue ? Je souhaite extraire les
lments d'adresse de la rue "Rue du chne" pour une importation. et/ou
une commune ?
D - Faut-il "tagguer" ces adresses avec un "tag" spcifique genre
"note=import-adr-auto " pour pouvoir les reprer par la suite ?
D - est qu'un logiciel d'import interactif spcifique (qui visualise
et pose des questions spcifiques) serait mieux que de charger sous
JOSM ?
Benot R.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Tech] Extraction des adresses...
Denis a crit: Benot ROUSSEAU a crit : Donc l'ide serai, par exemple, de pouvoir monter un annuaire en plaant directement les adresses directement en tant que noeud sur les btiments quand ils existent. Pas plus qu'OSM ne doit tagger pour le rendu, nous ne devons pas modliser pour des applications particulires , amha. J'avoue que la question de l'adressage est trs loin d'tre simple grer pour un projet comme le ntre. Outre les questions de toponymie, d'valuation de l'exhaustivit (notion importante pour la plupart des acteurs publics qui pourraient s'appuyer sur notre travail), des outils mis en test en ce moment (qui me font assez peur, pour le moment), il est ncessaire de se poser la question de savoir ce que nous voulons : un rfrentiel -mme incomplet ou imparfait- pour des services de secours, une base pour du calcul d'itinraire "porte--porte", etc. J'ai peur qu'on ne se soit lanc dans dfi encore au-dessus de notre porte. Je m'explique plus bas. Houla ! Sortie de son contexte, la phrase laisserai penser que je fais la promotion de cette ide. Ce n'est absolument pas le cas. En automatique, je rponds non une nime fois. La qualit n'tant pas assure, ni si je le fais, ni si c'est fait aprs. Je prends l'exemple d'un centre commercial de Poitiers, l'lot des Cordeliers. Il occupe un pat de maisons et ouvre avec des adresses sur trois rues. Il inclut un parking souterrain, des magasins en galerie, des magasins en "faade" et des logements priv. Les btiments en faade ont une adresse et ne sont pas accessible depuis les autres. Les appartements ont une ou deux adresses, le parking, une adresse pour l'entre sortie, et les magasins de la galerie sont accessibles quelques adresses. Associer tout ce petit monde au btiment est exacte, associer tous ces commerces et rsidences toutes les adresses est faux, choisir pour chacun l'adresse la plus proche est faux aussi. Crer des relations entre les diffrents services et les adresses serait par contre une possibilit. Ou alors, ventuellement, rapprocher les POI services de leur adresse prfrentielle pour qu'un calcul de proximit puisse tre fait. Auquel cas le calcul peut tout aussi bien tre fait en direct. Je crois (c'est donc un acte de foi) qu'OSM a vocation interprter le monde tel qu'il le conoit et/ou le constate. Cela implique que la mme "ralit" soit vue diffremment suivant les contributeurs. L'effet communaut doit conduire ce qu'une boulangerie Brest, Toulouse, Grenoble ou Strasbourg soit identifiable comme telle partout. En quoi une adresse postale est-elle diffrente d'une boulangerie (sous l'angle du tag) ? Je crois qu'une adresse est un moyen, pas une fin. Elle sert identifier un point de dpart ou d'arrive dans une application de calcul d'itinraire (peu importe ce que ces adresses desservent). Elle sert aussi identifier des personnes (physiques ou morales) ; c'est le fameux argument de la CNIL (localisant indirect). La mme adresse peut concerner plusieurs acteurs et un mme acteur peut avoir plusieurs adresses (certaines mme difficilement localisables -penser Boite Postale, CEDEX-) Je ne crois qu'il est pas du ressort d'OSM de grer cette relation n-n. En revanche, nous avons toute lgitimit pour indiquer que telle adresse postale est golocalise par un couple de coordonnes. Je suis bien d'accord. Peut tre aurais-tu d rpondre Pieren peut tre. Je suis avec beaucoup d'intrt les tous derniers outils de traitement des donnes cadastrales ; il y a des avances indniables, mais aussi des cueils dont il faut se mfier. J'ai appris, ces derniers temps me mfier de mes propres contributions dans le domaine de l'adressage. La vrit est dure trouver : elle n'est ni dans le cadastre, ni dans les pages jaunes, ni mme dans les bases de donnes "pro", mais partout la fois (parfois nulle part). Donc ne pas ajouter des erreurs aux erreurs invitables qui vont dj s'y glisser tout en indiquant source et traitement. Qu'une "entre-sortie" (oximore ou I/O ?) de parking ait une adresse me laisse, titre personnel, perplexe, mais je suis comme Saint-Thomas, je peux me laisser convaincre par des preuves. En ce qui concerne le parking, c'est une socit en elle mme pas le parking d'une autre. Denis Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Tech] Extraction des adresses...
Mickey86 a crit: Le lundi 19 juillet 2010 07:31:03, hamster a crit : Benot ROUSSEAU a crit : Les adresses sont maintenant dplaces x mtres du centre de la voie trace dans OSM (plus propre) et notes sur les erreurs potentielles et mettre l'adresse en question sur le batiement le plus proche et non pas a x metre de la voie, ca serait faisable ? variante : mettre l'adresse sous forme d'un noeud sur le chemin du batiment le plus proche, en positionnant du cote ou le chemin du batiment est le plus proche de la rue C'est possible, mais le risque d'erreur me semble beaucoup trop lv. Pour ce qui est d'un nud ou le btiment c'est du pareil au mme ct programmation. Ou la limite de la parcelle si le btiment est trop loin. C'est possible aussi mais l encore, le risque d'erreur me semble trop lev. Beaucoup de parcelles ou de btiments sont loin de leur n de voie (alles prives, bt imbriqus, ...) ou proches d'une autre (toutes les intersections, ..). Les btiments sont parfois nombreux pour une adresse. Faut-il tous les nter, faut-il risquer de nter la grange ? A avoir boss sur les adresses, j'ai chang d'avis sur les mthodes de numrotation. J'ai essay les deux systmes de ntation bt et plaques. La signification premire de ces numros c'est un reprage li et dans la rue. Donner un n un btiment moins de sens et quand on cherche un n de rue on cherche se positionner au sein de cette rue. Et penser aux btiments plusieurs adresses (aux croisements, ceux qui donnent sur deux rues devant derrire, ...). Finalement les plaques de n sont les plus utiles et ce qui fait le plus sens, le n est bien li la rue. Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Tech] Extraction des adresses...
Mikaël Cordon a écrit : Le 19 juillet 2010 08:24, Benoît ROUSSEAU adressepossi...@free.fr a écrit : Mickey86 a écrit : Le lundi 19 juillet 2010 07:31:03, hamster a écrit : Benoît ROUSSEAU a écrit : Les adresses sont maintenant déplacées à x mètres du centre de la voie tracée dans OSM (plus propre) et notées sur les erreurs potentielles et mettre l'adresse en question sur le batiement le plus proche et non pas a x metre de la voie, ca serait faisable ? variante : mettre l'adresse sous forme d'un noeud sur le chemin du batiment le plus proche, en positionnant du cote ou le chemin du batiment est le plus proche de la rue C'est possible, mais le risque d'erreur me semble beaucoup trop élévé. Pour ce qui est d'un nœud ou le bâtiment c'est du pareil au même côté programmation. Ou à la limite de la parcelle si le bâtiment est trop loin. C'est possible aussi mais là encore, le risque d'erreur me semble trop élevé. Beaucoup de parcelles ou de bâtiments sont loin de leur n° de voie (allées privées, bât imbriqués, ...) ou proches d'une autre (toutes les intersections, ..). Les bâtiments sont parfois nombreux pour une adresse. Faut-il tous les n°ter, faut-il risquer de n°ter la grange ? A avoir bossé sur les adresses, j'ai changé d'avis sur les méthodes de numérotation. J'ai essayé les deux systèmes de n°tation bât et plaques. La signification première de ces numéros c'est un repérage lié à et dans la rue. Donner un n° à un bâtiment à moins de sens et quand on cherche un n° de rue on cherche à se positionner au sein de cette rue. Et penser aux bâtiments à plusieurs adresses (aux croisements, ceux qui donnent sur deux rues devant derrière, ...). Finalement les plaques de n° sont les plus utiles et ce qui fait le plus sens, le n° est bien lié à la rue. Je suis tout à fait d’accord ! :) En fait, ma proposition de mettre sur la limite de parcelle était dans un soucis de placement automatique sachant que la parcelle le plus souvent colle la rue, plutôt qu’une distance arbitraire par rapport au centre de la rue (ce qui dépend de la largeur de la rue). Et dans les faits, lorsque le bâtiment ne colle pas la limite de la parcelle et si le bâtiment est assez éloigné, à la main je positionne le numéro sur la limite de la parcelle. Mais c’est une méthode personnelle. Ok pigé, je vais voir ça... mais ça demande beaucoup du taf, donc patience. Benoît R. ___ 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] [Tech] Extraction des adresses...
Pieren a crit: 2010/7/19 Benot ROUSSEAU adressepossi...@free.fr Beaucoup de parcelles ou de btiments sont loin de leur n de voie (alles prives, bt imbriqus, ...) ou proches d'une autre (toutes les intersections, ..). Les btiments sont parfois nombreux pour une adresse. Faut-il tous les nter, faut-il risquer de nter la grange ? A avoir boss sur les adresses, j'ai chang d'avis sur les mthodes de numrotation. J'ai essay les deux systmes de ntation bt et plaques. La signification premire de ces numros c'est un reprage li et dans la rue. Donner un n un btiment moins de sens et quand on cherche un n de rue on cherche se positionner au sein de cette rue. Et penser aux btiments plusieurs adresses (aux croisements, ceux qui donnent sur deux rues devant derrire, ...). Finalement les plaques de n sont les plus utiles et ce qui fait le plus sens, le n est bien li la rue. Benot R. Je prfre le numro sur un node attach la faade du btiment parce que j'y trouve plusieurs avantages: - on fait la diffrence entre le btiment principal et le garage ou la grange - on identifie la faade du bti (si le cadastre respecte la rgle de placer le numro sur les botes aux lettres, ce qui n'est pas toujours le cas) - on gre les numros multiples sur un polygone sans problmes ni questions - on lie par une mthode graphique (diteur) plusieurs informations si le polygone contient d'autre part des tags (amenity, shop, etc) sur le way ou sur d'autres nodes/POI l'intrieur. Personnellement, je prfererais que l'outil cherche le mur perpendiculaire la route le plus proche (en face du numro), ce qui devrait assez souvent fonctionner, surtout en zone urbaine. Et s'il y a un doute, de le faire la main. Pieren Bonjour, En zone urbaine, mon avis, pas encore test, bosser avec ton ton plug va plus vite. Les adresses sont proches, a va vite. Comme dj voqu, mon avis ce sera plus utile en campagne. La rgle des BALs c'est termin en campagne les BALs persos au portail sont remplaces par des totems en "milieu" d'lot. Tous ce que tu voques comme relation d'informations supplmentaires adresses peut se faire comme tu le dis, mais par la suite. Attaquer l'api et calculer la faade la plus proche o dans la vise ortho n'est ni complexe ni gourmand en calculs. Je prfrerai que l'erreur faite soit ce moment l, plutt qu'au placement du numro. Pour ma part, je m'interdit d'intervenir automatiquement sur la structure des btiments en ajoutant un ou des points sur une faade. Puis, en cas d'erreur, grande chelle, en semi auto, woooh ! Par contre, si certains veulent tenter la chose (en java multi-plateforme par exemple), je vous donne tous les lments pour. Ce que je vous propose d'essayer, Hamster, Mickey86 et Pierren, C'est de positionner la plaque "l'intersection orthogonale" du segment le plus proche dans les x mtres. Si c'est une faade, si c'est une limite parcellaire, un mur, ... Ca devrait convenir tous le monde. La plaque n'est pas loigne de plus de x mtres de la voie et si un lment est sur le trajet, il emporte le placement. Est-il lgal et souhaitable (thique) d'identifier un bti directement par son adresse ? Facilit accrue de croiser des informations personnelles et d'en dduire des revenus en fonction de la taille de la maison, ... L je ne sais pas rpondre ni o chercher des infos. S'il y a des juristes... Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Tech] Extraction des adresses...
Pieren a crit:
2010/7/19 Benot ROUSSEAU adressepossi...@free.fr
En zone urbaine, mon
avis, pas encore test, bosser avec ton ton
plug va plus vite. Les adresses sont proches, a va vite. Comme dj
voqu, mon avis ce sera plus utile en campagne.
C'est risqu parce que ton outil sera utilis pour tous les cas de
figure une fois disponible. Et on le voit en ce moment avec les
doublons ou avec d'autres outils, certains attachent plus d'importance
la quantit qu' la qualit.
Arrte, j'en tremble dj. Bon j'ai peut-tre des solutions mais c'est
tester.
La rgle des BALs c'est
termin en campagne les BALs persos au
portail sont remplaces par des totems en "milieu" d'lot.
Ca dpend de l'anciennet du bti.
Pas chez nous.
Tous ce que tu
voques comme relation d'informations
supplmentaires adresses peut se faire comme tu le dis, mais par la
suite. Attaquer l'api et calculer la faade la plus proche o dans la
vise ortho n'est ni complexe ni gourmand en calculs.
C'est justement ma crainte. C'est de faire faire la partie la plus
utile mais la plus difficile par d'autres, plus tard. Il vaut mieux
placer l'adresse au meilleur endroit au moment de sa cration que
d'esprer que chaque application ira spculer sans trop se planter dans
les relations entre adresses et autres POIs. Mais j'ai bien conscience
que c'est un vrai challenge au niveau logiciel.
Ca n'a rien de difficile, c'est dj dans le logiciel et c'est de loin
le plus simple que j'ai eu coder, c'est quelques lignes. Entre les
projections, les communications avec le cadastre et l'api, le parser
SVG, le reconnaissance des chiffres, ... Comme tu le dis au dessus, je
ne veux pas gnrer des erreurs en nombre automatiquement, j'aimerai
rester dans l'acceptable. Et dans ce cas, moins de m'expliquer une
mthode pour assurer un nombre tolrable d'erreur, pour ma part je ne
m'engage pas l dessus. Mais rien n'empche par la suite d'associer
automatiquement les adresses aux bti les plus proches, ca n'a rien de
difficile mme l'chelle de la France car c'est finalement trs peu
de points. Je donnerai tous les lments si qqun souhaite le faire.
double Distance(ref PointD pt1seg, ref PointD pt2seg)
{
double ampx = pt2seg.X - pt1seg.X;
double ampy = pt2seg.Y - pt1seg.Y;
return Math.Sqrt((ampx * ampx) + (ampy * ampy));
}
PointD IntersectionOrthoPointSegment(PointD ptadr, PointD
ptseg1, PointD ptseg2)
{
PointD ptintersec = new PointD(Double.NaN, Double.NaN);
double longueur = Distance(ref ptseg1, ref ptseg2);
double dterminant = (((ptadr.X - ptseg1.X) * (ptseg2.X -
ptseg1.X)) + ((ptadr.Y - ptseg1.Y) * (ptseg2.Y - ptseg1.Y))) /
(longueur * longueur);
if (dterminant 0.0 || dterminant 1.0)
return ptintersec; // le point n'est pas dans le
segment
ptintersec.X = ptseg1.X + dterminant * (ptseg2.X -
ptseg1.X);
ptintersec.Y = ptseg1.Y + dterminant * (ptseg2.Y -
ptseg1.Y);
return ptintersec;
}
IntersectionVoie VoieLaPlusProche(Adresse adresse,
double distancemax)
{
IntersectionVoie intersection = new IntersectionVoie();
PointD ptcoords = new PointD(adresse.Lon, adresse.Lat);
PointD pttmp = new PointD();
double distancemin = double.MaxValue;
double distance = double.MaxValue;
foreach (VoieAdressable voie in g_Voies)
{
for (int i = 0; i voie.Points.Count - 1; i++)
{
pttmp = IntersectionOrthoPointSegment(ptcoords,
voie.Points[i], voie.Points[i + 1]);
if (Double.IsNaN(pttmp.X))
continue;
distance = Distance(ref ptcoords, ref pttmp);
if (distance distancemax)
continue;
if (distance distancemin)
continue;
distancemin = distance;
intersection.Point = pttmp;
intersection.IdVoie = voie.IdWay;
}
}
Pieren
Benot R.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Tech] Extraction des adresses...
Pieren a crit: Ta proposition est assez dlicate mettre en place vu que l'outil d'extraction du pdf ne distingue pas les limites parcellaires. Et il y a de nombreux endroits o les sont dessins entre le milieu de la route et la parcelle. Pieren Les quoi entre le milieu de la route et la parcelle ? Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Alerte ! Les doublons, ça grossi t sans arrêt - Était :Bâtiments se superposant
Pierre-Alain Dorange a crit: Le 19 juil. 10 17:57, Pieren a crit : Je viens d'envoyer un message 'square' pour lui dire d'employer une mthode plus carre. J'ai aussi contact Square cet aprs-midi et effectivement il c'tait aperu depuis hier qu'il y avait un problme et a dj commenc y travailler, tout en s'excusant. Il chercher ventuellement un moyen de rattraper les erreurs rapidement... -- Pierre-Alain Dorange, Blog Citoyen de Cognac : http://cognac-citoyen.blogspot.com/ Twitter : https://twitter.com/padorange -Facebook : http://www.facebook.com/pa.dorange Juste un avis, le traitement sera plus rapide en automatique mme si Marc fait pour l'instant la main. Je vais voir avec lui pour modifier mon logiciel afin qu'il ai moins de traitements manuels et l'aider pour aller plus vite. Le plus important c'est surtout de ne plus gnrer de doublons, n'en j'tez plus. Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Motivations des contributeurs d'OSM
Arnaud Vandecasteele a crit: Bonjour a tous, Il me semble avoir vu passer un document listant les motivations des contributeurs d'OSM. Ce document a t publi lors du SOTM2010. Cela vous rappelle-t-il quelque chose ? De plus toujours ce sujet, je m'interroge sur les motivations premires qui nous ont pousss participer OSM et surtout continuer . Je ne parle pas des motivations d'aujourd'hui maintenant que vous tes des habitus, mais de celles du tout dbut quand vous saviez peine a quoi correspondait l'acronyme OSM :) Me basant sur mon exprience personnelle, j'en ai list quelques-unes : * la libert de cration * l'importante communaut * ct fun * le fait de pouvoir se tromper * la sensation s'explorer de nouveaux territoires * le fait de pouvoir s'impliquer progressivement * participer a un projet libre avez vous d'autres facteurs qui vous ont incit contribuer et surtout qui vous a donn envie de continuer? Arnaud - disposer de cartes libres pour diffrents projets. - librer des donnes publiques (va falloir que j'avance d'ailleurs) car il est trs difficile d'obtenir certaines donnes pourtant thoriquement "publiques" ou de pouvoir les exploiter. - intrt pour le monde (si petit). - se ct dfi, si on s'y met tous on peux. Puis, je n'ai non pas re dcouvert, mais, dcouvert mon environnement proche, celui de mon enfance, ... Un grande surprise de voir que je ne le connaissais pas ! Et pourtant... Bent R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Tech] Extraction des adresses...
Pieren a crit: 2010/7/19 Benot ROUSSEAU adressepossi...@free.fr Ta proposition est assez dlicate mettre en place vu que l'outil d'extraction du pdf ne distingue pas les limites parcellaires. Et il y a de nombreux endroits o les sont dessins entre le milieu de la route et la parcelle. Pieren Les quoi entre le milieu de la route et la parcelle ? Oups,les "trottoirs". Pardon. En ce qui concerne le chargement des limites parcellaires actuellement a donne a : (voir image la suite). Donc on peux faire le distingo avec ce qu'on a... Le filtrage limine les ponts, les traits de renvoi des n aux parcelles, les terre-pleins et certains trottoirs (peut-tre en reste t'il selon comment ils sont saisis). Ceci, dans la version que j'ai d'un SVG. Reste que c'est le bazar par endroits. C'est se demander si la vectorisation n'est pas faite pour le rendu qui serait obtenu par superposition de couches (dans le mme calques). Ca reste une hypothse vrifier... Donc pour le calage des adresses en limite de parcelles, c'est possible. Est-ce que a gnrera plus d'erreurs de positionnement des adresses ? Mystre ! Disons que le Cadastre est parfois surprenant : des maisons en parcelles, des raccords approximatifs, ... On ne va pas s'en plaindre il n'est pas destin l'usage que nous en faisons. On peux aussi envisager, de plus en plus, l'extraction d'autres lments comme les cimetires, ... car les calques sont prsents dans les svg sous forme de groupes (si a donne des ides d'autres). Auquel cas, limiter la reconnaissance des symboles sur une couche particulire est plus ais et l'on doit pouvoir par la suite retrouver la/les parcelle/s (pour les cimetires, ...) ou les btiments (glises, ...) lis en superposition. Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] [Tech] Extraction des adresses...
Bonjour, Ca avance, voici un aperu de l'import sous JOSM : En gros, il ne manque que l'criture des relations dans le fichier OSM. Les adresses sont maintenant dplaces x mtres du centre de la voie trace dans OSM (plus propre) et notes sur les erreurs potentielles. Les adresses potentiellement errones sont tiquetes avec un fixme=ADRER-0X; ... qui contient le(s) type(s) d'avertissement(s) lis celle-ci. Le programme est prudent et avertit d'un fixme plutt que de laisser passer. Les avertissements sont : - ERADR-01 : cette adresse n'est lie ni une voie ni une relation. - ERADR-03 : cette adresse est proche d'une voie mais sans relation. Erreur potentielle proximit d'une intersection. - ERADR-05 : doublon d'adresse dans la relation. - ERADR-07 : saut anormalement lev de numrotation. Erreur potentielle sur le n marqu ou le prcdent. Dans l'aperu ci dessus, sous JOSM, j'ai filtr les adresses avec un fixme (en gris), il y a dans cette rue deux n23 (points verts), peut-tre une erreur sur le Cadastre. Le n23 le plus gauche est bien not en erreur... Idem pour le reste. Je n'ai pas regard toutes les adresses une par une, mais la notation d'erreur m'a dvoil des erreurs que je n'avais pas dtectes visuellement. L'un dans l'autre a devrait bien se passer ... Avantage, tout a n'est viable que si les voies sont parfaitement saisies ; c.a.d. bien segmentes, nommes, positionnes, ... Le programme est vraiment rvlateur et on a des surprises ! Esprons qu'une explosion des voies suivra celle bti, ou l'inverse car on est pas oblig d'importer le bti. Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] noeuds dupliques, ou peut etre pas
Bonjour Hamster, J'ai averti que je lanais une suppression automatique des (30842) nuds orphelins. J'ai du en supprimer environ 2 (en 6 heures). Il est possible qu'ils soient passs dans le lot. Je ne comprends pas ta phrase, c'est un bien ou un mal ? Tu les as supprims et tu ne les retrouvent pas ? Tu veux dire que tu n'en as pas trace dans quelque chose comme http://www.openstreetmap.org/browse/node/806737877 ? Benot R. Tenshu a crit: J'ai vu des faux positifs personnellement mais pas autant c'est vrai. 2010/7/17 hamster hams...@suna.fdn.fr mon import du cadastre sut orsay a fait plein de noeuds dupliques : http://matt.dev.openstreetmap.org/dupe_nodes/?zoom=16lat=48.68026lon=2.18087layers=BT mon probleme c'est que j'ai supprime tous ces noeuds dupliques il y a quelques jours deja, et aujourd'hui je ne parviens pas a les trouver quand je les cherche dans JOSM pourtant sur le site des dupe nodes ils disent que c'est mis a jour a la minute : http://matt.dev.openstreetmap.org/dupe_nodes/about.html alors finalement je sait plus si ils y sont toujours ou pas, et si oui comment les corriger ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] noeuds dupliques, ou peut etre pas
Erwan de FERRIERES a écrit : Le 17/07/2010 19:59, Christophe Merlet a écrit : Le samedi 17 juillet 2010 à 19:52 +0200, Benoît ROUSSEAU a écrit : Bonjour Hamster, J'ai averti que je lançais une suppression automatique des (30842) nœuds orphelins. J'ai du en supprimer environ 2 (en 6 heures). Il est possible qu'ils soient passés dans le lot. Je ne comprends pas ta phrase, c'est un bien ou un mal ? Tu les as supprimés et tu ne les retrouvent pas ? Tu veux dire que tu n'en as pas trace dans quelque chose comme http://www.openstreetmap.org/browse/node/806737877 ? je crois surtout que c'est le site dupe_nodes qui n'est plus à jour depuis 48 heures et qu'il affiche toujours des nœuds dupliqués supprimés depuis un petit moment. je pense que c'est la même chose, j'en ai corrigé quelques un de mon côté, et ce n'est toujours pas mis à jour... Merci pour l'explication :p j'suis passé à côté. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSRoad Demo
Jean a crit: Je viens d'installer une dmo d'OSRoad. http://osroad.sourceforge.net/demo/ Pour rappel, OSRoad est un application permettant d'afficher le status de routes au format GPX, ainsi que d'afficher des points remarquables sur une carte OpenStreetMap. Apache/IIS, PHP, Mysql sont les composants ncessaires. Vous trouverez le tout l'adresse : http://sourceforge.net/projects/osroad/ Procdure d'install : http://osroad.sourceforge.net/ Pour voir la partie admin, l'url est : http://osroad.sourceforge.net/demo/admin/ user : demo pass : demo J'ai besoin de personnes pour analyser les failles de scurit au niveau injection sql notamment. Bons tests Jean CARTIER Bravo ! Trs utile a ! Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Creation liste mapty-fr
Philippe Pary a crit: Le vendredi 16 juillet 2010 15:21 +0200, hamster a crit : je suis pour, mais tant que tu y est si tu demande aussi la creation d'une liste debutants-fr (ou tout autre nom) pour les debutants, je pense que c'est la que le besoin est le plus pressant (j'ai quelques copains qui n'arrivent pas a demarrer et qui ne profitent pas de l'aide de cette liste precisement a cause du flux de messages trop important) je pense aussi que tout ce qui est programmation est assez distinct du reste et pourrait facilement etre separe dans une liste devel-fr (par exemple) Ce sont deux ides qui me paraissent encore plus intressantes que la liste pour les mapping parties. La cration de ces 3 listes (mapping parties, dbutant et devel) me parait tre une bonne ide Philippe Bonjour, Je ne suis pas sr qu'isoler les dbutants, les dev, les expriments, les organisateurs, .. soit une bonne ide. J'avoue avoir progresser plus rapidement parce que j'ai entendu, les dev, les mappeurs, les organisateurs, les gourous, ... parce que je participais un tout. Il ya le bizutage comme partout sur les questions de dbutant, mais rien de mchant et c'est inhrent toute initiation... Il est intressant en tant que dbutant d'entendre ce qui se passe un peu partout. Je pense qu'il vaudrait mieux apprendre grer une mailling liste. Pour les Mapping party, je crois que le site osm-fr propose un flux rss en doublon de billets blog ce qui est la manire de faire pour promulguer. +2cents. Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Creation liste mapty-fr
Nicolas Dumoulin a écrit : Je ne suis pas sûr qu'isoler les débutants, les dev, les expérimentés, les organisateurs, .. soit une bonne idée. J'avoue avoir progresser plus rapidement parce que j'ai entendu, les dev, les mappeurs, les organisateurs, les gourous, ... parce que je participais à un tout. Il ya le bizutage comme partout sur les questions de débutant, mais rien de méchant et c'est inhérent à toute initiation... Il est intéressant en tant que débutant d'entendre ce qui se passe un peu partout. Bonjour, Allez, moi aussi je continues à participer au flood ;-) Je ne pense pas que le résultat isole les utilisateurs, mais améliore justeme le ciblage des discussions. Par exemple, pour ma part je resterai abonné aux 3-4 listes. Un nouveau qui débarque voudra peut-être commencer par la liste débutant ou ça ne cause pas trop de relations partout et de requête sql. Mais si tout l'intéresse, il pourra suivre tout. L'idée me plaît car elle offre le choix, et si on ne veut pas s'embêter, on s'abonne à tout. Le seul risque à mes yeux peut être les fils qui dérivent … mais ça devrait bien se gérer je pense. Yaka … on verra. Les catégories proposées sont peut-être perfectibles, mais j'ai pas réfléchi à mieux. +1 Re, Donc, on risque de retrouver les mêmes partout donc et on se recentrera sur une liste :p. Pour donner un exemple, prenons, l'import semi auto des adresses. Beaucoup de retours pertinents sur les usages liés au Cadastre (n°tation métrique, ...) ... Je crains, peut-être à tort, qu'une liste de "devs" pondent des logiciels de "devs" et se coupe de l'expérience de non devs dans des domaines très variés. J'aime bien, comme Julien T., l'idée des [sujet], mais il semble que cela est déjà été testé sans succès. De toutes manières, je ne suis pas foncièrement contre l'idée de mailling lists séparées donc essayons, on verra bien. Mais comme Émilie L. le proposait à d'autres niveaux, essayons de conserver une relation entre elles, ptet des "bulk/digest" (mais c'est du taff et je n'y crois pas trop). Benoît R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Creation liste mapty-fr
Gilles Bassire a crit: Jean-Francois Nifenecker wrote: Le 16/07/2010 16:03, Rodolphe Quiedeville a crit : Dcouper sur plusieurs listes en une seule fois multiplie le risque de perdre des gens en route. Une liste de discussion c'est un quilibre subtil entre un grand nombre d'acteur (posteur, lecteur, lecteur/posteur, ...) je prconise toujours de commencer par crer une premire liste annexe et de prendre le temps d'observer le r-quilibrage qui s'effectue. Ensuite suivant le rsultat il sera toujours temps de crer de nouvelles listes pour dcharger celle-ci. D'accord l-dessus : on teste et aprs quelques mois on fait le bilan. Je vote pour une liste "dbutants" (nom exact dfinir) qui est ce qui manque le plus, ama. +1 pour crer une premire liste avant de continuer. +1 pour que cette liste soit celle destin au support utilisateur. +1 c'est raisonnable +1 "support" n'est rassurant et pas "pjoratif/exclusif". On sent que qu'on peux poser la question "bte". Support, moi je m'en servirai toujours parce que plus j'apprends plus je vois que je ne sais pas. Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Chemins ruraux et communaux le retour
A la lecture du fil Re: [OSM-talk-fr] Btiment avec un prau : "Les relations ne sont pas des catgories" http://wiki.openstreetmap.org/wiki/FR:Relations/Relations_are_not_Categories (traduite pour l'occasion ;-) ) Voil qui rsout l'ajout de l'info sur les chemins ruraux et communaux en relations de plusieurs voies du plusieurs types. L a se tient. Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
