Défis MapRoulette en forêt (limites forestières)

Salut à tous !

Suite à l’approbation, il y a quelques mois, des attributs boundary=forest (limite de forêt) et boundary=forest_compartment (parcelle forestière), les limites des parcelles et des forêts sont à représenter par des entités (polygone ou relation type=boundary) différentes des entités landuse/natural, qui représentent, elles, l’usage du sol ou sa couverture naturelle. L’avantage principal, c’est que les étangs, clairières, pierriers… qui ne sont pas landuse=forest/natural=wood, et qui étaient donc exclus des forêts/parcelles auparavant, peuvent maintenant être représentés pour ce qu’ils sont, c’est-à-dire des éléments qui font partie de la forêt ou de la parcelle, même s’ils ne sont pas boisés.

J’ai préparé deux défis MapRoulette pour nettoyer les données en place, parce qu’on a un peu de tout en France, avec deux archétypes qui sont :

  • des polygones landuse=forest+name=250 pour forcer le rendu principal à afficher le numéro de parcelle ;
  • des polygones landuse=forest+name=Forêt domaniale de Pétaouchnok qui excluent les prairies, pierriers, étangs… qui font pourtant partie de la domaniale, ou qui au contraire les incluent, en affirmant donc que la prairie, le pierrier, l’étang… sont boisés.

J’ai donc préparé deux défis :

  1. un pour corriger les parcelles forestières ;
  2. un pour les forêts publiques (domaniales et communales).

Pour mémoire, les informations sur les forêts publiques (forêts et parcellaire) sont publiées par l’ONF.

J’ai laissé les instructions nécessaires dans les défis, mais libre à vous de demander ici des informations complémentaires si des points vous semblent obscurs ou si vous rencontrez des entités sur lesquelles vous souhaiteriez un deuxième avis.

Amusez-vous bien !

2 Likes

Salut j’ai bien envie de participer. Juste une question est-ce que c’est purement une mise à jour « technique » ou doit on confirmer par une visite terrain ?

Salut, @Djiril !

C’est purement technique ; vérifier sur le terrain n’est pas nécessaire. Le but est de mettre à jour la modélisation elle-même, et une vérification terrain, bien que toujours utile, serait un boulot énorme et hors de propos.

Ok c’est bien ce que je pensais. Merci !
Faire de la forêt ça me changera des mises à jour de commerce à Paris :wink:

Bon j’ai essayé de faire le bon élève :slight_smile:
Je me suis dit aller, allons en Bretagne du coup je suis allé voir ici : FR:Sources de données potentielles/France - OpenStreetMap Wiki puis ici : Catalogue GeoBretagne - GeoBretagne et enfin la : Catalogue GeoBretagne - GeoBretagne
J’ai suivi le tuto ici pour visualiser des WMS avec QGIS : Utilisation de données WMS(QGIS3) — QGIS Tutorials and Tips
Mais les couches ne se chargent pas quand je clique sur « Connexion »…



J’ai peut être raté un truc ou a moins que le WMS ne soit plus dispo.
J’ai essayé avec uMap sans succès non plus.

Du coup soit je duplique les zones sans vérifier mais bon c’est pas top non ?

Bonne soirée !

Djiril (débutant en géomatique)

Juste avant de me coucher j’ai joué avec ça : Visualiseur - GeoBretagne
Mais je ne trouve pas la bonne couche pour les forêts publiques

