Bonjour. Merci pour le travail déjà fait sur le support ; après un rapide coup d’œil, j’ai quelques retours : * le plugin pourrait-il prémâcher les tags des bâtiments du GeoJSON, par exemple en mettant directement building=yes, source=… et wall=no sur les polygones ? Il semble que, pour ces polygones, le tag type vaille 02 pour un bâtiment léger, et 01 pour les autres, mais il vaudrait sans doute mieux demander confirmation à l’Etalab ; * la création de highway=residential avec le cadastre est une bonne idée quand les voies n’existent pas déjà ; toutefois, en milieu rural, là où les données seront le plus susceptibles d’être importées dans OSM, ce sera plus souvent des chemins que des rues, donc peut-être que highway=track serait plus approprié ? Sinon, highway=road ; en plus, cela attirerait l’attention du contributeur sur ces chemins qu’il essaierait d’envoyer dans OSM sans les avoir vérifiés au préalable, puisque jOSM n’aime pas envoyer des highway=road ; * un truc qu’on perd, je trouve, ou alors je n’ai pas compris comment l’avoir : on ne peut plus connaître l’étendue d’un lieu-dit, ni son code FANTOIR d’ailleurs, avec les nouvelles données, car on perd le lien entre l’étiquette du lieu-dit et son emprise, et ces données ne contiennent pas le FANTOIR ; * une autre amélioration possible : si la relation des frontières de la commune est présente, donner la possibilité de télécharger en un clic tout ou partie des données publiées pour la commune, grâce au code INSEE présent dans la relation ; * les emprises de rivières sont importées comme waterway=riverbank, or il me semble que ce schéma est déprécié et en perte de vitesse par rapport à natural=water+water=river, qu’alors il vaudrait sans doute mieux utiliser. Sinon, mettre seulement natural=water seul ; comme ça, cela éviterait de mettre des tags erronés sur les étangs, s’ils ont les mêmes : au lieu d’avoir des tags erronés sur les étangs, on aurait des tags à préciser sur tous les polygones. Dommage que le sens d’écoulement manque dans ces données, ça aurait pu permettre un import direct d’un chemin waterway=stream/ditch/river…
Attention, je dis tout ça naïvement, sans savoir ce que ça représente comme travail de développement. Quoi qu’il en soit, déjà un bon boulot de fait ; merci Vincent et Christian pour ces avancées. Cordialement. De : Vincent Privat <vincent.pri...@gmail.com> Envoyé : mardi 3 octobre 2017 23:34 À : Discussions sur OSM en français Objet : Re: [OSM-talk-fr] Publication OpenData du cadastre Hello, Quelques compléments d'info sur JOSM. Le support du cadastre est disponible, il faut utiliser la toute dernière version stable (12921) de JOSM et la version 33690 du greffon cadastre-fr. J'ai annoncé la nouvelle version du greffon il y a quelques jours sur la liste dev-fr, et on en a parlé aussi au dernier meeting toulousain, j'ai déjà corrigé quelques soucis de jeunesse suite aux tests préliminaires des mappeurs toulousains :) Le greffon permet d'ouvrir les lots Edigéo via file/open, file/open location, ou en drag&drop, soit de l'archive tar.bz2, soit du fichier .THF. Les géométries sont automatiquement simplifiées pour éviter d'avoir des piscines avec 500 nœuds. Le souci des bâtiments coupés en 2 au milieu d'une limite de parcelle ne se pose pas, vu qu'il s'agit des géométries natives du cadastre (sauf dans les cas de bâtiments à cheval sur plusieurs planches). Actuellement sont chargés le bâti, les limites administratives, les parcelles & sections, les adresses, la voirie, et diverses autres choses (puits, pylônes, cimetières, bâtiment de culte, etc.). Tout est sourcé avec le tag habituel "cadastre-fr ... DGFiP 2017 etc.". Ne sont pas chargés: les infos de mitoyenneté (mur, fossé) parce que représentées par un nœud, et les choses qui sont bizarrement regroupées dans le cadastre telles que "terrains de sport et petits ruisseaux" (WTF?!), ou bien "parking, terrasse, surplomb", etc. Pour les curieux la correspondance entre les données du cadastre et les tags OSM se fait ici: https://github.com/openstreetmap/josm-plugins/blob/master/cadastre-fr/src/org/openstreetmap/josm/plugins/fr/cadastre/edigeo/pci/EdigeoPciReader.java#L37 https://avatars1.githubusercontent.com/u/261431?v=4&s=400 openstreetmap/josm-plugins github.com josm-plugins - Mirror of the JOSM plugin repository in Subversion Les calques chargés ainsi dans JOSM sont flaggués "envoi dissuadé". C'est à dire: JOSM va vous crier dessus si vous essayez d'envoyer ces données vers OSM, pour sensibiliser tout le monde qu'il y a un gros travail de vérification & d'intégration à mener avant de faire ça. Si je vois qu'il y a des dérives et des imports massifs sans travail préalable, je basculerai rapidement en mode "envoi interdit", ce qui bloquera complètement l'envoi direct à partir de ces calques. Il me manque à exploiter la date de dernière mise à jour (je pense à la mettre dans un tag source:date). J'attends l'API Etalab avec impatience, ça permettra à JOSM de télécharger les données du cadastre pour une zone donnée (actuellement il faut connaître le numéro de planche du cadastre). Si vous trouvez des bugs n'hésitez pas à me les remonter :) A+ Vincent Le 3 octobre 2017 à 14:47, Christian Quest <cqu...@openstreetmap.fr> a écrit : Oui, officiellement dispo depuis hier... :) Les données brutes de la DGFiP sont au format EDIGEO, format peu courant mais ouvrable avec gdal (donc QGis). Dans cette première livraison, Etalab propose une extraction des principales couches d'infos surfaciques remise au format geojson en WGS84: limites de communes, de section cadastrale, de parcelle, et l'emprise des bâtiments. Des données sont téléchargeables par département et par communes pour les geojson et par département et feuille cadastrale pour l'EDIGEO. Ces données seront mises à jour trimestriellement. Les nouveautés à venir pour les contributeurs: - la prochaine version de JOSM va pouvoir ouvrir directement les fichier EDIGEO de la DGFiP. - l'extraction du bâti de cadastre.openstreetmap.fr deviennent en partie inutiles - les script d'extraction d'adresses de cadastre.openstreetmap.fr et de BANO vont aussi pouvoir évoluer prochainement. Il y a d'autres données provenant du cadastre qui seront bientôt disponibles: - le PCI Image et les localisants de parcelles - l'historique des évolutions des parcelles (la parcelles XXX est séparée en YYY et ZZZ) Les fichiers EDIGEO permettent bien plus que ce qu'on a pu faire jusqu'à maintenant. On a par exemple les dates de création et de dernière modification des objets. On y trouve aussi des filaires portant les noms des voies pour l'habillage des plan... j'ai commencé à travailler dessus pour les rapprocher de FANTOIR, il se peut que ce type de traitement soit fait sur les données mises à disposition par Etalab en geojson. D'autres traitements sont aussi envisagés par Etalab pour améliorer les données, les lier à d'autres, etc. Ceci devrait arriver d'ici la fin de l'année. Etalab va aussi mettre en place des API pour interroger ces données, comme ça a pu être fait en mettant en place un géocodeur pour faciliter la réutilisation de la BAN. Il mes semble utile qu'on réfléchisse ensemble au meilleur moyen d'exploiter ces données et surtout de le penser dans le long terme pour les mises à jour. Pour cela, évitons de nous précipiter sur des imports à partir de ces données pour l'instant très brutes. Ces données font parti du "Service Public de la Donnée de Référence" dont le slogan est "Des données sur lesquelles vous pouvez compter"... c'est donc là pour longtemps ;) Le 3 octobre 2017 à 14:20, David Marchal <pene...@live.fr> a écrit : Cher tous, Je viens de voir que le cadastre, en tout cas certaines informations, viennent d’être publiées en OpenData, et en vectoriel, s’il vous plaît : https://www.nextinpact.com/brief/le-cadastre-est-accessible-en-open-data-329.htm Sans doute ce que Christian Quest disait être dans les tuyaux. D’emblée, je vois l’utilisation du GeoJSON pour l’importation du bâti, mais on doit pouvoir en tirer beaucoup plus. Merci à la DGFiP et à Etalab pour ça, ça devrait nous aider. Cordialement. _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France _______________________________________________ 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
