[OSM-talk-fr] Publication OpenData du cadastre

[Christian Quest]

Le 04/10/2017 à 16:30, David Marchal a écrit :

> 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 ;

C'est bien ça et toute la doc concernant les fichiers EDIGEO est disponible:

https://www.data.gouv.fr/s/resources/plan-cadastral-informatise/20170906-150737/standard_edigeo_2013.pdf

> * 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 ;

A mon avis ces géométries (couche zoncommuni) ne devraient être 
qu'indicatives et utilisées par des bot de comparaison. Elle sont 
parfois incohérentes (un seul linestring pour plusieurs rues). A mettre 
de côté pour l'instant à mon avis.

> * 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 ;

Il y a une couche correspondant aux emprises des lieux-dits, par contre, 
tout comme les filaires de voirie, il n'y a pas de lien avec FANTOIR... 
là aussi, un retraitement intermédiaire serait plus utile qu'un accès 
direct depuis JOSM.


> * 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 ;

Dans quel but ? Pour affichage ou pour retravailler dessus et upload ?
Vu le volume je crains qu'on fasse de l'import sans réel affinage des 
données.


> * 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…

Là aussi c'est de l'habillage et pas forcément très à jour. On avait 
d'ailleurs suspendu la génération de cette couche sur cadastre.gouv.fr 
vu la mauvaise qualité par rapport à ce qu'on constate sur le terrain.

> 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.
>

Il me semble utile d'expérimenter et d'explorer ces données, mais d'être 
très prudent dans un premier temps sur la ré-utilisation qu'on peut en 
faire.

Il est urgent d'attendre un peu, surtout que pas mal d'autres choses 
devraient arriver à courte échéance et qui rendra sûrement 
l'exploitation des EDIGEO moins intéressante.

-- 
Christian Quest - OpenStreetMap France