Utilise les couches de l’ONF pour les forêts publiques (http://ws.carmencarto.fr/WMS/105/ONF_Forets?), ça ira mieux. Logiquement, si GeoBretagne les a, ils doivent les tirer de l’ONF, alors autant aller à la source, et tu peux les ajouter dans JOSM (Help/Preferences/Imagery – JOSM).

Je crois que la Bretagne ne veut pas de moi :frowning:

Super, c’est une bonne nouvelle :slight_smile:
Par contre, je n’ai pas vu où a été faire l’approbation : ça se passe où ?

@Penegal j’ai fait un premier essai sur une parcelle, merci de regarder si c’est bon…

1 Like

en allant sur la page wiki, tu as le statut approved. Quand tu cliques dessus, cela t’amènes à la page https://wiki.openstreetmap.org/wiki/Proposed_features/boundary%3Dforest(_compartment)relations(v3)

@Djiril ton URL dans la liste des fournisseurs actifs est étrange ; pour l’emprise des forêts, j’ai ceci : wms:http://ws.carmencarto.fr/WMS/105/ONF_Forets?language=fre&FORMAT=image/png&TRANSPARENT=TRUE&VERSION=1.3.0&SERVICE=WMS&REQUEST=GetMap&LAYERS=FOR_PUBL_FR&STYLES=&CRS={proj}&WIDTH={width}&HEIGHT={height}&BBOX={bbox} Regarde : le paramètre FORMAT demande bien du PNG chez moi ; celui de l’URL de ta capture d’écran est réglé à null. Le serveur te répond qu’il ne supporte pas ce format ; rien d’étonnant… :wink:

Pour info, si tu veux le calque des parcelles (limites et référence ; attention, la référence de la parcelle n’est pas forcément un numéro, ça peut être une lettre), le voici : wms:http://ws.carmencarto.fr/WMS/105/ONF_Forets?language=fre&FORMAT=image/png&TRANSPARENT=TRUE&VERSION=1.3.0&SERVICE=WMS&REQUEST=GetMap&LAYERS=PARC_PUBL_FR&STYLES=&CRS={proj}&WIDTH={width}&HEIGHT={height}&BBOX={bbox}

Pour ton essai : le rendu dans JOSM n’aime pas trop ton essai. Je pense que l’entité landuse=forest ne devrait pas être l’unique membre de la relation boundary=forest_compartment : ça maintient un lien logique entre le peuplement (landuse=forest) et la parcelle, ce qu’il faut éviter. Je pense que, si l’entité landuse=forest est un polygone et pas une relation, il faut tracer un nouveau polygone, et faire de ce nouveau polygone l’entité boundary=forest_compartment. Tu vois ce que je veux dire ?

Si tu dois faire une relation, n’oublie pas de mettre les limites de la parcelle en rôle outer dans la relation boundary=forest_compartment ; ça, je suis sûr que c’est un problème ! :sweat_smile:

Tu peux également créer simplement un polygone boundary=forest_compartment : une relation type=boundary avec un seul membre outer alourdi la structure de données, et n’apporte rien, sauf si les limites de la zone sont déjà des chemins que tu peux utiliser comme membres outer. Par ailleurs, utiliser boundary=* sur de simples polygones est très répandu, alors ne te casse pas trop la nénette avec des relations si un polygone simple est plus… simple :grin:

Merci pour ces explications mais bon la je crois que ça dépense largement mes compétences…
Je vais continuer mon (auto) formation, et je reviens dans quelques mois, années :wink:

Peut-être que ceci te parlera mieux :

Comme tu peux le voir, aucune de ces entités n’a de lien direct avec les landuse=forest qu’elles recouvrent. S’agissant de relation, note les rôles outer de leurs membres.

1 Like

Ok merci Penegal, je vais regarder ça et approfondir toutes ces notions :wink:

C’est chouette que le schéma de tag ait été approuvé, mais pour motiver les contributeurs, il serait bon que la question du rendu des parcelles forestières avance.
Je me suis permis de relancer l’issue correspondante sur Github (c’est mon compte « pro » puisque je travaille dans ce domaine :wink: ):

Pour ceux qui ont un compte Github, et qui s’intéressent à la thématique, n’hésitez pas à appuyer ce besoin !

1 Like

Sinon, je viens de faire un premier test avec une petite Forêt Domaniale de 19 parcelles :

Détail de ma procédure :

  • chargement de la couche SHP des parcelles issue de Carmen dans QGis
  • export GeoJson en WGS84 des parcelles filtrées sur la Forêt Domaniale en question
  • chargement de ce GeoJson dans JOSM
  • adaptation des tags pour les parcelles : ccod_prf devient ref + ajout de type=boundary et boundary=forest_compartment + suppression des autres tags inutiles (attention, au début j’avais aussi mis les tags sur les nœuds : ne mettre les tags que sur les ways)
  • import dans OSM

Mais je me pose la question de la mise en topologie avec les nœuds existants dans OSM : je ne pense pas qu’il faille modifier les nœuds de ces parcelles, qui doivent correspondre aux noeuds source, mais j’ai peur que cela fasse des doublons, non ?

Pour le boundary=forest, je pense ajouter une relation, mais plusieurs options sont possibles :

  • import du SHP du contour de la Forêt depuis les données OpenData ONF
  • mise en relation de la sélection des parcelles de cette forêt (mais du coup, on n’aurait pas le contour mais toutes les parcelles membres)
  • utilisation d’un outil comme « ComComMaker » (https://comcommaker.openstreetmap.fr) pour recréer la frontière d’après une sélection de parcelles, mais cela nécessite d’adapter ComComMaker, car sauf erreur, ce n’est pas possible actuellement avec des boundary=forest_compartment ( ? ).

Des conseils ?

Attention, les données ONF ne sont pas toujours d’une précision extrême, par manque de temps et de matériel de levée GPS précis (souvent, on fait la levée GPS avec un smartphone, dont la précision n’est pas idéale sous les arbres ou dans les vallées encaissées). Un exemple, avec un modèle numérique de terrain Lidar et les parcelles ONF publiées en vert :

Ces données sont améliorées au fil de l’eau, mais l’ONF n’a plus le personnel nécessaire pour remettre à plat tout ça ; ici, on voit certaines limites de parcelles, en bordure de l’image, bien calées sur les chemins, mais l’une d’entre elles, en plein milieu de l’image, annoncée comme longeant une route, est en réalité sur la route comme les autres, comme tout le monde s’en sera douté. La route fait bien limite dans ce cas aussi, même si les données ONF annoncent autre chose — je suis sûr de moi sur ce cas, car je connais personnellement ce coin.

S’appuyer sur une route, un ruisseau, une limite de commune… située à trois mètres n’est donc pas un problème : si la limite de parcelle annoncée par l’ONF longe la route sur 200 m avec 3 m de distance entre les deux, c’est que la route fait limite. C’est valable pour tout élément linéaire : si l’ONF annonce que la limite de forêt/parcelle suit cet élément linéaire avec un léger décalage, il est hautement probable que cet élément soit la limite, auquel cas il faut s’aligner dessus.

C’est pour ça que, pour ma part, si des chemins, sentiers, layons, cours d’eau… sont déjà présents dans OSM, je vais utiliser des relations type=boundary au lieu de polygones simples, et utiliser ces éléments déjà présents en membres outer de ces relations, pour éviter de créer des doublons de ces chemins dans OSM par un simple import. J’utilise le fond de carte WMS de l’ONF dans JOSM et je trace mes parcelles à la main, une par une ; comme ça, je suis sûr de voir toutes les parcelles une par une pour avoir l’occasion de les recaler sur les éléments préexistants dans OSM ou avec de l’imagerie satellite. C’est un travail de titan, mais un import en gros ou semi-automatisé pourrait facilement passer à côté de ce genre de cas, ce qui serait dommage à mon sens, car on répéterait les erreurs d’autres alors qu’on a l’occasion de les corriger. Je favorise, pour ma part, la qualité à la quantité.

Inconnu au bataillon. ComComMaker ? Ça vit où, ça mange quoi ? :sweat_smile:

Attention, Sylvain : si toute la forêt est gérée par un unique gestionnaire, ce qui est le cas en toute logique (surtout en forêt publique française :wink:), l’attribut operator est à appliquer sur l’objet boundary=forest, pas sur les objets boundary=forest_compartment, car ça fait plein de petits doublons sinon. C’est marqué sur la page Tag:boundary=forest_compartment dans sa version issue du vote :

As a delimited forest is managed as a whole, it is not useful to tag each compartment belonging to a delimited forest with tags applying to the whole delimited forest; such tags should be applied on the enclosing boundary=forest entity. For instance, the operator of the delimited forest is most probably unique, so an operator tag should not be applied on each compartment, only on the boundary=forest entity.

Sinon, tu peux voir le problème de décalage dont je te parlais sur cette parcelle : selon toute probabilité, la limite NO de la parcelle est le sentier : les limites de parcelle sont censées être débroussaillées régulièrement, particulièrement en domaniale, ce qui est bien plus accueillant pour les piétons… qui vont donc logiquement suivre la limite de parcelle.

Pareil pour les autres limites, en fait : à défaut d’utiliser les chemins existants dans des relations, il faudrait au moins fusionner les points des limites de parcelle avec ces chemins, pour maintenir et garantir l’alignement.

Bonne promenade en forêt publique ! :rofl:

Oh, au fait :

Ouh, collègue ? Moi, c’est DT GE !

1 Like