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
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
