On n'a pas fait comme ça du tout pour les communes ou les cantons : l'automatisme est en fait plus que douteux pour ce genre de projet sachant qu'on a des imprécisions évidentes et un gros travail de conflation à faire pour recoller à l'existant. Alors non je n'ai jamais parlé d'import mais bien d'intégration
Les données de l'Insee seront là juste à titre de comparaison pour fire du rapprochement et juger de la qualité relative finale Mais évidemment pour faciliter ces rapprochements les identifiants de référence Insee doivent être intégrés (ref:FR:INSEE=*, seulement si on veut éviter la confusion avec les codes INSEE communaux actuellement dans ref:INSEE, à moins que le format des codes IRIS reprenne le format du code INSEE communal et qu'on ne code le numéro d'IRIS de la commune après, mais pas isolément ; cependant on risque d'avoir Osmose trouvant étrange ces codes INSEE "communaux", et il vaut peut-être mieux utiliser un séparateur "-" entre les deux et non pas ":" discuté déjà pour le versionnement avec des dates; toutefois cette référence porte sur des objets frontière qui ne sont pas de même type et qu'on ne peut pas confondre). De plus je ne demande absolument pas qu'on y ajoute des "admin_centre" (aucun sens ici) ni même des noeuds membres "label" inutile. En effet, même si de nombreux IRIS ont des noms qu'on peut indiquer dans leurs relation avec "name=*" et qu'on n'a pas besoin de traduire, il n'est pas nécessaire cependant d'afficher des noms d'IRIS sur les rendus carto, ce nom n'apparaitra utile que sur des interrogations de données de la carte sur un point ou une frontière sélectionnée; puisque ce nom ne devrait pas être visible sur un rendo carto, on ne //devrait// pas avoir besoin d'indiquer un placement avec un noeud "label" (qui n'est de toute façon utile QUE pour ses coordonnées suggérées, et jamais pour son/ses noms contenus dans le noeud) ; cependant rien ne devrait l'empêcher si ça facilité l'usage, seul "admin_centre" ne devrait pas être utilisé du tout (ce n'est pas une frontière administrative, juste une frontière statistique). Ces noeuds cependant ne devrait pas être créés exprès, on ne devrait prendre que les noeuds place=* existants s'il correspondent correctement par leur nom actuel et sont bien dans la surface, sinon ils seront plus une pollution inutile (i on choisit un noeud place, il ne faut PAS en changer le nom même s'il est un peu différent du nom de l'IRIS (d'ailleurs la remarque s'applique également aux noeuds "place=*" utilisés en "admin_centre" des communes qui ne devraient JAMAIS non plus être modifié pour correspondre au nom de la relation pour la collectivité communale (et surtout pas si c'est une "commune nouvelle", la toponymie fine des "place=*" n'a rien à voir avec les noms des entités ou collectivités administratives qui les contient et c'est suffisant de nommer ces entités dans leur relation et pour placer un label, avec ou sans icone, si on n'affiche pas le nom le long des frontières). Et de toute façon hors de question d'automatiser un import sans avoir fait un essai manuel avant. Je ne pense même pas que l'uatomatisation soit nécessaire (tout ce qu'on peut avoir besoin éventuellement c'est un tableau d'avancement, mais on n'a pas forcément besoin d'un outil pour ça, c'est facile d'en créer un sur le wiki (une page par département, certains départements seront vite traités, on n'est pas obligé de commencer par les mettre tous. Et ce sera nettement plus facile à faire et moins long que les cantons qui nous a posé des tas de soucis pour interprêter les arrêtés et rechercher les rues mais qui déjà nous donne aussi de bonnes indications (avec les autres frontières administratives communales, ou d'arrondissements ou quartiers et sous-quartiers) pour recadrer les IRIS. On peut définir une règle de conflation avec des écarts ne dépassant pas les 20 mètres environ, sinon on reprend le tracé donné par l'Insee tel quel (à moins que d'évidence il suivant une rue mais pas tous ses virages et vient découper des bâtiments en deux dans des coins "riquiquis", mais on ne devrait cependant pas avoir à coller ces traits sur le tracé des bâtiments mais plutôt sur le tracé des parcelles cadastrales qu'on n'importera pas non plus directement car il n'y a aucune raison qu'une commune a découpé ses IRIS sur autre chose que les limites cadastrales de propriétés, autre que le fait qu'une propriété a été depuis subdivisée ou des morceaux regroupés avec d'autres voisins pour construire un même bâtiment avec une seule adresse occupée c'est un cas où l'INSEE doit déterminer la parcelle la plus pertinente pour centrer l'occupant dans l'IRIS, mais on n'a de toute façon pas le détail à ce niveau parcellaire dans les statistiques, les IRIS peuvent donc garder une certaine imprécision tant que cela ne joue pas trop fortement sur les critères de secret statistique et de protection des données personnelles des occupants, le minimum étant tout de même que les occupants soient dans un IRIS appartenant à la bonne subdivision administrative ou électorale la plus fine, le tracé des IRIS peut donc ignorer certains détails physiques, naturels ou architecturaux). Le 4 janvier 2018 à 17:34, marc marc <marc_marc_...@hotmail.com> a écrit : > Le 04. 01. 18 à 15:00, Philippe Verdy a écrit : > >> J'aimerai connaître : > >> - l'outil que tu vas utiliser pour rapprocher les limites libre > >> imprécise de l'insee des frontières supposée exacte d'osm > > > la conflation "à vue de nez" > > C'est possible pour faire le premier exemple. > Mais c'est déraisonnable d'envisager du manuel à grand échelle. > Tous les imports/intégrations doivent avoir une partie pour utiliser > l'existant "en automatique" et pas manuellement pour chaque nœud. > Tu devrais te rapprocher de Vincent pour voir comment il a fait > le rapprochement qu'il a publié sur gouv.fr > Une première étape utile serrait donc d'avoir cette version > partiellement intégrée à jour. > _______________________________________________ > 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
