Re: [OSM-talk-fr] Import bâti cadastre dans JOSM
Calage du cadastre avec l'ortho-imagerie : là aussi ça revient tous les 6 mois ! L'erreur est en général constante planche par planche, il faut donc sélectionner les objets d'une même planche en espérant que personne n'a déplacé certains objets à la main entre temps. Mais tant que tu travailles en relatif, l'erreur n'est pas trop gênante. Jean-Yvon ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti cadastre dans JOSM
Bonjour, Le 28/12/2019 à 11:38, rainerU a écrit : Est-ce un bug ou y a-t-il une vrai différence de mise mise à jour ? Non ce n'est pas un bug. Le cadastre sur cadastre.openstreetmap.fr est pris à la source, directement sur les serveurs de cadastre.gouv.fr. Il est donc mis à jour au rythme des mises à jours des serveurs du site, à savoir quotidiennement. Côté Etalab, la mise à jour est trimestrielle, on peut s'attendre à une mise à jour en janvier si le rythme donné dans l'historique est tenu : https://cadastre.data.gouv.fr/datasets/cadastre-etalab vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti cadastre dans JOSM
Le 28.12.19 à 11:38, rainerU a écrit : > j'ai constaté que les données dans les fichiers générés sur > cadastre.openstreetmap.fr étaient plus à jour que les données Etalab. > Par exemple ici: > > https://www.openstreetmap.org/#map=19/42.62719/2.76934 > > Est-ce un bug ou y a-t-il une vrai différence de mise mise à jour ? Etalab via plugin josm : maj trimestrielle pdf via cadastre.openstreetmap.fr : maj en continu ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti cadastre dans JOSM
Am 26.12.19 um 21:10 schrieb Vincent de Château-Thierry: Le sujet ici c'est de savoir si on doit maintenir une page (l'actuelle cadastre.openstreetmap.fr) qui s'appuie sur un processus d'accès au Cadastre (le recours aux PDFs d'impression de cadastre.gouv.fr) qui certes nous a sauvé la mise pendant des années, mais a avec le temps été rendu plus gourmand en ressources et est devenu obsolète avec l'apparition du cadastre redifusé par Etalab. Je me suis posé cette question quand j'ai découvert, par hasard, la possibilité de télécharger les données Etalab dans JOSM. Après, j'ai constaté que les données dans les fichiers générés sur cadastre.openstreetmap.fr étaient plus à jour que les données Etalab. Par exemple ici: https://www.openstreetmap.org/#map=19/42.62719/2.76934 Est-ce un bug ou y a-t-il une vrai différence de mise mise à jour ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti cadastre dans JOSM
Je confirme, on ne peut pas simplement faire une sélection multiple et glisser le tout, c'est le détail de tout qu'il fauit changer à la main, objet par objet. On n'est pas obligé de tout faire, mais au moins là où ça fait des superpositions indésirables, et suffisamment pour savoir distinguer correctement les formes et les placements relatifs des objets de tout type (y compris les plus petits, et notamment replacer correctement les points d'adresse du bon côté de la rue ou face au bon bâtiment de façon non ambiguë). Mais la précision du cadastre concernant les batiments n'est pas suffisante pour tout ce qu'on veut placer à côté. Le cadastre n'est pas une source fiable pour le bâti qui n'est qu'indicatif la plupart du temps et n'est fiable que pour le parcellaire, la voie publique, et les points de référence marqués de symboles spéciaux. Il est aussi peu fiable pour les cours d'eau, dont il n'indique que le parcellaire où il circule. L'import du cadastre c'était très bien il y a quelques années pour contruire rapidement le fond de carte sur lequel on a ensuite travaillé longuement un peu partout sur plein de détails. Maintenant cela ne suffit plus du tout avec tout ce qu'on a sur nos cartes. Même la toponymie et les noms/numéros de référence de rues/routes ne sont plus à jour depuis longtemps. Il n'est valable encore que dans les grandes métropoles ayant numérisé leur SIG depuis longtemps et corrigé et beaucoup travaillé depuis leurs anciennes planches. La preuve: les planches cadastrales entre communes ne sont même pas jointives, il n'y a toujours pas de conflation (on s'en souvient quand on a délimité les communes, le travail manuel de conflation a été important et estimatif) et les écarts sont plus importants que ce qu'on attend maintenant sur OSM (parfois plusieurs mètres d'écart, on est maintenant à une précision décimétrique pour plein d'objets, notamment et notamment en zone urbaine dense ou pour lever les ambiguïtés). Le cadastre en de nombreux endroit était basé sur une triangulation nettement moins précise qu'aujourd'hui, et il a été maintenu alors que depuis on a les relevés datellitaires puis maintenant aériens et des calages de position bien plus précis que ce qui a été bâti et conservé en l'état il y a des décennies. Il n'a pas été construit pour la signalisation routière, les accès, la sécurité, le mobilier urbain, les données d'environnement, etc. Il faut dire que les objectifs du cadastre (en France mais aussi ailleurs: question précision c'est bien pire en Espagne) n'ont jamais été de mettre dedans tout ce qu'on met maintenant dans OSM, alors qu'on ne s'intéresse pas du tout dans OSM au parcellaire (ultra-fragmenté qui ne correspond plus à grand chose d'aujourd'hui et contient plein de choses historiques qui n'ont plus lieu d'être). Le cadastre en France n'est toujours pas uniformisé et une grande partie du territoire n'a pas été revu depuis des décennies car les communes (et nombre des communautés de communes rurales) n'en ont pas les moyens. On verra dans quelques décennies si cela progresse mais c'est très lent, quand on sait qu'il y a encore plein de communes dont le cadastre n'a même pas été numérisé en l'état, donc pas retravaillé non plus pour corriger l'héritage passé. Il n'a pas été fait non plus pour être synchronisé avec les divers fournisseurs ou détenteurs de données cartographiques. Ca commence à se faire, mais encore lentement. L'open data commence à améliroer les choses mais c'est encore assez nouveau pour plein de communes d'avoir accès à toutes les données en même temps. Le travail de fourmis pour resynchoniser tout ça est justement ce qu'on fait dans OSM avec le travail de fusion et de comparaison des sources et plein d'observations dont les collectivités ne rêvaient même pas pouvoir réaliser elles-mêmes, surtout sur des éléments eux-mêmes évolutifs. Le ven. 27 déc. 2019 à 23:26, Eric SIBERT a écrit : > >> Je > >> voudrais ré-importer mais en conservant les tags des anciens bâtiments. > >> Une méthode facile proposée? > > > > https://cadastre.damsy.net te prémache un conflate dans josm qui te > > permet de conserver les id et les tags existant dans osm > > Commune de Lumbin (38). > > 1428 correspondances. 1300 conflits. Je ne sais que faire... > > (Il n'y a pas que le bâti qui aurait besoin d'un gros coup de chiffon > d'ailleurs). > > > > > Tu peux bien évidement aussi charger le tout "à la main" comme > > d'habitude > > En fait, j'ai fait du remplacement pur et simple sur certaines parties > de la commune au début de l'année. > > > la dernière solution si c'est juste un décalage est de sélectionner tout > > le batiment et de déplacer (à la souris) la sélection pour l'aligner par > > exemple sur l'imagerie. > > Non, ça ne marche jamais ;-). Le décalage est toujours variable à > l'échelle de la commune. > > Eric > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org >
Re: [OSM-talk-fr] Import bâti cadastre dans JOSM
Je voudrais ré-importer mais en conservant les tags des anciens bâtiments. Une méthode facile proposée? https://cadastre.damsy.net te prémache un conflate dans josm qui te permet de conserver les id et les tags existant dans osm Commune de Lumbin (38). 1428 correspondances. 1300 conflits. Je ne sais que faire... (Il n'y a pas que le bâti qui aurait besoin d'un gros coup de chiffon d'ailleurs). Tu peux bien évidement aussi charger le tout "à la main" comme d'habitude En fait, j'ai fait du remplacement pur et simple sur certaines parties de la commune au début de l'année. la dernière solution si c'est juste un décalage est de sélectionner tout le batiment et de déplacer (à la souris) la sélection pour l'aligner par exemple sur l'imagerie. Non, ça ne marche jamais ;-). Le décalage est toujours variable à l'échelle de la commune. Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti cadastre dans JOSM
Partout je constate que les polygones du cadastre sont fantaisistes, la question du calage de quelques pixels est mineure à côté: les formes proportions, tailles et orientations sont largement fausses un peu partout, et le découpage des bâtiments ne correspond à rien (avec des fusions mêmes de bâtiments pourtant bien séparés, avec même des chemins entre eux... Le cadastre n'est qu'un indicateur de la densité de l'habitat, mais certainement pas une référence, et il n'y a rien à jour (des retards de 10 ans ou plus) et l'imagerie est toujours plus récente presque partout hormi une poignée de bâtiments en zone urbaine dense où il y a pu y avoir quelques ajouts et restructurations suite à des réaménagements de ZAC par exemple et des études récentes. Ensuite le terrain s'endort pendant des décennies s'il ne s'agit pas de projets concertés (mais uniquement privés, propriété par propriété: là c'est du n'importe quoi...) Le cadastre n'est précis que pour le parcellaire (qui ne nous intéresse même pas) hormi dans les grandes métropoles ayant des GIS bien développés et avec les technologies les plus récentes et de nombreuses études de terrain par de nombreux acteurs obligés de se concerter et fournir des plans précis. Le ven. 27 déc. 2019 à 15:23, Eric SIBERT a écrit : > Heu... et sinon, j'ai un autre problème. J'arrive sur une zone. Je > constate que le bâti dans OSM est mal calé (par rapport au GPS, aux > orthophotos...). Je vois aussi que le cadastre actuel est mieux calé. Je > voudrais ré-importer mais en conservant les tags des anciens bâtiments. > Une méthode facile proposée? > > Eric > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti cadastre dans JOSM
Le 27.12.19 à 15:22, Eric SIBERT a écrit : > Heu... et sinon, j'ai un autre problème. J'arrive sur une zone. Je > constate que le bâti dans OSM est mal calé (par rapport au GPS, aux > orthophotos...). Je vois aussi que le cadastre actuel est mieux calé. Je > voudrais ré-importer mais en conservant les tags des anciens bâtiments. > Une méthode facile proposée? https://cadastre.damsy.net te prémache un conflate dans josm qui te permet de conserver les id et les tags existant dans osm Tu peux bien évidement aussi charger le tout "à la main" comme d'habitude et exécuter le script de config de https://cadastre.damsy.net tu peux aussi le faire "à la main", avec l'option "remplacer la géométrie" disponible dans le menu lorsque tu installes UtilsPlugin2 la dernière solution si c'est juste un décalage est de sélectionner tout le batiment et de déplacer (à la souris) la sélection pour l'aligner par exemple sur l'imagerie. dans tous les cas, on finit souvent par avoir à ajuster aussi les routes ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti cadastre dans JOSM
Heu... et sinon, j'ai un autre problème. J'arrive sur une zone. Je constate que le bâti dans OSM est mal calé (par rapport au GPS, aux orthophotos...). Je vois aussi que le cadastre actuel est mieux calé. Je voudrais ré-importer mais en conservant les tags des anciens bâtiments. Une méthode facile proposée? Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti cadastre dans JOSM
Bonjour, Le 27/12/2019 à 13:28, marc marc a écrit : Bonjour Vincent, ton email est parfaitement juste, sauf qu'il parle de la technique sous-jacente et pas une seconde de l'expérience utilisateur. Si si, je parle d'expérience plus intégrée et moins clickodrome notamment. alors oui, évidement qu'à terme, l'utilisation des pdf cessera. mais en attendant, au moins un des outils qui l'utilise est un des plus abouti. jeter cela en disant "yaka faire tout à la main avec le cadastre vectoriel parce que c'est plus moderne" n'est pas très plaisant comme réponse. surtout que Gautier a écrit les patchs pour corriger ce qui doit l'être. Je crois qu'on ne se comprends pas :/ Il est hors de question de jeter quelque travail que ce soit. Je répondais en gardant en tête la question initiale d'Eric, à savoir : "Comment j'importe un morceau de bâti du cadastre???" et en disant qu'à iso-fonctionalités, on avait maintenant un moyen plus direct d'importer un morceau de bâti du cadastre, sans passer par un site, un enregistrement de fichier, etc. Mais comme le fait remarquer Eric, c'est pas la panacée non plus vu qu'on récupère des feuilles entières de cadastre et non la stricte sélection qu'on souhaiterait. Le site de Gautier a une toute autre ambition que simplement récupérer un morceau de bâti, on est plus dans la même discussion. Ca n'empêche qu'il mériterait peut-être sur la même page de doc à faire, dont je parlais hier, un chapitre dédié, afin que quiconque s'intéresse aux manières de récupérer un bout de cadastre à jour sache que https://cadastre.damsy.net existe et répond au besoin, voire au-delà. La modernité n'a rien à voir avec mon point, qui est juste de faire qu'on s'adapte aux ressources qu'on sollicite, en essayant quand l'occasion se présente d'adapter nos pratiques. L'apparition du cadastre d'Etalab est typiquement une occasion de cet ordre. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti cadastre dans JOSM
Je ne me fierais pas à la géométrie indiqué par le cadastre, ça peut juste servir à la détection, mais dans ce cas juste se servir du signalement pour aller prendre une imagerie décente pour retracer correctement, donc non il n'y au besoin d'AUCUN import direct du cadastre, encore moins de fusion. C'est toujours mieux en reprenant et modifiant les données OSM avec l'imagerie comme support pour la géométrie. Le ven. 27 déc. 2019 à 14:32, marc marc a écrit : > Le 27.12.19 à 14:09, Philippe Verdy a écrit : > > réimporter le cadastre ? Pour quoi faire ? > > Pour ajouter dans osm les nouveau batiments et ceux ayant été fortement > modifié (hangar agricole devenu un immeuble de logement, annexe doublant > parfois la surface du bati) > l'outil en question permet de les détecter, à l'échelle d'une commune, > en un temps record, ce qui n'est pas du luxe à vérifier tout les 10 ans. > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti cadastre dans JOSM
Le 27.12.19 à 14:09, Philippe Verdy a écrit : > réimporter le cadastre ? Pour quoi faire ? Pour ajouter dans osm les nouveau batiments et ceux ayant été fortement modifié (hangar agricole devenu un immeuble de logement, annexe doublant parfois la surface du bati) l'outil en question permet de les détecter, à l'échelle d'une commune, en un temps record, ce qui n'est pas du luxe à vérifier tout les 10 ans. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti cadastre dans JOSM
Tout n'est pas à iomporter tel quel dans le cadastre. D'ailleurs il comprend de nombreuses approximations voire des erreurs manifeste de géométrien des polygones découpés un peu n'importe comment, des vieux batiments qui n'existent plus des tas qui manquent, des batiments fusionnés à tord (alors qu'ils sont physiquement séparés). Le cadastre donne juste une "idée" du terrain mais tout n'y est pas car c'est déclaratif et les tracés inclus dedans sont faits à-la-va-vite. Hormi le découpage parcellaire, tout ce qui est fait après la cession des propriétés est très approximatif et tout n'est pas soumis à déclaration obligatoire. Même si c'est déclaré, ce sont parfois des croquis ou des plans de chantier prévisionnels et rien n'est fait après la recette et la mise à jour peut ensuite prendre des décennies avant de voir que ce qui a été mis était très grossier voire carrément faux. Le cadastre n'est à peu près cohérent que pour les équipements publics. Le diable se cache dans les détails... Les imageries aériennes donnent de meilleures géométries et là on voit clareiemtn que nombre de bâtiments son déclarés bien plus petits qu'ils ne sont réellement. Bref je vois mal aller à réimporter le cadastre une seconde fois: cela a juste conduit à créer une ébauche qui souvent a été corrigée de façon disparâtre. Les orthohotos et les vues au sol de type Maillary (pour les accès et ce qui est visible depuis la voir publique) sont souvent bien meilleurs, à condition de pouvoir les dater (ce qui n'est pas toujours possible). Je pense que les services municipaux ne sont pas encore équipées pour recadrer les anciennes déclarations papier sur une imagerie aérienne récente et n'ont pas le temps de s'occuper de recadrer le reste. Elles ne le feront que dans le cas de nouveaux marchés où ce seront les architectes qui se chargeront de remettre le détail dans les zones présentées sur leurs plans, et qui devraient aussi alors fournir des fichiers métrés de façon plus exacte et s'appuyer sur des imageries récentes (à ces cabinets de payer les études de terrain et les faire valider). Mais c'est souvent fait pour des zones très limitées, personne ne veut en assurer le cout ni ne veut avoir à gérer les conflits de voisinage sur en modifiant ce qui n'est pas concerné dans le projet que chacun va gérer ensuite. Et nombre de résidents ne s'aperçoivent ni ni vont commenter les marchés publics et enquêtes pour signaler les corrections nécessaires. L'ortho-photographie pourtant permettrait de mettre tout le monde d'accord bien plus vite et relever les incohérences (et elles sont nombreuses) sur des bases objectives. Mais des tas de communes n'ont pas les moyens humains ni le temps d'utiliser les nouveaux outils, et transmettent des données très partielles ou approximatives, qui sont conservées en l'état tant que cela ne conduit pas à une affaire juridique. Et même si le conflit est régél, c'est ouvent de gré à gré, et les décisions judisiaires ou arrangements se font de façon privée mais très peu sur des bases géométriques exactes, surtout que cela e encore le temps de changer ou que les arrangements mettront du temps aussi pour aboutir à la solution finale. Ces détails n'intéressent le plus souvent pas non, plus le fisc car sous un seuil minimal rien ne change en terme de droits (et les communes aussi hésitent à modifier leur base fiscale. Les conseils municipaux ont surtout à s'occuper de tas de demandes et trouver des compromis difficiles, et en période préélectorale, tout est un peu paralysé. Tout le conde continue comme si ce qui était inscrit depuis des années doit persister et en fait bien peut de monde ne veut révéler des détails qui pourraient être dérangeants et joue à la limite de la légalité, sachant qu'en cas de problème (si c'est découvert) il y aura une négociation. Si une piscine est déclarée mais est mal orientée sur le cadastre ou sont tracé exact n'est pas celui-là, tout le monde "s'en fout". Si c'est sur le domaine privé, chacun garde jalousement la volonté de faire ce qu'il veut chez lui tant qu'aucun voisin direct n'est dérangé et ne s'en plaint. Alors réimporter le cadastre ? Pour quoi faire ? Une poignée de batiments ça et là, démolis et reconstruits un peu différemment, tant que les limites réglementaires ne sont pas dépassées, rien n'est mis à jour. Il faudrait des tas de "petites mains" pour faire ça, et l'administration n'en dispose pas. Les petites mains, c'est plutôt nous tous sur OSM. D'ailleurs d'autres adminsitrations ou acteurs privés sont ravis de voir qu'il y a plus de monde à s'en occuper, et pour tout ce qui n'est pas lié à une communication réglementaire et fondant un engagement contractuel, on leus voit volontier utiliser OSM comme carte de base car cela répond mieux aux attentes des clients ou usagers, et c'est surtout plus lisible et plus en accord avec la réalité du terrain. Le ven. 27 déc. 2019 à 13:29, marc marc a écrit : > Bonjour Vincent, > > ton email est parfaitement juste, sauf qu'il
Re: [OSM-talk-fr] Import bâti cadastre dans JOSM
Bonjour Vincent, ton email est parfaitement juste, sauf qu'il parle de la technique sous-jacente et pas une seconde de l'expérience utilisateur. je t'invite à tester https://cadastre.damsy.net pour par exemple mettre à jour une commune dont le cadastre date de 2008 et faire donc une maj des bâtiments nouveaux et modifié entre temps. Ensuite je t'invite à utiliser tous sauf ce site pour faire la même chose avec le cadastre vectoriel disponible via le plugin josm. l'expérience utilisateur est en défaveur des outils cadastre vectoriel. alors oui, évidement qu'à terme, l'utilisation des pdf cessera. mais en attendant, au moins un des outils qui l'utilise est un des plus abouti. jeter cela en disant "yaka faire tout à la main avec le cadastre vectoriel parce que c'est plus moderne" n'est pas très plaisant comme réponse. surtout que Gautier a écrit les patchs pour corriger ce qui doit l'être. Pour ma part, l'intégration du cadastre à la main, c'est sans moi. Je ne vois aucune raison valable de demander au contributeur de passer 2x fois plus de temps que nécessaire alors qu'il existe des outils qui utilisent mieux le cerveau humain et le temps si précieux qui l'accompagne. Et il reste aussi, à chaque fois que je met à jour une commune, tant de "import cadastre à la main" à retoucher niveau qualité. Cordialement, Marc Le 26.12.19 à 21:10, Vincent de Château-Thierry a écrit : > Bonjour, > > Le 26/12/2019 à 19:41, marc marc a écrit : >> la grande différence c'est l'expérience de l'utilisateur. > > Oui parlons-en de l'expérience utilisateur :) > > Le sujet ici c'est de savoir si on doit maintenir une page (l'actuelle > cadastre.openstreetmap.fr) qui s'appuie sur un processus d'accès au > Cadastre (le recours aux PDFs d'impression de cadastre.gouv.fr) qui > certes nous a sauvé la mise pendant des années, mais a avec le temps été > rendu plus gourmand en ressources et est devenu obsolète avec > l'apparition du cadastre redifusé par Etalab. > > Entre le moment (juin 2010 [1]) où on a eu accès à ces PDFs et > maintenant, un changement de configuration du site cadastre.gouv.fr à > réduit d'un facteur 100 la surface terrain imprimable en PDF. Donc on a > du augmenter d'un facteur 100 les appels aux serveurs du site pour > obtenir la même couverture terrain en PDF. Ca c'est pour les ressources. > > Pour l'obsolescence : les travaux côté Etalab sur la donnée cadastrale > permettent maintenant un accès vectoriel au cadastre grandement facilité > comme l'a rappelé Ades. C'est vrai pour les couches hors adresses ici : > https://cadastre.data.gouv.fr/ > et pour les adresses là : > https://adresse.data.gouv.fr/ > > Là dessus, le plugin Cadastre-fr a bénéficié d'une 2è vie (merci à > Vincent Privat :) ) pour intégrer l'accès à ces couches directement > depuis l'interface de chargement de JOSM. > > On a donc au final directement dans le contexte d'intégration un accès > aux données, sans passer par un site intermédiaire > (cadastre.openstreetmap.fr) et en s'alignant sur de meilleures pratiques > d'accès à la donnée, sans scraping. Je ne vois pas avec tout ça comment > l'expérience utilisateur, plus intégrée, moins clickodrome, s'en > trouverait altérée. De mon point de vue le "reste à faire" consisterait > surtout à remplacer le contenu de la page d'accueil de > cadastre.openstreetmap.fr par un lien vers le wiki expliquant la > nouvelle manière d'accéder dans JOSM aux mêmes données. > > vincent > > [1] : > https://lists.openstreetmap.org/pipermail/talk-fr/2010-June/022871.html > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti cadastre dans JOSM
Disons que quand je n'y arrive pas d'un côté, j'essaie de l'autre ;-). En l'absence de mode d'emploi, je n'avais pas trouvé la nouvelle méthode à utiliser dans JOSM. Par ailleurs, ce que je reproche à l'import direct dans JOSM, c'est de ramener tout le bâti des planches cadastrales concernées, pas uniquement la zone concernée. Il y aurait une élimination automatique de ce qu'on a pas demandé, que je ne serais pas contre. Après, remplacer cadastre.openstreetmap.fr par un mode d'emploi actuel, oui. De toute façon, cadastre.openstreetmap.fr est inutilisable actuellement. Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti cadastre dans JOSM
Bonjour, Le 26/12/2019 à 19:41, marc marc a écrit : la grande différence c'est l'expérience de l'utilisateur. Oui parlons-en de l'expérience utilisateur :) Le sujet ici c'est de savoir si on doit maintenir une page (l'actuelle cadastre.openstreetmap.fr) qui s'appuie sur un processus d'accès au Cadastre (le recours aux PDFs d'impression de cadastre.gouv.fr) qui certes nous a sauvé la mise pendant des années, mais a avec le temps été rendu plus gourmand en ressources et est devenu obsolète avec l'apparition du cadastre redifusé par Etalab. Entre le moment (juin 2010 [1]) où on a eu accès à ces PDFs et maintenant, un changement de configuration du site cadastre.gouv.fr à réduit d'un facteur 100 la surface terrain imprimable en PDF. Donc on a du augmenter d'un facteur 100 les appels aux serveurs du site pour obtenir la même couverture terrain en PDF. Ca c'est pour les ressources. Pour l'obsolescence : les travaux côté Etalab sur la donnée cadastrale permettent maintenant un accès vectoriel au cadastre grandement facilité comme l'a rappelé Ades. C'est vrai pour les couches hors adresses ici : https://cadastre.data.gouv.fr/ et pour les adresses là : https://adresse.data.gouv.fr/ Là dessus, le plugin Cadastre-fr a bénéficié d'une 2è vie (merci à Vincent Privat :) ) pour intégrer l'accès à ces couches directement depuis l'interface de chargement de JOSM. On a donc au final directement dans le contexte d'intégration un accès aux données, sans passer par un site intermédiaire (cadastre.openstreetmap.fr) et en s'alignant sur de meilleures pratiques d'accès à la donnée, sans scraping. Je ne vois pas avec tout ça comment l'expérience utilisateur, plus intégrée, moins clickodrome, s'en trouverait altérée. De mon point de vue le "reste à faire" consisterait surtout à remplacer le contenu de la page d'accueil de cadastre.openstreetmap.fr par un lien vers le wiki expliquant la nouvelle manière d'accéder dans JOSM aux mêmes données. vincent [1] : https://lists.openstreetmap.org/pipermail/talk-fr/2010-June/022871.html ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti cadastre dans JOSM
Le 26/12/2019 à 19:44, Eric SIBERT a écrit : Comment merge-t-on la sélection? Dans le menu Sélection ou Ctrl+Shift+M ;-) Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti cadastre dans JOSM
il ne faut pas merger tout le calque Oui, je nettoie le calque avant de merger. mais sélectionner les batiments manquant et merger la sélection Comment merge-t-on la sélection? Cordialement Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti cadastre dans JOSM
la grande différence c'est l'expérience de l'utilisateur. croire qu'un utilisateur de cadastre.openstreetmap.fr va aller sur un site gouv.fr pour trouver ce qu'il a besoin pour ensuite l'utiliser dans josm avec un plugin... c'est oublier que c'est pas le niveau de la majorité des contributeurs. à mon avis l'avenir c'est quelque chose genre https://cadastre.damsy.net branché sur le cadastre vectoriel et bano v2 et encore, il reste pas mal d'idée (genre avoir la conflation qui se fait sur le serveur, avoir une meilleur sélection de "ici il faut intervenir", avoir une info de "ici batiment manquant") et idéalement une intégration osmose (parce qu'il est plus pratique d'avoir un seul outil qui te connecte à tous les autres plutôt que d'avoir à parcourir une 10aine pour chaque catégorie) Le 26.12.19 à 19:05, ades a écrit : > Comprends pas trop ;-) > C’est quoi l’intérêt du cadastre en ligne (si j’ai à peu près compris) avec > JOSM quand on peut importer le cadastre (à jour tous les trimestres, en shp, > en edigeo ou geojsom -là je suis moins sur pour ce format) à partir d’etalab > ? Et l’importer sans pb, par couches (bati, hydro, parcelle etc. dans Josm) > Au moins on peut travailler calmement et en local ;-) (sans bouffer de la > bande passante et de l’énergie sur le net), on fait facilement une conflation > dans Josm, ou on peut aussi utiliser n’importe soft sig pour préparer les > données… > > >> Le 26 déc. 2019 à 18:00, marc marc a écrit : >> >> Bonjour, >> >> Le 26.12.19 à 15:52, Eric SIBERT a écrit : >>> https://lists.openstreetmap.org/pipermail/talk-fr/2019-July/093691.html >>> >>> En allant sur cadastre.openstreetmap.fr, en non sécurié, en sécurisé >>> simple, en sécurisé en cliquant sur le cadenas vert pour dire que ce >>> n'est pas grave si tout n'est pas sécurisé, la fenêtre pour sélectionner >>> la zone à exporter reste vide. >> >> avant il suffisait d'utiliser le site en http (parce qu'en https il y a >> un mixed content) >> mais il semble qu'un autre soucis existe : cadastre.gouv.fr ne fournit >> plus de donnée en http >> les 2 ensemble font que c'est devenu inutilisable >> j'ai lancé un appel à maintenance sur ce dépot car je n'ai pas accés >> pour merger. >> si cela ne réagit pas, je ferrai les modifs à la main sur le serveur. >> >> >>> Directement dans JOSM, je vais dans Télécharger puis l'onglet >>> "Téléchargement depuis le Cadastre". Je sélectionne la zone et ça >>> télécharge. Je me retrouve avec des couches edigo-xxx.tar.bz2 avec deux >>> petits triangles oranges d'avertissement. Quand je fusionne avec le >>> calque principal, les triangles sont transmis au calque principal. Je ne >>> peux alors pas renvoyer les données vers OSM. >>> >>> Comment j'importe un morceau de bâti du cadastre??? >> >> il ne faut pas merger tout le calque mais sélectionner les batiments >> manquant et merger la sélection >> >> cordialement, >> Marc >> ___ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr > > > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti cadastre dans JOSM
Comprends pas trop ;-) C’est quoi l’intérêt du cadastre en ligne (si j’ai à peu près compris) avec JOSM quand on peut importer le cadastre (à jour tous les trimestres, en shp, en edigeo ou geojsom -là je suis moins sur pour ce format) à partir d’etalab ? Et l’importer sans pb, par couches (bati, hydro, parcelle etc. dans Josm) Au moins on peut travailler calmement et en local ;-) (sans bouffer de la bande passante et de l’énergie sur le net), on fait facilement une conflation dans Josm, ou on peut aussi utiliser n’importe soft sig pour préparer les données… > Le 26 déc. 2019 à 18:00, marc marc a écrit : > > Bonjour, > > Le 26.12.19 à 15:52, Eric SIBERT a écrit : >> https://lists.openstreetmap.org/pipermail/talk-fr/2019-July/093691.html >> >> En allant sur cadastre.openstreetmap.fr, en non sécurié, en sécurisé >> simple, en sécurisé en cliquant sur le cadenas vert pour dire que ce >> n'est pas grave si tout n'est pas sécurisé, la fenêtre pour sélectionner >> la zone à exporter reste vide. > > avant il suffisait d'utiliser le site en http (parce qu'en https il y a > un mixed content) > mais il semble qu'un autre soucis existe : cadastre.gouv.fr ne fournit > plus de donnée en http > les 2 ensemble font que c'est devenu inutilisable > j'ai lancé un appel à maintenance sur ce dépot car je n'ai pas accés > pour merger. > si cela ne réagit pas, je ferrai les modifs à la main sur le serveur. > > >> Directement dans JOSM, je vais dans Télécharger puis l'onglet >> "Téléchargement depuis le Cadastre". Je sélectionne la zone et ça >> télécharge. Je me retrouve avec des couches edigo-xxx.tar.bz2 avec deux >> petits triangles oranges d'avertissement. Quand je fusionne avec le >> calque principal, les triangles sont transmis au calque principal. Je ne >> peux alors pas renvoyer les données vers OSM. >> >> Comment j'importe un morceau de bâti du cadastre??? > > il ne faut pas merger tout le calque mais sélectionner les batiments > manquant et merger la sélection > > cordialement, > Marc > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti cadastre dans JOSM
Bonjour, Le 26.12.19 à 15:52, Eric SIBERT a écrit : > https://lists.openstreetmap.org/pipermail/talk-fr/2019-July/093691.html > > En allant sur cadastre.openstreetmap.fr, en non sécurié, en sécurisé > simple, en sécurisé en cliquant sur le cadenas vert pour dire que ce > n'est pas grave si tout n'est pas sécurisé, la fenêtre pour sélectionner > la zone à exporter reste vide. avant il suffisait d'utiliser le site en http (parce qu'en https il y a un mixed content) mais il semble qu'un autre soucis existe : cadastre.gouv.fr ne fournit plus de donnée en http les 2 ensemble font que c'est devenu inutilisable j'ai lancé un appel à maintenance sur ce dépot car je n'ai pas accés pour merger. si cela ne réagit pas, je ferrai les modifs à la main sur le serveur. > Directement dans JOSM, je vais dans Télécharger puis l'onglet > "Téléchargement depuis le Cadastre". Je sélectionne la zone et ça > télécharge. Je me retrouve avec des couches edigo-xxx.tar.bz2 avec deux > petits triangles oranges d'avertissement. Quand je fusionne avec le > calque principal, les triangles sont transmis au calque principal. Je ne > peux alors pas renvoyer les données vers OSM. > > Comment j'importe un morceau de bâti du cadastre??? il ne faut pas merger tout le calque mais sélectionner les batiments manquant et merger la sélection cordialement, Marc ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti cadastral, encore du travail à faire
Le 15 janv. 2013 01:01, Sébastien Dinot sebastien.di...@free.fr a écrit : Bonjour, Lorsque j'importe le bâti d'une commune, je passe beaucoup de temps à nettoyer préalablement le bâti. Outre le découpage des bâtiments au gré des parcelles, les autres problèmes que je rencontre en abondance sont : - Une surdéfinition et, souvent un crénelage chaotique, des murs incurvés. Il y a quelques temps, j'ai ainsi réduit la description d'une série silos d'à peine trois mètres de diamètre de 360 ~ 390 sommets à 16 sommets. En simplifiant cinq silos, j'ai donc supprimé environ 1800 points ! En la matière, l'outil de simplification de chemin de JOSM avec un paramètre simplify-way.max-error judicieusement réglé est de la plus grande aide. - Le chevauchement de bâtiments ou de parties de bâtiments. - L'absence d'intersection entre des portions de bâtiment forcément jointives (rares sont les balcons doués de la faculté de lévitation). Je n'ai jamais calculé quel pourcentage de points je supprimais mais ce dégraissage m'a à plusieurs reprises permis d'alléger le bâti de plusieurs milliers de points. Mais on n'atteindra jamais sur le bâti l'allègement que l'on obtient en supprimant les riverbank farfelus et surdéfinis du cadastre. :) Tout ça fait un bon cahier des charge pour l'amélioreration du script de transcription. ;-) Sébastien -- Sébastien Dinot, sebastien.di...@free.fr http://sebastien.dinot.free.fr/ Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer ! ___ 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] Import bâti cadastral, encore du travail à faire
Le 14 janvier 2013 13:03, Pieren pier...@gmail.com a écrit : Bonjour, Je voudrais faire part ici d'un retour d'expérience sur le bâti cadastral de deux villages de taille moyenne (1500.. 2000 habitants) que j'ai eu l'occasion d'examiner en détail ce week-end. Dans le premier, j'ai immédiatement constaté le nombre ahurissant de polygones building=yes qui se découpaient suivant le parcellaire, très fragmenté dans cette commune rurale. En ne conservant que les contours extérieurs (définition du tag building=yes), j'ai pu supprimer approximativement 70% des polygones. Dans le deuxième cas, l'urbanisation était plus récente mais il y avait encore env. 30% de buildings en trop. Le découpage des bâtiments par le cadastre semble donc très, très variable d'une commune à l'autre, mais aussi à l'intérieur d'une même commune (et ne semble pas dépendre de pratiques spécifiques à un CDIF). C'est aussi mon impression. Dans ma ville c'est plutôt l'inverse... un immeuble de plusieurs étages et des garages qui n'ont qu'un polygone, et dans ce cas, je recoupe. -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquesthttp://openstreetmap.fr/u/christian-quest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti cadastral, encore du travail à faire
Meme impression aussi. Je ne conserve les separations que lorsqu'elles sont dues a un passage entre bati lourd et bati leger ou si l imagerie aerienne montre un changement de niveau ou de batiment. Julien De : Christian Quest cqu...@openstreetmap.fr À : Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé le : Lundi 14 janvier 2013 13h28 Objet : Re: [OSM-talk-fr] Import bâti cadastral, encore du travail à faire Le 14 janvier 2013 13:03, Pieren pier...@gmail.com a écrit : Bonjour, Je voudrais faire part ici d'un retour d'expérience sur le bâti cadastral de deux villages de taille moyenne (1500.. 2000 habitants) que j'ai eu l'occasion d'examiner en détail ce week-end. Dans le premier, j'ai immédiatement constaté le nombre ahurissant de polygones building=yes qui se découpaient suivant le parcellaire, très fragmenté dans cette commune rurale. En ne conservant que les contours extérieurs (définition du tag building=yes), j'ai pu supprimer approximativement 70% des polygones. Dans le deuxième cas, l'urbanisation était plus récente mais il y avait encore env. 30% de buildings en trop. Le découpage des bâtiments par le cadastre semble donc très, très variable d'une commune à l'autre, mais aussi à l'intérieur d'une même commune (et ne semble pas dépendre de pratiques spécifiques à un CDIF). C'est aussi mon impression. Dans ma ville c'est plutôt l'inverse... un immeuble de plusieurs étages et des garages qui n'ont qu'un polygone, et dans ce cas, je recoupe. -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ 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] Import bâti cadastral, encore du travail à faire
bonjour, et meilleurs vux OSM et ses fourmis Je me suis pos aussi cette question ds mon premier import du cadastre. J'ai cherch regrouper. (pas fait beaucoup, et puis la nouvelle demande de double compte me refroidi ) - en ville (village) On les repre facilement grce aux diffrences entre les toitures, le sens des faitage, l'ombrage. J'avais donc conclu que 2 btis clairement construits diffremment au vu des toitures devaient mener 2 building=yes. Presque pas de fusion. J'ai mme arrt de fusionn - en tissu diffus distendus l c'est plus dur, j'ai vu beaucoup de garages rajouts aux btisses qui en cadastre avait une limite sparative mais qui dans les faits rclamaient une fusion avec le plus gros bti. Pas beaucoup de fusion. J'ai arrte aussi plus par doute - en tissu de campagne, c'est encore plus compliqu car plus d'adresse cadastrale pour vrifier. Dans les hameaux anciens ou bti de corps de ferme assembl il n'y a pas trop moyen de passer devant pour regarder, les toitures sont clairement diffrentes et traduisent des poques diffrentes mais on sait aussi qu'historiquement il s'agissait des mme familles. fusion si les btis sont assimilables aux mme poques et sur une mme parcelle (il faut vrifier sur le serveur) pas fusion si beaucoup de parcelles correspondent des btis diffrents. au final j'en ai fait trs peu des fusions. et puis finalement j'aime bien les limites sparatives entre bti a me donne une information sur la logique d'usage du sol, ce que ne donne pas la carte TOP25 par exemple 70% me parait norme au vu de ce que j'ai dans mon coin, mme 30%... djo_man Le 14/01/2013 13:28, Christian Quest a crit: Le 14 janvier 2013 13:03, Pieren pier...@gmail.com a crit : Bonjour, Je voudrais faire part ici d'un retour d'exprience sur le bti cadastral de deux villages de taille moyenne (1500.. 2000 habitants) que j'ai eu l'occasion d'examiner en dtail ce week-end. Dans le premier, j'ai immdiatement constat le nombre ahurissant de polygones "building=yes" qui se dcoupaient suivant le parcellaire, trs fragment dans cette commune rurale. En ne conservant que les contours extrieurs (dfinition du tag "building=yes"), j'ai pu supprimer approximativement 70% des polygones. Dans le deuxime cas, l'urbanisation tait plus rcente mais il y avait encore env. 30% de "buildings" en trop. Le dcoupage des btiments par le cadastre semble donc trs, trs variable d'une commune l'autre, mais aussi l'intrieur d'une mme commune (et ne semble pas dpendre de pratiques spcifiques un CDIF). C'est aussi mon impression. Dans ma ville c'est plutt l'inverse... un immeuble de plusieurs tages et des garages qui n'ont qu'un polygone, et dans ce cas, je recoupe. -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ 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] Import bâti cadastral, encore du travail à faire
Je suis d'accord aussi: quand on charge le cadastre avec josm, les surfaces oranges sont moins découpées qu'avec Qadastre ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti cadastral, encore du travail à faire
Ça ferait un bon thème pour un Maproulette à la française, à condition de pouvoir identifier les bons candidats En particulier s'il permettait d'alterner facilement entre fond Bing et cadastre pour bien juger de la nécessité ou pas de la césure. Et pourquoi pas permettre d'affiner rapidement la nature du bâtiment (house, garage ...), quand celle-ci n'est pas ambiguë. Car c'est un autre aspect qui singularise la France du reste du monde : on indique qu'il y a un bâtiment, mais on ne prend pas la peine de dire de quel type [1]. J'ai lu et je comprends les arguments de Djo_man, mais dans pas mal de cas [2], l'arbitrage est relativement simple, au moins par un oeil humain. Le reste est surtout une contrainte de temps humain disponible [1] France : http://taginfo.openstreetmap.fr/keys/building#values Monde : http://taginfo.openstreetmap.org/keys/building#values [2] http://osmose.openstreetmap.fr/map/?zoom=18lat=47.15634lon=-1.39291layers=BFFT Le 14 janvier 2013 13:03, Pieren pier...@gmail.com a écrit : Bonjour, Je voudrais faire part ici d'un retour d'expérience sur le bâti cadastral de deux villages de taille moyenne (1500.. 2000 habitants) que j'ai eu l'occasion d'examiner en détail ce week-end. Dans le premier, j'ai immédiatement constaté le nombre ahurissant de polygones building=yes qui se découpaient suivant le parcellaire, très fragmenté dans cette commune rurale. En ne conservant que les contours extérieurs (définition du tag building=yes), j'ai pu supprimer approximativement 70% des polygones. Dans le deuxième cas, l'urbanisation était plus récente mais il y avait encore env. 30% de buildings en trop. Le découpage des bâtiments par le cadastre semble donc très, très variable d'une commune à l'autre, mais aussi à l'intérieur d'une même commune (et ne semble pas dépendre de pratiques spécifiques à un CDIF). L'import du bâti cadastral français dans OSM souffre d'une lacune grave. La modélisation du bâti n'est pas respecté. Seul le contour extérieur des bâtiments doit porter le tag building=*. Tout le reste devrait passer dans d'autres tags comme room=* ([1]) ou building:part ([2]) si on connait la configuration des lieux, ce qui est rarement le cas. Lorsque des maisons sont adossées, la séparation en polygones distincts ne se justifie que si les bâtiments forment des corps distincts. Comme c'est difficilement vérifiable de l'extérieur, la prudence devrait être de mise et donc opter pour la séparation que lorsque d'autres indicateurs comme les adresses distinctes sont présents (les différences architecturales ou d'âge des constructions peuvent aussi aider). La conséquence de cette mauvaise modélisation est que le nombre de bâtiments dans OSM est totalement fantaisiste et ne peut servir à aucune étude statistique ou analyse sérieuse. On trouve trop de petits balcons, terrasses, pérons, petits mobiliers (armoires techniques, statues), découpages sur lignes parcellaires ou par étages, ou de curieux triangles en coins taggués improprement en building=yes. A aucun moment, le guide d'import semi-automatique ([3]) ne mentionne la nécessité de simplifier les polygones du bâti en les fusionnant lorsque le découpage ne correspond pas aux contours extérieurs. Ou alors, suis-je le seul à penser que c'est un problème ? Pieren [1] http://wiki.openstreetmap.org/wiki/Key:room [2] http://wiki.openstreetmap.org/wiki/Simple_3D_Buildings [3] http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_b%C3%A2timents ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus, Nadja ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti cadastral, encore du travail à faire
2013/1/14 Ab_fab gamma@gmail.com: Ça ferait un bon thème pour un Maproulette à la française, à condition de pouvoir identifier les bons candidats Peut-être qu'un premier calcul de ratio, genre nombre de polygones building divisé par le nombre d'habitants, par commune serait une première piste. Pieren PS: à noter que le 70% est effectivement excessif. Il ne concerne que le ratio de réduction sur les bâtiments vraiment modifiés (qui était de 80% en fait). Pour les 30% de l'autre commune, par contre, c'est bien rapporté au total des buildings (et ~10% pour les wall=no). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti cadastral, encore du travail à faire
Dans l'outil adresses sur le site web, j'indique un ratio polygones de bâti / adresses. Bien sûr il n'est intéressant que si on a saisit toutes les adresses ;) Je vais rajouter le ratio bâti / habitants et adresses / habitants... Le 14 janvier 2013 15:13, Pieren pier...@gmail.com a écrit : 2013/1/14 Ab_fab gamma@gmail.com: Ça ferait un bon thème pour un Maproulette à la française, à condition de pouvoir identifier les bons candidats Peut-être qu'un premier calcul de ratio, genre nombre de polygones building divisé par le nombre d'habitants, par commune serait une première piste. Pieren PS: à noter que le 70% est effectivement excessif. Il ne concerne que le ratio de réduction sur les bâtiments vraiment modifiés (qui était de 80% en fait). Pour les 30% de l'autre commune, par contre, c'est bien rapporté au total des buildings (et ~10% pour les wall=no). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquesthttp://openstreetmap.fr/u/christian-quest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti cadastral, encore du travail à faire
Je pensais pour ma part à des critères géométriques sur des bâtiments contigus (valeurs des angles, surfaces respectives, nombre de segments contigus avec d'autres bâtiments ...) Sans parler des tests qui pourraient être faits avec un extrait du parcellaire du cadastre (utilisé juste pour cette fin) (cibler en priorité les segments contigus de bâti prolongés dans le cadastre par une limite de parcelle) Pas simple ... Le 14 janvier 2013 15:13, Pieren pier...@gmail.com a écrit : 2013/1/14 Ab_fab gamma@gmail.com: Ça ferait un bon thème pour un Maproulette à la française, à condition de pouvoir identifier les bons candidats Peut-être qu'un premier calcul de ratio, genre nombre de polygones building divisé par le nombre d'habitants, par commune serait une première piste. Pieren PS: à noter que le 70% est effectivement excessif. Il ne concerne que le ratio de réduction sur les bâtiments vraiment modifiés (qui était de 80% en fait). Pour les 30% de l'autre commune, par contre, c'est bien rapporté au total des buildings (et ~10% pour les wall=no). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus, Nadja ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti cadastral, encore du travail à faire
Pourquoi on ne considérerait pas que building = yes est une erreur à corriger, au même titre que highway = road ? De plus, il me semble que le tag wall = no pourrait facilement être remplacé par une qualification du building : roof, hangar, shed, greenhouse... Bon, maintenant ça fait un paquet d'erreurs a corriger ! mais pour des fourmis laborieuses, tout est possible ;-) Mika Le lundi 14 janvier 2013 à 14:57 +0100, Ab_fab a écrit : Ça ferait un bon thème pour un Maproulette à la française, à condition de pouvoir identifier les bons candidats En particulier s'il permettait d'alterner facilement entre fond Bing et cadastre pour bien juger de la nécessité ou pas de la césure. Et pourquoi pas permettre d'affiner rapidement la nature du bâtiment (house, garage ...), quand celle-ci n'est pas ambiguë. Car c'est un autre aspect qui singularise la France du reste du monde : on indique qu'il y a un bâtiment, mais on ne prend pas la peine de dire de quel type [1]. J'ai lu et je comprends les arguments de Djo_man, mais dans pas mal de cas [2], l'arbitrage est relativement simple, au moins par un oeil humain. Le reste est surtout une contrainte de temps humain disponible [1] France : http://taginfo.openstreetmap.fr/keys/building#values Monde : http://taginfo.openstreetmap.org/keys/building#values [2] http://osmose.openstreetmap.fr/map/?zoom=18lat=47.15634lon=-1.39291layers=BFFT Le 14 janvier 2013 13:03, Pieren pier...@gmail.com a écrit : Bonjour, Je voudrais faire part ici d'un retour d'expérience sur le bâti cadastral de deux villages de taille moyenne (1500.. 2000 habitants) que j'ai eu l'occasion d'examiner en détail ce week-end. Dans le premier, j'ai immédiatement constaté le nombre ahurissant de polygones building=yes qui se découpaient suivant le parcellaire, très fragmenté dans cette commune rurale. En ne conservant que les contours extérieurs (définition du tag building=yes), j'ai pu supprimer approximativement 70% des polygones. Dans le deuxième cas, l'urbanisation était plus récente mais il y avait encore env. 30% de buildings en trop. Le découpage des bâtiments par le cadastre semble donc très, très variable d'une commune à l'autre, mais aussi à l'intérieur d'une même commune (et ne semble pas dépendre de pratiques spécifiques à un CDIF). L'import du bâti cadastral français dans OSM souffre d'une lacune grave. La modélisation du bâti n'est pas respecté. Seul le contour extérieur des bâtiments doit porter le tag building=*. Tout le reste devrait passer dans d'autres tags comme room=* ([1]) ou building:part ([2]) si on connait la configuration des lieux, ce qui est rarement le cas. Lorsque des maisons sont adossées, la séparation en polygones distincts ne se justifie que si les bâtiments forment des corps distincts. Comme c'est difficilement vérifiable de l'extérieur, la prudence devrait être de mise et donc opter pour la séparation que lorsque d'autres indicateurs comme les adresses distinctes sont présents (les différences architecturales ou d'âge des constructions peuvent aussi aider). La conséquence de cette mauvaise modélisation est que le nombre de bâtiments dans OSM est totalement fantaisiste et ne peut servir à aucune étude statistique ou analyse sérieuse. On trouve trop de petits balcons, terrasses, pérons, petits mobiliers (armoires techniques, statues), découpages sur lignes parcellaires ou par étages, ou de curieux triangles en coins taggués improprement en building=yes. A aucun moment, le guide d'import semi-automatique ([3]) ne mentionne la nécessité de simplifier les polygones du bâti en les fusionnant lorsque le découpage ne correspond pas aux contours extérieurs. Ou alors, suis-je le seul à penser que c'est un problème ? Pieren [1] http://wiki.openstreetmap.org/wiki/Key:room [2] http://wiki.openstreetmap.org/wiki/Simple_3D_Buildings [3] http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_b%C3%A2timents ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab Il n'y a pas de pas perdus, Nadja ___ Talk-fr mailing list
Re: [OSM-talk-fr] Import bâti cadastral, encore du travail à faire
2013/1/14 Mickaël Guéret m.gue...@free.fr: Pourquoi on ne considérerait pas que building = yes est une erreur à corriger, au même titre que highway = road ? Vu la quantité et la nécessité de vérifier de visu, c'est des erreurs qui risqueraient de persister longtemps ;-) De plus, il n'y a pas de consensus clair pour les bâtiments à usages multiples. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti cadastral, encore du travail à faire
Bonjour, De : Ab_fab Je pensais pour ma part à des critères géométriques sur des bâtiments contigus (valeurs des angles, surfaces respectives, nombre de segments contigus avec d'autres bâtiments ...) Sans parler des tests qui pourraient être faits avec un extrait du parcellaire du cadastre (utilisé juste pour cette fin) (cibler en priorité les segments contigus de bâti prolongés dans le cadastre par une limite de parcelle) Pas simple ... Je viens de faire un test sur un extrait de base Auvergne, en sélectionnant les polygones issus d'osm2pgsql sur 2 critères combinés : - building = yes - le polygone a 3 sommets distincts Je récupère donc des triangles, qu'on peut ranger en 2 catégories : - ceux taggués wall=no, souvent en pignon de bâtiment, et contigus à un polygone sans wall=no - des portions de bâtiment, sans wall=no sur le triangle ni sur le reste du bâtiment, et pour lesquels l'existence du triangle correspond à un passage de limite de parcelle dans le bâtiment (donc fusionnable, en théorie). Quelques objets de mon jeu-test (à regarder avec JOSM ouvert) : http://localhost:8111/load_object?objects=w62941737 http://localhost:8111/load_object?objects=w62944316 http://localhost:8111/load_object?objects=w62942253 http://localhost:8111/load_object?objects=w62943363 http://localhost:8111/load_object?objects=w62942984 http://localhost:8111/load_object?objects=w62943980 http://localhost:8111/load_object?objects=w62942830 http://localhost:8111/load_object?objects=w62944580 http://localhost:8111/load_object?objects=w62944340 http://localhost:8111/load_object?objects=w62943836 http://localhost:8111/load_object?objects=w62943675 http://localhost:8111/load_object?objects=w62941778 http://localhost:8111/load_object?objects=w62941929 http://localhost:8111/load_object?objects=w62943758 http://localhost:8111/load_object?objects=w62943155 Ça n'est qu'un aspect du problème soulevé par Pieren, mais qu'on pourrait prendre comme l'indicateur d'un style de cadastre. Peut-être (mais à affiner) la matière d'un test Osmose pour indiquer, au delà du simple polygone, une commune sujette à morcellement ? vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti cadastral, encore du travail à faire
Le lundi 14 janvier 2013 à 16:08 +0100, Ab_fab a écrit : Je pensais pour ma part à des critères géométriques sur des bâtiments contigus (valeurs des angles, surfaces respectives, nombre de segments contigus avec d'autres bâtiments ...) Sans parler des tests qui pourraient être faits avec un extrait du parcellaire du cadastre (utilisé juste pour cette fin) (cibler en priorité les segments contigus de bâti prolongés dans le cadastre par une limite de parcelle) Pas simple ... déjà par la taille et la forme, les très petits bâtiments triangulaires sont sans doute des erreurs. Je serais doué je coderais l'analyse osmose qui va bien... Mika ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti cadastral, encore du travail à faire
2013/1/14 Mickaël Guéret m.gue...@free.fr: les très petits bâtiments triangulaires sont sans doute des erreurs. Je comprends que ces triangles soient plus faciles à détecter. Mais d'après ce que j'ai vu, ils ne représentent qu'une partie infime du problème. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti cadastral, encore du travail à faire
Le lundi 14 janvier 2013 à 16:19 +0100, Pieren a écrit : Vu la quantité et la nécessité de vérifier de visu, c'est des erreurs qui risqueraient de persister longtemps ;-) De plus, il n'y a pas de consensus clair pour les bâtiments à usages multiples. Pieren Sur le wiki [1], la description du bâtiment mélange l'usage qui en est fait et la forme du bâtiment. Mais si j'ai bien compris, les discussions semblent mettre en avant la typologie du bâtiment sur son usage ? Ex : un hangar dans une cours de ferme, c'est building = hangar plutôt que farm_auxiliary. En attendant un consensus clair, dans certaines zones (résidentielles récentes par exemple) c'est très facile de requalifier les bâtiments importés du cadastre : par exemple ici : http://www.openstreetmap.org/?lat=46.953713lon=-0.388319zoom=18layers=M Mika [1] : http://wiki.openstreetmap.org/wiki/Talk:Key:building ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti cadastral, encore du travail à faire
J'ai pas tout regardé, mais les 4 premiers devraient être corrigés, c'est à dire fusionnés avec le bâtiment adjacent. ça me semble une bonne base pour détecter des erreurs d'import du bâtis (dans ce cas, on ne peut vraiment pas parler d'intégration du bâtis...) On pourrait aussi regarder les bâtiments qui font moins de 1 m de large (ou même 50 cm...) non ? ça doit être assez rare en vrai... ;-) Mika Le lundi 14 janvier 2013 à 16:44 +0100, Vincent de Chateau-Thierry a Je viens de faire un test sur un extrait de base Auvergne, en sélectionnant les polygones issus d'osm2pgsql sur 2 critères combinés : - building = yes - le polygone a 3 sommets distincts Je récupère donc des triangles, qu'on peut ranger en 2 catégories : - ceux taggués wall=no, souvent en pignon de bâtiment, et contigus à un polygone sans wall=no - des portions de bâtiment, sans wall=no sur le triangle ni sur le reste du bâtiment, et pour lesquels l'existence du triangle correspond à un passage de limite de parcelle dans le bâtiment (donc fusionnable, en théorie). Quelques objets de mon jeu-test (à regarder avec JOSM ouvert) : http://localhost:8111/load_object?objects=w62941737 http://localhost:8111/load_object?objects=w62944316 http://localhost:8111/load_object?objects=w62942253 http://localhost:8111/load_object?objects=w62943363 http://localhost:8111/load_object?objects=w62942984 http://localhost:8111/load_object?objects=w62943980 http://localhost:8111/load_object?objects=w62942830 http://localhost:8111/load_object?objects=w62944580 http://localhost:8111/load_object?objects=w62944340 http://localhost:8111/load_object?objects=w62943836 http://localhost:8111/load_object?objects=w62943675 http://localhost:8111/load_object?objects=w62941778 http://localhost:8111/load_object?objects=w62941929 http://localhost:8111/load_object?objects=w62943758 http://localhost:8111/load_object?objects=w62943155 Ça n'est qu'un aspect du problème soulevé par Pieren, mais qu'on pourrait prendre comme l'indicateur d'un style de cadastre. Peut-être (mais à affiner) la matière d'un test Osmose pour indiquer, au delà du simple polygone, une commune sujette à morcellement ? vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti cadastral, encore du travail à faire
Salut, bonne idée le building:part=, ça permet aussi de rajouter des infos pour le rendu 3d, mais ça ne résout pas vraiment le problème du nombre de polygones building, étant donné qu'il faut quand même un polygone englobant + le polygone building:part ... en tout cas c'est clair que si on passe les building=yes en erreur osmose, on aura plus que ça sur la carte :D (je plaide coupable d'un nombre certain de non rectification de ces données ...) mais c'est sur qu'un maproulette sur les polygones de type building avec des caractéristiques spéciales par exemple superficie 300m2, proximité d'un poi de bâtiment public (comme pour les écoles), ... ça pourrait permettre de qualifier assez rapidement des bâtiments non résidentiels ! Sylvain Le 14 janvier 2013 16:19, Pieren pier...@gmail.com a écrit : 2013/1/14 Mickaël Guéret m.gue...@free.fr: Pourquoi on ne considérerait pas que building = yes est une erreur à corriger, au même titre que highway = road ? Vu la quantité et la nécessité de vérifier de visu, c'est des erreurs qui risqueraient de persister longtemps ;-) De plus, il n'y a pas de consensus clair pour les bâtiments à usages multiples. Pieren ___ 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] Import bâti cadastral, encore du travail à faire
Le 14 janvier 2013 16:19, Pieren pier...@gmail.com a écrit : 2013/1/14 Mickaël Guéret m.gue...@free.fr: Pourquoi on ne considérerait pas que building = yes est une erreur à corriger, au même titre que highway = road ? Vu la quantité et la nécessité de vérifier de visu, c'est des erreurs qui risqueraient de persister longtemps ;-) De plus, il n'y a pas de consensus clair pour les bâtiments à usages multiples. Remarque d'autant plus pertinente que les valeurs données à building=* ne sont (pour l'essentiel) PAS basées sur la topologie ou la structure des batiments mais sur leur USAGE (résidentiel, commercial, service...) Si vous regardez la page wiki au sujet du Tag:building, il n'y a meˆme encore aucun réel consensus sur les valeurs à donner dans de nombreux cas car l'usage varie énormément et souvent n'est pas unique, même pour une même adresse (rue/numéro et même numéro d'appartement ou étage, on des usages multiples candidats pour un même lieu). La questio nse pose donc de la séparation déjà de la structure topologique et des usages, mais building=* semble condamné à rester au niveau des usages (mais ne comprend pourtant pas tout, par exemple on doit exclure les tombes, les chateaux, les remparts, les monuments historiques... alors même qu'ils peuvent avoir aussi un usage rentrant dans une des catégories de building=* ! J'ai cherché récemment le cas d'un ancien fortin militaire sur une île, qui est conservé au patrimoine, mais n'a plus l'usage militaire, mais n'est pas non plus un musée ni un service, mais se visite pourtant et a un intérêt touristique : quelle catégorie mettre à ce building ? Aucune ne convient et il reste alors seulement building=yes, et pourtant on devrait aussi mettre historic=castle et castle_type=defensive et aussi un tag pour indiquer tourism quelque part. Et aucun validateur de données n'accepte cette combinaison qu'il considère comme ambigue ou de styles différents dans JOSM, ou bien building dans un building alors qu'il n'y a qu'un seul polygone sans aucune intersection ! Bref on est dans le flou total au sujet des valeurs de building=*. Et finalement building=yes qui convient à tout le monde n'est pas si stupide que ça. On ne trouvera pas de solution avec un seul tag ou une seule valeur donnée à building=* (pas de point-virgule ?) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti cadastral, encore du travail à faire
Bonjour, Lorsque j'importe le bâti d'une commune, je passe beaucoup de temps à nettoyer préalablement le bâti. Outre le découpage des bâtiments au gré des parcelles, les autres problèmes que je rencontre en abondance sont : - Une surdéfinition et, souvent un crénelage chaotique, des murs incurvés. Il y a quelques temps, j'ai ainsi réduit la description d'une série silos d'à peine trois mètres de diamètre de 360 ~ 390 sommets à 16 sommets. En simplifiant cinq silos, j'ai donc supprimé environ 1800 points ! En la matière, l'outil de simplification de chemin de JOSM avec un paramètre simplify-way.max-error judicieusement réglé est de la plus grande aide. - Le chevauchement de bâtiments ou de parties de bâtiments. - L'absence d'intersection entre des portions de bâtiment forcément jointives (rares sont les balcons doués de la faculté de lévitation). Je n'ai jamais calculé quel pourcentage de points je supprimais mais ce dégraissage m'a à plusieurs reprises permis d'alléger le bâti de plusieurs milliers de points. Mais on n'atteindra jamais sur le bâti l'allègement que l'on obtient en supprimant les riverbank farfelus et surdéfinis du cadastre. :) Sébastien -- Sébastien Dinot, sebastien.di...@free.fr http://sebastien.dinot.free.fr/ Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import Bâti communes de Haute-Saône
mon toc etant les erreurs osmose sur les batiments, j'ai regardé ta derniere intégration de batiments : Faymont effectivement il y avait 4 batiments avec des chevauchements, detectabele comme tu l'as précisé. ces chevauchements étaient a la marge ainsi que quelques batiments a fusionner http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_b%C3%A2timents/Aper%C3%A7u_des_erreurs_rencontr%C3%A9es pour le reste, je n'ai rien vu de choquant, donc +1 pour toi Peut etre le tag source cadastre a enlever sur les etangs si tu les a repris avec bing. +1 pour le tableau de suivi pour les anomalies, il y a les outils dédiés http://osmose.openstreetmap.fr/map/?lat=47.60661lon=6.58806zoom=15 http://tools.geofabrik.de/osmi/?lat=47.60661lon=6.58806zoom=15 http://wiki.openstreetmap.org/wiki/FR:Outils_de_validation bonne contigration (continuation+intégration) didier Le jeudi 15 novembre 2012 à 18:14 +0100, Jean-François Gaffard a écrit : bonjour cela fait quelques jours que j'ai entrepris l'import systématique du bâti disponible pour les communes rurales de Haute-Saône je tiens à jour l'avancée du travail sur la page : http://wiki.openstreetmap.org/wiki/Communes_de_la_Haute-Sa%C3%B4ne Est ce que les plus experts d'entre nous peuvent regarder si je n'incorpore pas trop d'anomalies. Je m'efforce de corriger les routes, les noms de voies d'après le cadastre. (au moins pour quelques une), l'occupation du sol, etc ? est-ce qu'il faut systématiquement corriger les alertes bâtiment à l'intérieur d'un autre ? j'aurais peut-être du poser la question plus tôt ! ___ 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] Import bâti
Il est très facile de charger et fusionner dans JOSM une série de fichiers découpés, plus que l'inverse. Ca ne me gênerai pas que ça soit découpé sur cadastre.openstreetmap.fr, si ça pouvait éviter des imports partiels qui sont parfois bien longs à corriger... Le 16 août 2012 13:41, Vincent de Chateau-Thierry v...@laposte.net a écrit : - sur le principe même de proposer des morceaux (n fichiers) plutôt qu'un tout comme actuellement : certes ça devrait limiter les besoins de gros reverts, dans la mesure où les uploads seraient chacun de taille réduite. Néanmoins, ça implique une méthode de travail que chacun ne souhaite pas forcément adopter. On voit dans le présent fil (et c'était la même chose quand j'ai proposé ce script la première fois [1]) que travailler en découpant selon les axes routiers (= en pâtés de maisons) est plus naturel. -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti
Le ven. 17 août 2012 10:18:03 CEST, Christian Quest a écrit : Il est très facile de charger et fusionner dans JOSM une série de fichiers découpés, plus que l'inverse. Ca ne me gênerai pas que ça soit découpé sur cadastre.openstreetmap.fr, si ça pouvait éviter des imports partiels qui sont parfois bien longs à corriger... On peut simplement proposer les deux : le fichier unique et ses subdivisions. Je tente de m'y mettre aussi vite que possible Philippe ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti
Il n'y a pas dans le cadastre un découpage naturel déjà ? Au moins par feuille cadastrale, les feuilles étant indexées autour de quartiers, voire de bloc peu étendus dans les villes, et déjà selon les axes de circulation qui délimitent les zones cadastrales. Le 17 août 2012 10:48, Philippe Pary phili...@cleo-carto.com a écrit : Le ven. 17 août 2012 10:18:03 CEST, Christian Quest a écrit : Il est très facile de charger et fusionner dans JOSM une série de fichiers découpés, plus que l'inverse. Ca ne me gênerai pas que ça soit découpé sur cadastre.openstreetmap.fr, si ça pouvait éviter des imports partiels qui sont parfois bien longs à corriger... On peut simplement proposer les deux : le fichier unique et ses subdivisions. Je tente de m'y mettre aussi vite que possible Philippe ___ 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] Import bâti
Le 15/08/2012 08:28, Vincent de Chateau-Thierry a écrit : Bonjour, Le 14/08/2012 23:48, Plop76 a écrit : Typiquement, je m'intéresse à ces petites villes : http://www.openstreetmap.org/browse/changeset/12166522 et on arrive déjà à 8000 nœuds et 1300 chemins... J'aurais pu envoyer les modifications dans plusieurs changesets, mais ça aurait été purement artificiel puisque localement toute la zone était déjà effectuée. Je peux te proposer ce script : http://wiki.openstreetmap.org/wiki/User:Vincent_95/Outils/Split qui sert justement à morceler un gros fichier de buildings pour travailler par zones plus petites/légères, et les uploader séparément les unes des autres. Quand je m'en sers, mon seuil est de parvenir à des fichiers bruts de moins de 1 Mo. Si tu te veux/peux pas t'en occuper, je peux le faire tourner sur un fichier qui t'intéresse, et t'envoyer le résultat. Quelle est la licence de ce splitter ? Le must c'est une AGPLv3 selon moi, mais toute licence libre sera la bienvenue :-) Si la licence le permet, je l'ajouterai à l'interface de cadastre.openstreetmap.fr et éventuellement l'appliquerai d'autorité pour les fichiers trop volumineux (10Mo par exemple) Philippe ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti
Le 16/08/2012 08:50, Philippe Pary a écrit : Si la licence le permet, je l'ajouterai à l'interface de cadastre.openstreetmap.fr et éventuellement l'appliquerai d'autorité pour les fichiers trop volumineux (10Mo par exemple) Philippe +1, une très bonne idée ;) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti
Effectivement la solution c'est de faire une sélection rectangulaire dans JOSM et utiliser la fonction envoyer la sélection : on a un récapitulatif du nombre d'objets ajoutés/modifiés/supprimés qui vont être envoyés dans le changeset, ce qui permet de choisir une sélection plus petite. On peut donc facilement réduire le changeset. Je pense même qu'on devrait avoir quelquechose dans JOSM pour limiter la taille de l'envoi, afin qu'un changeset trop gros (trop d'objets) puisse être envoyé en divisant horizontales ou verticales la bounding box de tous les objets (sur la taille la plus grande) en 2 successivement en 2 moitiés, afin d'envoyer des zones rectangulaires. L'autre méthode basée sur un simple compteur qui s'arrête quand le nombre d'objets maximum a été envoyé produira des changesets moins lisibles car partiellement incomplets et qui poseront plus de conflits à résoudre car les objets à envoyer couvriront aléatoirement une zone plus étendue. Si JOSM n'est pas modifié, on pourrait envisager la création d'un plugin afin d'expérimenter cette méthode d'envoi de changesets partiels, avant que cela devienne la méthode standard, où la seule configuration possible serait d'indiquer le nombre d'objets maximum à envoyer (le plugin s'occupant tout seul de découper la box en zones rectangulaires par divisions successives de la bounding box jusqu'à ce que le plafond d'objets ne soit pas dépassé) On peut réutiliser le même commentaire d'envoi pour les changesets succesifs, mais ils devraient chacun couvrir des bounding box qui se recouvrent le moins possible ce qui permet de les distinguer (cela facilite aussi le travail en cas de revert d'un changeset pour réparer une zone). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti
tracer un polygone artificiel n'est pas très pratique s'il est ajouté avec la sélection générée. De plus on risque de l'oublier en passant à la zone suivante. car il faudra le supprimer. A mon avis il est plus pratique de sélectionner un objet existant réel (par exemple une relation boundary. Mais comme l'import du bâti se fait à priori commune par commune et qu'il est rare qu'on ait cartographié des boundaries plus petites que la commune entière (les planches cadastrales ne sont pas nécessairement coupées sur des limites administratives) on n'a pas toujours une relation significative servant de bounding box. La méthode par sélection rectangulaire sera plus souple. Quand on croit avoir fini toutes les sélections rectangulaire, on essaye juste alors de faire un envoi normal pour voir combien d'objets qui auraient été oubliés par les sélections successives. Et on fait l'envoi de ce dernier changeset en envoyant tout normalement Le 15 août 2012 13:31, Christian Quest cqu...@openstreetmap.fr a écrit : Donc tracer un polygone, pour sélectionner des objets dedans, puis le supprimer après... ok, pas des plus pratique, mais c'est déjà bien ! Le 15 août 2012 13:09, Vincent Privat vincent.pri...@gmail.com a écrit : Yes ça marche ! Il faut d'abord sélectionner un polygone puis Selection - All Inside (Alt-Shift-I) -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ 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] Import bâti
Le 16 août 2012 11:27, Philippe Verdy verd...@wanadoo.fr a écrit : tracer un polygone artificiel n'est pas très pratique s'il est ajouté avec la sélection générée. De plus on risque de l'oublier en passant à la zone suivante. car il faudra le supprimer. C'est pour ça que j'ai mis pas des plus pratique. Le plugin qui ajoute cette fonction devrait juste être modifié pour supprimer le polygone si il n'a aucun attribut et un id nul (nouvel objet)... comme ça on trace (temporairement) et on sélectionne... en attendant un vrai outil de sélection par polygone (une modification du lasso pourrai se faire). -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti
J'ai créé un ticket de proposition d'amélioration: http://josm.openstreetmap.de/ticket/7967 -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti
Salut Philippe, De : Philippe Pary Le 15/08/2012 08:28, Vincent de Chateau-Thierry a écrit : Je peux te proposer ce script : http://wiki.openstreetmap.org/wiki/User:Vincent_95/Outils/Split Quelle est la licence de ce splitter ? Le must c'est une AGPLv3 selon moi, mais toute licence libre sera la bienvenue :-) Dont acte pour la licence. Si la licence le permet, je l'ajouterai à l'interface de cadastre.openstreetmap.fr et éventuellement l'appliquerai d'autorité pour les fichiers trop volumineux (10Mo par exemple) Sur le principe, à titre personnel, je suis bien sûr pour l'usage de ce programme (sinon je ne l'aurais pas écrit :-) ). Cependant, je vois 2 bémols pour un usage du programme en l'état de façon systématique sur les gros fichiers de cadastre.openstreetmap.fr : - sur le plan technique, ça n'est pas très robuste, du moins avec ma config, ce qui fait que pour de trop gros fichiers ( 15 Mo) je n'ai pas pu le faire marcher (c'est paradoxal mais c'est comme ça). Le source marche bien pour des fichiers de quelques Mo. Encore une fois, ce script n'a au départ comme but que de répondre à mon propre besoin (et avec mes seules compétences en dev). Si Pinaraf veut en faire une bouchée en C++ faut pas hésiter :-). - sur le principe même de proposer des morceaux (n fichiers) plutôt qu'un tout comme actuellement : certes ça devrait limiter les besoins de gros reverts, dans la mesure où les uploads seraient chacun de taille réduite. Néanmoins, ça implique une méthode de travail que chacun ne souhaite pas forcément adopter. On voit dans le présent fil (et c'était la même chose quand j'ai proposé ce script la première fois [1]) que travailler en découpant selon les axes routiers (= en pâtés de maisons) est plus naturel. vincent [1] : http://lists.openstreetmap.org/pipermail/talk-fr/2010-September/027266.html Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti
Bonjour, Le 14/08/2012 23:48, Plop76 a écrit : Typiquement, je m'intéresse à ces petites villes : http://www.openstreetmap.org/browse/changeset/12166522 et on arrive déjà à 8000 nœuds et 1300 chemins... J'aurais pu envoyer les modifications dans plusieurs changesets, mais ça aurait été purement artificiel puisque localement toute la zone était déjà effectuée. Je peux te proposer ce script : http://wiki.openstreetmap.org/wiki/User:Vincent_95/Outils/Split qui sert justement à morceler un gros fichier de buildings pour travailler par zones plus petites/légères, et les uploader séparément les unes des autres. Quand je m'en sers, mon seuil est de parvenir à des fichiers bruts de moins de 1 Mo. Si tu te veux/peux pas t'en occuper, je peux le faire tourner sur un fichier qui t'intéresse, et t'envoyer le résultat. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti
2012/8/14 Plop76 vaujani...@free.fr: Ça ne change pas la taille du changeset, ça change juste le nombre de requêtes au serveur pour envoyer les modifications. Au final, la taille du changeset est la même. Pour diminuer la taille du changeset, il faut envoyer les modifications par zone. Oui pardon, j'ai confondu changeset et paquets (chunks). Je n'ai pas trouvé de moyen pour diminuer artificiellement la taille maximale du changeset (50.000). Par contre, j'ai vu qu'on pouvait lancer des upload d'objets sélectionnés au lieu d'un upload simple. Peut-être creuser de ce côté-là ... Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti
Très pratique l'envoi de la sélection... Et pour les sélections, on a maintenant le lasso dans JOSM. Ce qui manque (ou que je n'ai pas trouvé), c'est une sélection par polygone... le lasso n'est pas toujours évident à utiliser, surtout sur un trackpad ! Le 15 août 2012 10:03, Pieren pier...@gmail.com a écrit : Oui pardon, j'ai confondu changeset et paquets (chunks). Je n'ai pas trouvé de moyen pour diminuer artificiellement la taille maximale du changeset (50.000). Par contre, j'ai vu qu'on pouvait lancer des upload d'objets sélectionnés au lieu d'un upload simple. Peut-être creuser de ce côté-là ... -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti
Le 15 août 2012 12:07, Christian Quest cqu...@openstreetmap.fr a écrit : Ce qui manque (ou que je n'ai pas trouvé), c'est une sélection par polygone... A priori utilsplugin2 permet déjà ça: http://josm.openstreetmap.de/ticket/4957 The plugin provides for selecting all objects inside an area (closed way or multipolygon) A tester :) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti
Yes ça marche ! Il faut d'abord sélectionner un polygone puis Selection - All Inside (Alt-Shift-I) Le 15 août 2012 13:01, Vincent Privat vincent.pri...@gmail.com a écrit : Le 15 août 2012 12:07, Christian Quest cqu...@openstreetmap.fr a écrit : Ce qui manque (ou que je n'ai pas trouvé), c'est une sélection par polygone... A priori utilsplugin2 permet déjà ça: http://josm.openstreetmap.de/ticket/4957 The plugin provides for selecting all objects inside an area (closed way or multipolygon) A tester :) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti
Donc tracer un polygone, pour sélectionner des objets dedans, puis le supprimer après... ok, pas des plus pratique, mais c'est déjà bien ! Le 15 août 2012 13:09, Vincent Privat vincent.pri...@gmail.com a écrit : Yes ça marche ! Il faut d'abord sélectionner un polygone puis Selection - All Inside (Alt-Shift-I) -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti
ces astuces pourraient etre ajoutée au wiki. http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_b%C3%A2timents je l'ai remanié pour une meilleure lisibilité sans changer réellement le contenu. je n'ai pas abordé le coté eau ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti
A priori oui, mais peut-être avant il faut vérifier que la zone existante à importer est à peu près propre et bien positionnée. Attention si votre fichier d'import s'appuyait sur les anciens bâtiments, le travail précédent de dédoublonnage avant import peut ne plus suffire et des bâtiments peuvent manquer d'un côté ou de l'autre, ou avoir bougé depuis le revert par le bot, ou même avoir été restaurés (annulation d'une ancienne suppression par un utilisateur CC-BY-SA-only). 2012/8/14 Plop76 vaujani...@free.fr: Bonjour, Peut-on recommencer à effectuer des imports, en particulier le bâti d'après le cadastre ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti
Il y a eu un message officiel de la fondation concernant le fait que le bot avait terminé son boulot: http://blog.osmfoundation.org/2012/07/26/automated-redactions-complete/ Par contre, il n'est pas fait mention de la suspension des imports. J'avais posé la question à pnorman, mais pas eu de réponse. Je pense que c'est ok maintenant (qui ne dit mot consent). Le 14 août 2012 18:43, Plop76 vaujani...@free.fr a écrit : Les zones dont je souhaite faire l'import du bâti sont totalement vierges de bâtiments (ou presque), le travail est donc rapide et je n'avais pas enregistré le fichier d'import. Je demande ça parce que je m'étais fait bloqué au milieu d'un import, pendant le travail du bot (et pnorman m'avait demandé de supprimer les points orphelins)... et comme je ne vois pas d'annonce officielle comme quoi le travail du bot est fini et qu'on peut reprendre les imports, je demande pour ne pas risquer d'avoir à reverter un import partiel :) -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti
2012/8/14 Christian Quest cqu...@openstreetmap.fr: Par contre, il n'est pas fait mention de la suspension des imports. J'avais posé la question à pnorman, mais pas eu de réponse. Je pense que c'est ok maintenant (qui ne dit mot consent). Il a été mentionné sur une liste de diffusion qu'il fallait laisser passer un délai d'une semaine après la fin du job du bot (les raisons sont un peu pipeau pour moi mais bon...). Donc oui, je pense que les imports peuvent reprendre puisque le délai est largement dépassé. Attention toutefois, nos import buildings/cadastre sont sous surveillance en général parce que certains ne respectent pas suffisamment les règles (je ne dis pas ça pour plop76 dont je ne connais pas le travail). Notamment, réduisez la taille de vos changeset pour passer sous les radars... Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti
En travaillant par petites zones correspondant à quelques pâtés de maisons, entre des rues principales on évite de tout mélanger, on fait les choses proprement on nettoie les points orphelins. Si ta zone n'a pas beaucoup de points c'est certainement une zone rurale, un village entier d'une commune de moins de 1000 habitants devrait passer sans problème, ce qui reste alors à faire ce sont les fermes autour, par secteur géographique entre les départementales qu'il n'est pas inutile d'ajuster et préciser au passage afin d'améliorer leur précision et le placement des points remarquables (châteaux d'eau, ponts, pylônes d'antennes, pylônes de lignes hautes tension, faciles à repérer sur l'imagerie). Un changeset devrait contenir pas plus de 2000 points, ou environ 200 bâtiments, plus quelques rues ou routes réalignées. Le 14 août 2012 22:06, Plop76 vaujani...@free.fr a écrit : Pieren avait énoncé : 2012/8/14 Christian Quest cqu...@openstreetmap.fr: Par contre, il n'est pas fait mention de la suspension des imports. J'avais posé la question à pnorman, mais pas eu de réponse. Je pense que c'est ok maintenant (qui ne dit mot consent). Il a été mentionné sur une liste de diffusion qu'il fallait laisser passer un délai d'une semaine après la fin du job du bot (les raisons sont un peu pipeau pour moi mais bon...). Donc oui, je pense que les imports peuvent reprendre puisque le délai est largement dépassé. Attention toutefois, nos import buildings/cadastre sont sous surveillance en général parce que certains ne respectent pas suffisamment les règles (je ne dis pas ça pour plop76 dont je ne connais pas le travail). Notamment, réduisez la taille de vos changeset pour passer sous les radars... J'ai justement découvert les règles sur l'import grâce à mon erreur. Je n'avais regardé que le wiki FR sur le cadastre et pas http://wiki.openstreetmap.org/wiki/Import/Guidelines et les mailing lists :) J'ai vu par exemple qu'il fallait normalement avoir un compte dédié pour les imports. J'ai pas vraiment cherché la raison de cette règle, mais la communauté française semble tolérer que pour les imports locaux on puisse garder son compte classique. C'est bien le cas ou alors vaut-il mieux que un compte dédié pour le bâti ? Notamment, réduisez la taille de vos changeset pour passer sous les radars... Il faudrait des changesets de combien de points/chemins ? Parce qu'avec les bâtiments, ça dépasse rapidement les milliers de points... ___ 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] Import bâti
2012/8/14 Plop76 vaujani...@free.fr: J'ai vu par exemple qu'il fallait normalement avoir un compte dédié pour les imports. J'ai pas vraiment cherché la raison de cette règle, mais la communauté française semble tolérer que pour les imports locaux on puisse garder son compte classique. C'est bien le cas ou alors vaut-il mieux que un compte dédié pour le bâti ? Ben, l'idée du compte séparé, c'est pour identifier facilement ce qui est import de ce qui contribution classique (pour faire du revert par exemple). Pour l'import bâti du cadastre, on peut utiliser d'autres critères chercher les tags building et source=cadastre. Surtout, les imports de ce type sont limités en surface (contrairement à l'import Corine Land Cover par ex). Perso, je pense que comme l'import reste limité sur un type d'objet et limité en surface, ça ne justifie pas la création d'un compte spécial (maintenant, si tu veux quand même en faire un, il te faudra un deuxième email de contact pour créer un deuxième compte OSM, ce que je trouve rédhibitoire). Il faudrait des changesets de combien de points/chemins ? Parce qu'avec les bâtiments, ça dépasse rapidement les milliers de points... Dans JOSM, tu peux fixer la taille de tes paquets à transférer (dans le dialogue de l'upload, paramètres avancés). Moi, je les mets à 500 ou 1000 éléments par paquet (JOSM se charge du reste). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti
Le 14 août 2012 22:55, Pieren pier...@gmail.com a écrit : Il faudrait des changesets de combien de points/chemins ? Parce qu'avec les bâtiments, ça dépasse rapidement les milliers de points... Dans JOSM, tu peux fixer la taille de tes paquets à transférer (dans le dialogue de l'upload, paramètres avancés). Moi, je les mets à 500 ou 1000 éléments par paquet (JOSM se charge du reste). Ce que tu indiques dans JOSM ce n'est pas une limite par changeset, mais une limite du nombre d'objets par requête HTTP. JOSM ne sépare pas automatiquement en créant une série de changesets. Pour différentes raisons, la limite que j'ai mise dans JOSM pour le transfert de données c'est 4 objets (alors que pour charger des données depuis le serveur, il utilise une limite implicite de 200 objets, pas idiot pour les noeuds mais souvent trop gros pour les ways qui demandent beaucoup de ressources sur le serveur et qui souvent échouent à cause de ça ; les relations devraient être chargées plutôt par paquet de 20 mais il ny en a nettement moins que les ways c'est pas courant que cela pose problème). C'est peut-être petit, mais même sur mon accès ADSL lent, non rédibitoire en terme de temps de réponse. C'est même ce qui me permet les transferts les plus rapides avec moins de charge pour le serveur, surtout pour vérifier les conflits. Les changesets créés en revanche peuvent monter très au delà. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti
Philippe Verdy avait énoncé : En travaillant par petites zones correspondant à quelques pâtés de maisons, entre des rues principales on évite de tout mélanger, on fait les choses proprement on nettoie les points orphelins. Cela prend évidemment plus de temps sur des grandes zones, mais le travail n'est pas forcément moins propre. Cela demande davantage de manipulation du fichier osm cadastral de base (copier/coller des zones). Même si localement on travaille sur des petites zones, je ne vois que des intérêts à rassembler toutes ces zones dans un seul fichier osm avant l'envoi. Si ta zone n'a pas beaucoup de points c'est certainement une zone rurale, un village entier d'une commune de moins de 1000 habitants devrait passer sans problème, ce qui reste alors à faire ce sont les fermes autour, par secteur géographique entre les départementales qu'il n'est pas inutile d'ajuster et préciser au passage afin d'améliorer leur précision et le placement des points remarquables (châteaux d'eau, ponts, pylônes d'antennes, pylônes de lignes hautes tension, faciles à repérer sur l'imagerie). Un changeset devrait contenir pas plus de 2000 points, ou environ 200 bâtiments, plus quelques rues ou routes réalignées. Typiquement, je m'intéresse à ces petites villes : http://www.openstreetmap.org/browse/changeset/12166522 et on arrive déjà à 8000 nœuds et 1300 chemins... J'aurais pu envoyer les modifications dans plusieurs changesets, mais ça aurait été purement artificiel puisque localement toute la zone était déjà effectuée. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti avec trop de points
Il y a une fonction de simplification de tracé qui marche pas mal dans JOSM La plupart du temps, les grosses quantités de points se retrouvent pour les formes courbes et circulaires. Genre une centaine de points pour un pylône d'éolienne [1] Mais là, c'est sur des formes rectilignes, ce qui est moins fréquent. Il y aurait peut être du brainstorming à faire pour trouver de bonnes analyses pour détecter ce genre de choses [2]. Est-ce que tu arrives à une bonne simplification avec l'outil de JOSM décrit dans [1] ? @+ [1] http://lists.openstreetmap.org/pipermail/talk-fr/2011-November/038088.html [2] http://lists.openstreetmap.org/pipermail/talk-fr/2012-May/043886.html Le 27 juillet 2012 11:45, Stéphane Péneau stephane.pen...@wanadoo.fr a écrit : Bonjour, Je vous lis via l'interface Nabble depuis un moment, et je me suis décidé à m'inscrire car je suis face à une problème que je ne sais pas résoudre : Je me suis attelé depuis quelque temps à la correction des chevauchements de bâtiments sur la région des pays de la loire, et je viens de tomber sur un import du bâti assez récent, et qui comporte énormément de points pour chaque building. voyez-vous même ici : http://www.openstreetmap.org/?**lat=46.676555lon=-0.848492** zoom=18layers=Mhttp://www.openstreetmap.org/?lat=46.676555lon=-0.848492zoom=18layers=M Je voulais contacter l'auteur du changeset, mais franchement, je ne vois pas trop quoi lui dire puisque je ne comprends pas comment celà a pu arriver, ni comment corriger. Voici le changeset : http://www.openstreetmap.org/**browse/changeset/12195453http://www.openstreetmap.org/browse/changeset/12195453 Au passage, si certains font des imports du bâti sur les pays de la loire, et sans corriger les erreurs de chevauchement, attendez-vous à ce que je vous tombe dessus. Mais j'imagine que ça n'arrive pas pour les membres de cette liste, non ;-) A bientôt StephaneP __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti avec trop de points
Il y a l'outil de simplification intégré à JOSM, ainsi qu'un second sous forme de plugin qui fonctionne un peu différemment qui a l'avantage de savoir simplifier les noeuds communs à plusieurs chemins. Entre les deux, on obtient de bons résultats. Ce boulot de simplification fait partie des tâches à accomplir avant envoi vers OSM... comme c'est expliqué sur le wiki: http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_bâtiments#Traitements_des_b.C3.A2timents_avec_JOSM_avant_envoi_vers_serveur_OSM Dommage de le faire après un premier envoi car cela crée inutilement des noeuds de façon très temporaire sur des serveurs d'OSM et génère beaucoup de modifications à importer sur toutes les bases qui se mettent à jour à l'aide des fichiers diff. Un petit rappel du contenu de cette page du wiki au contributeur qui a importé ces bâtiments ne fera pas de mal. Le 27 juillet 2012 11:57, Ab_fab gamma@gmail.com a écrit : Il y a une fonction de simplification de tracé qui marche pas mal dans JOSM La plupart du temps, les grosses quantités de points se retrouvent pour les formes courbes et circulaires. Genre une centaine de points pour un pylône d'éolienne [1] Mais là, c'est sur des formes rectilignes, ce qui est moins fréquent. Il y aurait peut être du brainstorming à faire pour trouver de bonnes analyses pour détecter ce genre de choses [2]. Est-ce que tu arrives à une bonne simplification avec l'outil de JOSM décrit dans [1] ? @+ [1] http://lists.openstreetmap.org/pipermail/talk-fr/2011-November/038088.html [2] http://lists.openstreetmap.org/pipermail/talk-fr/2012-May/043886.html Le 27 juillet 2012 11:45, Stéphane Péneau stephane.pen...@wanadoo.fr a écrit : Bonjour, Je vous lis via l'interface Nabble depuis un moment, et je me suis décidé à m'inscrire car je suis face à une problème que je ne sais pas résoudre : Je me suis attelé depuis quelque temps à la correction des chevauchements de bâtiments sur la région des pays de la loire, et je viens de tomber sur un import du bâti assez récent, et qui comporte énormément de points pour chaque building. voyez-vous même ici : http://www.openstreetmap.org/?lat=46.676555lon=-0.848492zoom=18layers=M Je voulais contacter l'auteur du changeset, mais franchement, je ne vois pas trop quoi lui dire puisque je ne comprends pas comment celà a pu arriver, ni comment corriger. Voici le changeset : http://www.openstreetmap.org/browse/changeset/12195453 Au passage, si certains font des imports du bâti sur les pays de la loire, et sans corriger les erreurs de chevauchement, attendez-vous à ce que je vous tombe dessus. Mais j'imagine que ça n'arrive pas pour les membres de cette liste, non ;-) A bientôt StephaneP ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti avec trop de points
Je m'en suis sorti avec le plugin Simplify Area. 6000 points en moins. Je vais contacter le contributeur, mais il va falloir que je le prenne avec des pincettes, je lui ai déjà fait remarqué toutes les erreurs de chevauchement il y a quelques jours, il va croire que je le poursuis... Le 27/07/2012 12:33, Christian Quest a écrit : Il y a l'outil de simplification intégré à JOSM, ainsi qu'un second sous forme de plugin qui fonctionne un peu différemment qui a l'avantage de savoir simplifier les noeuds communs à plusieurs chemins. Entre les deux, on obtient de bons résultats. Ce boulot de simplification fait partie des tâches à accomplir avant envoi vers OSM... comme c'est expliqué sur le wiki: http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_bâtiments#Traitements_des_b.C3.A2timents_avec_JOSM_avant_envoi_vers_serveur_OSM Dommage de le faire après un premier envoi car cela crée inutilement des noeuds de façon très temporaire sur des serveurs d'OSM et génère beaucoup de modifications à importer sur toutes les bases qui se mettent à jour à l'aide des fichiers diff. Un petit rappel du contenu de cette page du wiki au contributeur qui a importé ces bâtiments ne fera pas de mal. Le 27 juillet 2012 11:57, Ab_fab gamma@gmail.com a écrit : Il y a une fonction de simplification de tracé qui marche pas mal dans JOSM La plupart du temps, les grosses quantités de points se retrouvent pour les formes courbes et circulaires. Genre une centaine de points pour un pylône d'éolienne [1] Mais là, c'est sur des formes rectilignes, ce qui est moins fréquent. Il y aurait peut être du brainstorming à faire pour trouver de bonnes analyses pour détecter ce genre de choses [2]. Est-ce que tu arrives à une bonne simplification avec l'outil de JOSM décrit dans [1] ? @+ [1] http://lists.openstreetmap.org/pipermail/talk-fr/2011-November/038088.html [2] http://lists.openstreetmap.org/pipermail/talk-fr/2012-May/043886.html Le 27 juillet 2012 11:45, Stéphane Péneau stephane.pen...@wanadoo.fr a écrit : Bonjour, Je vous lis via l'interface Nabble depuis un moment, et je me suis décidé à m'inscrire car je suis face à une problème que je ne sais pas résoudre : Je me suis attelé depuis quelque temps à la correction des chevauchements de bâtiments sur la région des pays de la loire, et je viens de tomber sur un import du bâti assez récent, et qui comporte énormément de points pour chaque building. voyez-vous même ici : http://www.openstreetmap.org/?lat=46.676555lon=-0.848492zoom=18layers=M Je voulais contacter l'auteur du changeset, mais franchement, je ne vois pas trop quoi lui dire puisque je ne comprends pas comment celà a pu arriver, ni comment corriger. Voici le changeset : http://www.openstreetmap.org/browse/changeset/12195453 Au passage, si certains font des imports du bâti sur les pays de la loire, et sans corriger les erreurs de chevauchement, attendez-vous à ce que je vous tombe dessus. Mais j'imagine que ça n'arrive pas pour les membres de cette liste, non ;-) A bientôt StephaneP ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab Il n'y a pas de pas perdus ___ 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] Import bâti avec trop de points
Le 27 juillet 2012 11:45, Stéphane Péneau stephane.pen...@wanadoo.fr a écrit : Bonjour, Je vous lis via l'interface Nabble depuis un moment, et je me suis décidé à m'inscrire car je suis face à une problème que je ne sais pas résoudre : Je me suis attelé depuis quelque temps à la correction des chevauchements de bâtiments sur la région des pays de la loire, Bonjour Stéphane, Sur les chevauchements de bâtiment, je pense qu'il ne faut pas trop s'en préoccuper: je ne doute pas qu'on aboutisse à un automate de correction d'ici quelques temps. A+ Bruno ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti avec trop de points
On 27/07/2012 12:43, Stéphane Péneau wrote: Je m'en suis sorti avec le plugin Simplify Area. 6000 points en moins. Je vais contacter le contributeur, mais il va falloir que je le prenne avec des pincettes, je lui ai déjà fait remarqué toutes les erreurs de chevauchement il y a quelques jours, il va croire que je le poursuis... Bonjour, L'élimination des points en trop ne pourrait-elle pas se faire dans l'outil d'importation du cadastre ? Jean-Claude ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti avec trop de points
Honnêtement, je ne sais pas ce qu'il s'est passé lors de cet import car sur ceux que j'ai fait, je n'ai jamais rencontré ce problème de profusion de point inutiles. Le 27/07/2012 13:27, Jean-Claude Repetto a écrit : On 27/07/2012 12:43, Stéphane Péneau wrote: Je m'en suis sorti avec le plugin Simplify Area. 6000 points en moins. Je vais contacter le contributeur, mais il va falloir que je le prenne avec des pincettes, je lui ai déjà fait remarqué toutes les erreurs de chevauchement il y a quelques jours, il va croire que je le poursuis... Bonjour, L'élimination des points en trop ne pourrait-elle pas se faire dans l'outil d'importation du cadastre ? Jean-Claude ___ 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] Import bâti avec trop de points
Salut Bruno, Je suis en train d'en essayer un, mais je ne suis pas vraiment convaincu. Oui, ça corrige les chevauchements, donc les erreurs affichées par osmose, mais ça ne corrige pas le bâti en lui-même. L'exemple le plus courant, c'est l'avancée de toit d'une maison particulière. Assez régulièrement, l'outil de conversion ne joint pas les 2 morceaux. S'il y a une petite inclinaison, alors il y a un premier point qui génère le chevauchement, et un autre qui n'est pas rattaché au bâti principal. Le premier est corrigé, mais pas le second, et ça ne me plait pas puisqu'on se retrouve avec une avancée de toit partiellement dans le vide. Le 27/07/2012 13:23, Bruno Cortial a écrit : Le 27 juillet 2012 11:45, Stéphane Péneau stephane.pen...@wanadoo.fr mailto:stephane.pen...@wanadoo.fr a écrit : Bonjour, Je vous lis via l'interface Nabble depuis un moment, et je me suis décidé à m'inscrire car je suis face à une problème que je ne sais pas résoudre : Je me suis attelé depuis quelque temps à la correction des chevauchements de bâtiments sur la région des pays de la loire, Bonjour Stéphane, Sur les chevauchements de bâtiment, je pense qu'il ne faut pas trop s'en préoccuper: je ne doute pas qu'on aboutisse à un automate de correction d'ici quelques temps. A+ Bruno ___ 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] Import bâti avec trop de points
didier2020 a bien avancé sur la question, ça approche... Le 27 juillet 2012 13:23, Bruno Cortial bruno.cort...@laposte.net a écrit : Sur les chevauchements de bâtiment, je pense qu'il ne faut pas trop s'en préoccuper: je ne doute pas qu'on aboutisse à un automate de correction d'ici quelques temps. -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti avec trop de points
C'est bien le script de didier2020 que j'essaie Le 27/07/2012 14:28, Christian Quest a écrit : didier2020 a bien avancé sur la question, ça approche... Le 27 juillet 2012 13:23, Bruno Cortial bruno.cort...@laposte.net a écrit : Sur les chevauchements de bâtiment, je pense qu'il ne faut pas trop s'en préoccuper: je ne doute pas qu'on aboutisse à un automate de correction d'ici quelques temps. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti avec trop de points
On 27/07/2012 15:28, didier2020 wrote: on parle de moi? je rougis ;) Faille/ce que le script ne sais pas faire: - corriger les erreurs des batiments suisses (ce n'est pas une blague) - suivant la précision du bati (7 ou 6 décimales), le script est plus ou moins performant - faire comme si un trait a une épaisseur de 15/20 cm pour simuler la largeur du mur afin de raccrocher les nodes éloignées tout en ayant un mur droit. De plus, c'est difficile (pour moi...) a identifier: un coin de mur en commun, ou 2 traits ayant un angle tres proche Un algorithme genre Douglas-Peucker ne serait-il pas utilisable pour la simplification ? Jean-Claude ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti avec trop de points
Le vendredi 27 juillet 2012 à 18:32 +0200, Jean-Claude Repetto a écrit : On 27/07/2012 15:28, didier2020 wrote: on parle de moi? je rougis ;) Faille/ce que le script ne sais pas faire: - corriger les erreurs des batiments suisses (ce n'est pas une blague) - suivant la précision du bati (7 ou 6 décimales), le script est plus ou moins performant - faire comme si un trait a une épaisseur de 15/20 cm pour simuler la largeur du mur afin de raccrocher les nodes éloignées tout en ayant un mur droit. De plus, c'est difficile (pour moi...) a identifier: un coin de mur en commun, ou 2 traits ayant un angle tres proche Un algorithme genre Douglas-Peucker ne serait-il pas utilisable pour la simplification ? merci, je ne connaissais pas. voir l'image jointe. le resultat voulu etant a droite. Jean-Claude ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr attachment: Capture-3.png___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
Bonjour, J'ai deux points que j'aimerais ajouter à ce débat. - Il y a deux fois plus d'erreurs que ce que relève osmose. En plus des chevauchements il y a les vides incorrects entre les bâtiments. - Il y a peut être une solution pas trop compliqué à mettre en œuvre pour corriger les deux cas d'erreur avec postgis 2.0 et la fonction http://postgis.org/documentation/manual-svn/ST_Snap.html Frédéric Le 7 février 2012 21:08, DH dhel...@free.fr a écrit : Le 07/02/2012 18:43, sly (sylvain letuffe) a écrit : Il semblerait qu'on passe à 2-2, mais je ne partage pas tout à fait l'avis de christian. Ni moi le tien. C'est ce qui fait le charme (?) de cette liste. Hé ben je ne dois pas être tombé sur les bonnes communes, mais ça ne me semble pas pas tant que ça. un cadastre importé, c'est un cadastre importé. C'est sûr si c'est un patelin de 300 habitants, c'est moins de boulot qu'une banlieue de plusieurs milliers d'âmes (genre Kingersheim au hasard). L'enjeu et le travail reste le même : 1. on laisse faire les outils en attendant qu'ils s'améliorent (sur quels critères d'abord ?) et on a ce que l'on mérite 2. on connaît les limites de 1, mais le sang de la fourmi ne fait qu'un seul tour quand elle découvre que des miettes de qualité peuvent être grapillées (la fourmi est écolo dans l'âme). La fourmi est besogneuse, sinon c'est une cigale déguisée en fourmi. L'import de masse est déjà sévèrement critiqué par nos voisins. Alors si en plus, on ne corrige pas les erreurs géométriques, ça va être encore pire pour notre (déjà mauvaise) réputation. Je suis bien d'accord. Une critique que j'ai déjà entendu concerne Corine qui parfois chevauche aussi d'autres polygones landuse (sans doute suite à une intervention manuelle, soit dans l'import, soit dans la création du doublon) et qui perdure dans la base pendant des années. Je suis aussi d'accord A l'analyse, il semble que les outils (et autre méthodes d'import de masse) soient tolérés dans la mesure où la colonie ne s'assied pas sur le tas de données produit d'un air satisfait : ça c'est fait, mais prend pelle et pioche pour remuer le tout et l'intéger au reste de la base. Certains regrettent d'avantage les imports sans voirie, ou sans correction sur les voiries qui se croisent alors avec le bâti. Mais c'est le même mécanisme qui entre en jeu, celui de dire que d'autres s'en chargeront plus-tard. Pas d'accord. Le mécanisme dont il est question, c'est la possibilité de réparer de manière automatique ce que des humains devraient faire sinon. Dans celui que tu cites, je n'arrive pas à imaginer un processus automatique pour placer des rues entre les bâtiments ou pour savoir où passerait vraiment la rue. Donc là, oui, je suis d'accord pour condamner ces imports avec chevauchement car aucun robot ne pourra le corriger plus tard. Repense à HAL9000 Chacun est responsable de ses apports (tiens cela ressemble encore trop à imports) à la base. Chaque contributeur est, de fait, responsable du niveau de qualité qu'il injecte dans la base. Noboby is perfect (as a ro(b)ot ?), mais on moins on aura mis de la transpiration dans cette base ; c'est ce qui devrait faire son odeur si particulière, appréciée par certains. Denis, tâcheron, moucheron, fourmi, cigale, cœlacanthe selon l'humeur ___ 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] Import bâti = nettoyage des données cleo carto
Le 8 février 2012 10:05, Frédéric Rodrigo fred.rodr...@gmail.com a écrit : Bonjour, J'ai deux points que j'aimerais ajouter à ce débat. - Il y a deux fois plus d'erreurs que ce que relève osmose. En plus des chevauchements il y a les vides incorrects entre les bâtiments. - Il y a peut être une solution pas trop compliqué à mettre en œuvre pour corriger les deux cas d'erreur avec postgis 2.0 et la fonction http://postgis.org/documentation/manual-svn/ST_Snap.html Frédéric Un des 2 scripts précédemment postés fait un J JOSM (Join Node to Way)sur tous les noeuds, et donc recolle les bâtiments. Mais j'ai bien compris que vous n'en vouliez pas de mes bidules ;-) A+ Bruno ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
par contre, j'ai justement corrigé pas mal de truc de ce genre dont l'auteur etait le pieren_bot... ;) je tiens a faire ici publiquement mes excuses au bot, il n'est que le dernier modificateur de bâtiments qui était déjà en erreurs. -- JB ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
On mardi 7 février 2012, DH wrote: Le 07/02/2012 18:43, sly (sylvain letuffe) a écrit : Il semblerait qu'on passe à 2-2, mais je ne partage pas tout à fait l'avis de christian. Ni moi le tien. C'est ce qui fait le charme (?) de cette liste. C'est même un de ces buts ! confronter des idées et des choix pour tenter d'obtenir une meilleure cohérance. A lire les débats, je crois que moi et christian perdons sur un score sans appel de 7-2 J'appliquerais donc, au delà de ce que j'en pense, ce qui resort de ce débat démocratique. C'est à dire suspendre mes imports du bâti. Vu qu'il est exclus que je fasse à la main ce qu'un robot pourrait faire, je laisse ça à d'autres, et j'arrête de mettre mes cochonneries dans la base. Denis, tâcheron, moucheron, fourmi, cigale, cœlacanthe selon l'humeur Je me qualifierais de fourmi raisonnée ou de cigale assumée. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
Frédéric Rodrigo : - Il y a peut être une solution pas trop compliqué à mettre en œuvre pour corriger les deux cas d'erreur avec postgis 2.0 et la fonction http://postgis.org/documentation/manual-svn/ST_Snap.html Je pense que c'est une solution valable pour nettoyer sa propre copie de la base, pas une méthode pour corriger en amont celle de OSM. Bruno : Un des 2 scripts précédemment postés fait un J JOSM (Join Node to Way)sur tous les noeuds, et donc recolle les bâtiments. Mais j'ai bien compris que vous n'en vouliez pas de mes bidules ;-) Pas du tout, je pense que tu te trompes ! Je te soutiens à donf et je suis sûr que la majorité serait pour un nettoyage automatique, si suffisamment bien fait, de la base OSM (justement pour éviter de se le taper à la main) Le problème a mon avis, il est là : - 10 personnes sur cette liste savent lancer ton programme en python - 6 ont les compétences de l'analyser le tester et l'améliorer - et 0.5 ont le temps de le faire ! En clair, tu as accompli une très bonne première étape : fournir un soft pour nettoyer. Frédéric et/ou jocelyn ont fourni l'outil pour repérer les erreurs (osmose) et Philippe a fourni un export basé sur le soft qadastre de je sais plus qui, qui malheureusement ne fourni pas un export cadastre assez propre (ce n'est pas un reproche) Maintenant, on passe au yaka, c'est à dire trouver celui qui va proposer non pas une brique, mais un résultat final, qui soit facile (ou plutôt très très facile) à contrôler par d'autres. Puis proposer un plan d'action, obtenir l'accord d'une majorité d'exprimés, et le faire. Comme toujours, facile à dire. Donc non, c'est pas qu'on en veut pas, c'est qu'on voudrait bien que tu fasses tout ;-))) Dans la limite de mes compétences+temps, je veux bien filer un coup de main, je vais regarder ce qu'il fait ton bidule et voir comment je peux l'utiliser et voir comment je pourrais par exemple présenter un échantillon avant/après d'un fichier -houses.osm d'une commune. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
J'ajoute qu'au delà des chevauchements, il y a les bâtiments scindés en plusieurs morceaux (par les limites de parcelles) qui prennent nettement plus de temps à corriger. Romain Le 8 février 2012 14:18, sly (sylvain letuffe) li...@letuffe.org a écrit : On mardi 7 février 2012, DH wrote: Le 07/02/2012 18:43, sly (sylvain letuffe) a écrit : Il semblerait qu'on passe à 2-2, mais je ne partage pas tout à fait l'avis de christian. Ni moi le tien. C'est ce qui fait le charme (?) de cette liste. C'est même un de ces buts ! confronter des idées et des choix pour tenter d'obtenir une meilleure cohérance. A lire les débats, je crois que moi et christian perdons sur un score sans appel de 7-2 J'appliquerais donc, au delà de ce que j'en pense, ce qui resort de ce débat démocratique. C'est à dire suspendre mes imports du bâti. Vu qu'il est exclus que je fasse à la main ce qu'un robot pourrait faire, je laisse ça à d'autres, et j'arrête de mettre mes cochonneries dans la base. Denis, tâcheron, moucheron, fourmi, cigale, cœlacanthe selon l'humeur Je me qualifierais de fourmi raisonnée ou de cigale assumée. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ 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] Import bâti = nettoyage des données cleo carto
Le 8 février 2012 14:52, Pieren pier...@gmail.com a écrit : 2012/2/8 Romain MEHUT romain.me...@gmail.com: J'ajoute qu'au delà des chevauchements, il y a les bâtiments scindés en plusieurs morceaux (par les limites de parcelles) qui prennent nettement plus de temps à corriger. Non. Si les polygones sont correctement attachés, la fusion des deux se fait en une touche avec JOSM. Laquelle? Pieren ___ 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] Import bâti = nettoyage des données cleo carto
Le 8 février 2012 14:54, Romain MEHUT romain.me...@gmail.com a écrit : Le 8 février 2012 14:52, Pieren pier...@gmail.com a écrit : 2012/2/8 Romain MEHUT romain.me...@gmail.com: J'ajoute qu'au delà des chevauchements, il y a les bâtiments scindés en plusieurs morceaux (par les limites de parcelles) qui prennent nettement plus de temps à corriger. Non. Si les polygones sont correctement attachés, la fusion des deux se fait en une touche avec JOSM. Laquelle? Maj + J ;-) Faut regarder dans les menus ce que propose JOSM ;-) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
On Wed, 8 Feb 2012 14:32:25 +0100, sly (sylvain letuffe) wrote: Frédéric Rodrigo : - Il y a peut être une solution pas trop compliqué à mettre en œuvre pour corriger les deux cas d'erreur avec postgis 2.0 et la fonction http://postgis.org/documentation/manual-svn/ST_Snap.html Je pense que c'est une solution valable pour nettoyer sa propre copie de la base, pas une méthode pour corriger en amont celle de OSM. Bruno : Un des 2 scripts précédemment postés fait un J JOSM (Join Node to Way)sur tous les noeuds, et donc recolle les bâtiments. Mais j'ai bien compris que vous n'en vouliez pas de mes bidules ;-) Pas du tout, je pense que tu te trompes ! Je te soutiens à donf et je suis sûr que la majorité serait pour un nettoyage automatique, si suffisamment bien fait, de la base OSM (justement pour éviter de se le taper à la main) C'est peut etre mes expériences désastreuse d’écriture de robot (ou plutot leurs executions), mais je me mefie toujours un peut des correction automatique. Il y aura toujours des cas de la vrai vie auquel on n'aura pas pensé Un exemple tout bete : les batiments http://www.openstreetmap.org/browse/way/81188412 et http://www.openstreetmap.org/browse/way/81188234 sont bien séparés de 20cm, il ne faut pas les recoller. -- JB ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
Bonjour, De : Etienne Trimaille Le 8 février 2012 14:54, Romain MEHUT a écrit : 2012/2/8 Romain MEHUT : J'ajoute qu'au delà des chevauchements, il y a les bâtiments scindés en plusieurs morceaux (par les limites de parcelles) qui prennent nettement plus de temps à corriger. N'empêche que ce temps, aussi long soit il, reste d'un volume ridicule en comparaison de tracer tout le bâti à la main, comme ça se faisait, sans autre choix, jusqu'à juin 2010. Ce temps (Denis parlait de transpiration, on parle de la même chose) figure une forme de valeur ajoutée, qui distingue de l'import brut, associé au recalage ou au tracé du filaire de voies. Ne pas oublier qu'il n'y a aucune obligation à importer du bâti, tout comme il n'y a aucune obligation de faire du chiffre / du volume d'upload. De mon côté je garde une logique assez simple : je n'importe que là où je peux ajouter autre chose que ce que donne le cadastre : ne serait-ce qu'un POI, mais ce sera forcément un endroit où j'ai déjà mis les pieds. Oui, ça limite le nombre de patelins, mais ça limite aussi les imports à l'aveugle. Je pense qu'on met forcément un peu plus d'énergie à bien faire en s'occupant de coins qu'on connaît et qu'on pratique. vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
J'ajoute qu'au delà des chevauchements, il y a les bâtiments scindés en plusieurs morceaux (par les limites de parcelles) qui prennent nettement plus de temps à corriger. Comme ça vient d'être signalé, il y a des bâtiments mitoyens construits indépendamment sur des parcelles voisines (typiquement dans les centres anciens) qui n'ont pas lieu d'être fusionnés. Et inversement, des bâtiments uniques construits sur plusieurs parcelles qui eux doivent être fusionnés. Les données du cadastre seul ne permettent pas de choisir. Donc, pas de fusion/correction automatique, uniquement du manuel après contrôle sur le terrain. Sinon, j'ai aussi rencontré des cas de bâtiments récents sur parcelle unique mais découpés en plusieurs morceaux. Dans ce cas, je serais plus favorable à un traitement automatisé. Il semble qu'à un moment donné (durant automne 2011), cleo carto faisait la fusion en automatique. Vous confirmez? Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
-Message d'origine- De : sly (sylvain letuffe) [mailto:li...@letuffe.org] Envoyé : mercredi 8 février 2012 14:32 À : Discussions sur OSM en français Objet : Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto Frédéric Rodrigo : - Il y a peut être une solution pas trop compliqué à mettre en œuvre pour corriger les deux cas d'erreur avec postgis 2.0 et la fonction http://postgis.org/documentation/manual-svn/ST_Snap.html Je pense que c'est une solution valable pour nettoyer sa propre copie de la base, pas une méthode pour corriger en amont celle de OSM. Je lance une idée en l'air (pour voir où elle peut retomber) : - injecter le fichier osm brut de fonderie (ou générer directement à partir du pdf) une base locale PostGIS - utiliser les outils de PostGIS pour signaler les éléments problématiques * points trop rapprochés (seuil de tolérance à définir) * superposition d'objets * détection de surfaces inférieures à un autre seuil * etc - le signalement est rabattu sur un élément FIXME ; des corrections simples peuvent peut-être déjà intervenir au sein de la base - export de PostGIS vers osm Si l'utilisateur voit dans JOSM tous les FIXME, cela peut l'aider à corriger plus facilement, non ? Je ne sais pas si c'est faisable, mais cela mérite peut-être qu'on y réfléchisse Mes 0,02€ Denis ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
De : HELFER Denis Je lance une idée en l'air (pour voir où elle peut retomber) : - injecter le fichier osm brut de fonderie (ou générer directement à partir du pdf) une base locale PostGIS - utiliser les outils de PostGIS pour signaler les éléments problématiques * points trop rapprochés (seuil de tolérance à définir) * superposition d'objets * détection de surfaces inférieures à un autre seuil * etc - le signalement est rabattu sur un élément FIXME ; des corrections simples peuvent peut-être déjà intervenir au sein de la base - export de PostGIS vers osm Si l'utilisateur voit dans JOSM tous les FIXME, cela peut l'aider à corriger plus facilement, non ? Je ne sais pas si c'est faisable, mais cela mérite peut-être qu'on y réfléchisse +1 pour le pré-traitement des fichiers -houses avant leur mise à disposition, pour leur appliquer des corrections, que ce soit via PostGIs ou les scripts de Bruno par ex. En revanche je ne crois pas à l'intérêt d'ajouter des FIXME dans le fichier. Pour moi la fonction d'avertissement est déjà (bien) assurée par le Validator, je crains que ces FIXME ne se retrouvent directement en base. Ignorer un warning du Validator ou ignorer un FIXME, je vois peu de différence (vu de ma lorgnette). vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
Le 8 février 2012 14:57, Etienne Trimaille etienne.trimai...@gmail.com a écrit : Le 8 février 2012 14:54, Romain MEHUT romain.me...@gmail.com a écrit : Le 8 février 2012 14:52, Pieren pier...@gmail.com a écrit : 2012/2/8 Romain MEHUT romain.me...@gmail.com: J'ajoute qu'au delà des chevauchements, il y a les bâtiments scindés en plusieurs morceaux (par les limites de parcelles) qui prennent nettement plus de temps à corriger. Non. Si les polygones sont correctement attachés, la fusion des deux se fait en une touche avec JOSM. Laquelle? Maj + J ;-) Faut regarder dans les menus ce que propose JOSM ;-) Merci. Voici un peu de temps de gagné! Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
Les FIXME c'est justement pour ce que le validateur ne détecte pas ou ne peut pas détecter, par exemple des données à affiner ou vérifier sur le terrain. En revanche, mettre FIXME dans une valeur de tag (par exemple name=FIXME) est inutile. Mais FIXME est tout à fait utilisable en tant que clé, et prend alors une valeur textuelle expliquant ce qui devrait être réglé (mais pas la peine de mentionner non plus un FIXME s'il manque soit un nom soit une référence pour une route). Exemples de FIXME : * mentionner qu'il y a désaccord entre plusieurs sources, ou une ambiguité sur les dates de ces sources, ce qui ne permet pas de prendre une décision. * mentionner que des données d'un import n'ont pas pu être traitées de façon automatique, et qu'un tag (par exemple description) contient des données à interpréter depuis la description, données qu'on peut alors reclasser dans d'autres tag. * mentionner un doûte sur une valeur * mentionner un tracé douteux, même si le validateur ne signale rien, par exemple des numéros de voies différents dans la même commune et pour le même nom alors que ces voies sont connectées, ou bien deux voies éloignées (non connectées), qui utilisent le même nom et la même référence au sein de la même zone de numérotation (par exemple dans la commune pour les voies communales, dans le département pour une route départementale ou un chemin départemental, le pays entier pour une route nationale ou une autoroute) Noter cependant ces disjonctions arrivent dans certains cas sur un tronçon où la route change temporairement de classification car le tronçon de raccordement n'est pas encore construit ou aménagé (un exemple en est l'A84 qui est disjointe à Avranche, car le tronçon de raccordement se fait encore par la N 175 qui traverse la ville (et se prolonge ensuite : il manque encore le tronçon autoroutier en rocade d'Avranche, qui ne figure même pas encore sur les chantiers; en attendant c'est la nationale, qui a été réaménagée, mais pas suffisamment pour avoir la classification autoroutière). Ces disjonctions ne sont donc pas toujours des erreurs, raison pour laquelle le validateur ne signale rien. Un FIXME en revanche peut être utilisé temporairement pour des erreurs à vérifier et corriger plus tard. Si la vérification a eu lieu, et qu'il n'y a pas d'erreur, ce FIXME sera à remplacer par une note mentionnant que la disjonction est normale en l'état actuel des lieux. Osmose n'affiche pas réellement les fixme mis en valeurs d'une clé (hormi si cela est contraire à d'autres règles de toponymie ou de typographie et capitalisation), mais détecte bien les noms de clés fixme ou FIXME. La présence d'un tel FIXME ne permet aucune correction automatique. Il faut un contrmole humain qui ne se contentera pas de le supprimer car ils ont une raison d'être. Le 8 février 2012 18:00, Vincent de Chateau-Thierry v...@laposte.net a écrit : De : HELFER Denis Je lance une idée en l'air (pour voir où elle peut retomber) : - injecter le fichier osm brut de fonderie (ou générer directement à partir du pdf) une base locale PostGIS - utiliser les outils de PostGIS pour signaler les éléments problématiques * points trop rapprochés (seuil de tolérance à définir) * superposition d'objets * détection de surfaces inférieures à un autre seuil * etc - le signalement est rabattu sur un élément FIXME ; des corrections simples peuvent peut-être déjà intervenir au sein de la base - export de PostGIS vers osm Si l'utilisateur voit dans JOSM tous les FIXME, cela peut l'aider à corriger plus facilement, non ? Je ne sais pas si c'est faisable, mais cela mérite peut-être qu'on y réfléchisse +1 pour le pré-traitement des fichiers -houses avant leur mise à disposition, pour leur appliquer des corrections, que ce soit via PostGIs ou les scripts de Bruno par ex. En revanche je ne crois pas à l'intérêt d'ajouter des FIXME dans le fichier. Pour moi la fonction d'avertissement est déjà (bien) assurée par le Validator, je crains que ces FIXME ne se retrouvent directement en base. Ignorer un warning du Validator ou ignorer un FIXME, je vois peu de différence (vu de ma lorgnette). vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
JOSM propose la correction automatique de la superposition de bâtiment ? Je n'ai pas trouvé. Comment procéder ? -- View this message in context: http://gis.19327.n5.nabble.com/Import-bati-nettoyage-des-donnees-cleo-carto-tp5432658p5463162.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
- Mail d'origine - De: partir-en-vtt ad...@partir-en-vtt.com À: talk-fr@openstreetmap.org Envoyé: Tue, 07 Feb 2012 14:45:00 +0100 (CET) Objet: Re: [OSM-talk-fr]Import bâti = nettoyage des données cleo carto JOSM propose la correction automatique de la superposition de bâtiment ? Je n'ai pas trouvé. Comment procéder ? + lancer la validation. + dans la fenetre ou apparait l'analyse du validator + clic sur le sens interdit pour faire apparaitre le détail des erreurs + clic sur le type d'erreur = il apparait le bouton réparer. je te dis cela de souvenir, je n'ai pas josm sous la main... didier -- View this message in context: http://gis.19327.n5.nabble.com/Import-bati-nettoyage-des-donnees-cleo-carto-tp5432658p5463162.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- didier --mapeur amateur-- ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
Bonjour et merci pour la réponse, La superposition n'est pas représenté comme une erreur mais un avertissement. De plus, lorsque je clic sur le nœud, le bouton réparer n'est pas disponible et j'en déduit qu'il faut donc le faire à la main ? -- View this message in context: http://gis.19327.n5.nabble.com/Import-bati-nettoyage-des-donnees-cleo-carto-tp5432658p5463295.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
Bonjour, De : partir-en-vtt La superposition n'est pas représenté comme une erreur mais un avertissement. De plus, lorsque je clic sur le nœud, le bouton réparer n'est pas disponible et j'en déduit qu'il faut donc le faire à la main ? Le Validator passe une erreur pour 2 bâtiments rigoureusement superposés (même suite de nodes pour définir les 2 bâtiments). Dans ce cas, on a une erreur Chemins dupliqués et la possibilité de réparer en un clic. Idem pour des noeuds superposés. En revanche pour des bâtiments partiellement superposés (chacun n'ayant qu'une partie de sa surface superposée à l'autre), on n'a en effet qu'un warning Bâtiments se chevauchant, et là, il faut sa souris, son clavier, et un peu de temps :-) vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
- Mail d'origine - De: partir-en-vtt ad...@partir-en-vtt.com À: talk-fr@openstreetmap.org Envoyé: Tue, 07 Feb 2012 15:39:08 +0100 (CET) Objet: Re: [OSM-talk-fr]Import bâti = nettoyage des données cleo carto Bonjour et merci pour la réponse, La superposition n'est pas représenté comme une erreur mais un avertissement. = les noeuds ne doivent pas avoir exactement les memes coordonnées ... De plus, lorsque je clic sur le nœud, le bouton réparer n'est pas disponible et j'en déduit qu'il faut donc le faire à la main ? = cela semble la seule issue ... oui ! -- View this message in context: http://gis.19327.n5.nabble.com/Import-bati-nettoyage-des-donnees-cleo-carto-tp5432658p5463295.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- didier --mapeur amateur-- ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
On Tue, 7 Feb 2012 06:39:08 -0800 (PST), partir-en-vtt wrote: Bonjour et merci pour la réponse, La superposition n'est pas représenté comme une erreur mais un avertissement. le validator leve plusieurs erreurs - des ways en double, donc des batiments en double/triple depuis le cadastre - des points qui ont les même coordonnées mais qui sont deux points différents - des points qui sont mis deux fois dans le même way (et pas pour boucler le batiment) - d'autres dans les 2 premiers cas, je crois qu'il propose l'action de correction De plus, lorsque je clic sur le nœud, le bouton réparer n'est pas disponible et j'en déduit qu'il faut donc le faire à la main ? pour certains cas, oui tu a un ID de way ? -- JB ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
C'était pour un nouvel import et bon 70 retouches à la mano, ce n'est quand même pas la joie. Je vais donc continuer à créer une moulinette corrigeant ces soucis. -- View this message in context: http://gis.19327.n5.nabble.com/Import-bati-nettoyage-des-donnees-cleo-carto-tp5432658p5463462.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
On mardi 7 février 2012, partir-en-vtt wrote: JOSM propose la correction automatique de la superposition de bâtiment ? Je n'ai pas trouvé. Comment procéder ? Pour ma part, j'ai abandonné ce genre de corrections. Oui oui, je sais, c'est pas bien. Explications : - C'est un boulot manuel de fou - Y'a déjà du pourri dans la base - un logiciel pourrait en réparer une grande partie automatiquement - D'autres ne feront de toute façon pas cette effort J'ai donc jugé qu'il n'y avait que peu d'issues valables à cet état de fait : 1) développer un robot qui nettoye le merdier des bâtiments 2) ne rien faire Dans les deux cas, rien ne justifie selon moi de perdre du temps contributeur qui serait mieux employé à autre chose. ps: je n'ai pas dis que réparer le problème en amont (fichier -houses) n'était pas une bonne idée, je dis que ça n'est de toute façon pas suffisant -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
Le 7 février 2012 16:31, sly (sylvain letuffe) li...@letuffe.org a écrit : On mardi 7 février 2012, partir-en-vtt wrote: JOSM propose la correction automatique de la superposition de bâtiment ? Je n'ai pas trouvé. Comment procéder ? Pour ma part, j'ai abandonné ce genre de corrections. Oui oui, je sais, c'est pas bien. Explications : - C'est un boulot manuel de fou - Y'a déjà du pourri dans la base - un logiciel pourrait en réparer une grande partie automatiquement - D'autres ne feront de toute façon pas cette effort J'ai donc jugé qu'il n'y avait que peu d'issues valables à cet état de fait : 1) développer un robot qui nettoye le merdier des bâtiments 2) ne rien faire Dans les deux cas, rien ne justifie selon moi de perdre du temps contributeur qui serait mieux employé à autre chose. ps: je n'ai pas dis que réparer le problème en amont (fichier -houses) n'était pas une bonne idée, je dis que ça n'est de toute façon pas suffisant +1 Je ne vois pas non plus quel problème cela pose réellement d'avoir des petits chevauchements de bâti et un de ces 4 on aura bien un algo qui remettra ça au propre. Par contre, les chevauchements avec les highway existants sont à corriger... -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquesthttp://openstreetmap.fr/u/christian-quest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr