r-lidar-lab / ALSroads

Road corrections and measurements from ALS data
19 stars 4 forks source link

Changement paramètres road_buffer et road_max_width #21

Closed jfbourdon closed 2 years ago

jfbourdon commented 2 years ago

Ajoute un avertissement pour capter des cas où le chemin trouvé passe par une l'extrémité des end caps, ce qui indique souvent un problème, comme par exemple que le chemin a pris un raccourci par la forêt. Ci-dessous un cas extrême qui passait sous silence avant (en vert le segment original et en rouge le segment trouvé): shortcut_road

Données pour trois cas où cet avertissement sort: https://transfert.mffp.gouv.qc.ca/?ShareToken=42213AAB5CDEAD06E495E5CD6C835A377DFE16E8

Toutefois, en voulant ajouter cet avertissement, je me suis retrouvé à jouer avec param$extraction$road_buffer et à comprendre pourquoi je trouvais la valeur deux fois plus grande que supposé. J'ai aussi fini par comprendre que l'analyse des métrique se faisait sur une distance fixe de 15 m de part et d'autre du chemin. Bref, j'ai créé param$extraction$road_max_width <- 30 pour l'extraction des métriques et divisé par 2 param$extraction$road_buffer pour que ça représente la largeur réelle du buffer ajouté au chemin.

Je crois avoir bien adapté tous les endroits où param$extraction$road_buffer était utilisé.

Ça m'amène aussi à me questionner sur la raison du +5 à la ligne suivante qui ne respecte pas strictement la valeur de param$extraction$road_buffer que l'utilisateur a choisi. https://github.com/Jean-Romain/MFFProads/blob/70ded35e9380a41d021ad3e14fb562a985c2682d/R/query_tools.R#L28

Jean-Romain commented 2 years ago

Ça m'amène aussi à me questionner sur la raison du +5 à la ligne suivante qui ne respecte pas strictement la valeur de param$extraction$road_buffer que l'utilisateur a choisi.

Je sais pas/plus mais je dirais pour avoir un petit peut plus de données et éviter des problèmes sur les bords. Notemment pour le DTM. Alors maintenant qu'il est précalculer c'est moins important mais en fait il y a une autre étape où il est calculé quand même. Je ne rentre pas dans les détails.

comprendre pourquoi je trouvais la valeur deux fois plus grande que supposé

En effet, je n'ai jamais corrigé ca.

comme par exemple que le chemin a pris un raccourci par la forêt

Ha ca c'est un problème difficile. Parce que l'output est quand même bon. Il y a bien un chemin là.

métrique se faisait sur une distance fixe de 15 m de part et d'autre du chemin. [...] Bref, j'ai créé param$extraction$road_max_width

Oui une fois qu'on sait où se trouve la route pas besoin d'analyser les 160 m. Tu as bien fait d'ajouter un param

@ilythiamorley Jean-Francois changed the buffer. In the former code when the input was e.g buffer = 160, 160 was actually the width of the polygon and it corresponded to a buffer of 160/2 = 80 around the road. It was improperly named "buffer". It is know a real buffer. The default value is 80 instead of 160. If you customized this value manually do not forget to update your code and put half of the value.

jfbourdon commented 2 years ago

Content de voir ta réaction :) Je me demandais comment tu verrais ces changements.

Et en lien avec ces changements, j'ai remarqué que la méthode utilisée pour accéder aux divers paramètres varie d'un endroit à l'autre dans le code. Y a-t-il donc une manière à privilégier entre param$extraction$road_buffer et param[["extraction"]][["road_buffer"]] ?

Jean-Romain commented 2 years ago

Je préfère param[["extraction"]][["road_buffer"]] qui est plus lisible mais param$extraction$road_buffer est plus simple à écrire car Rstudio autocomplète alors des fois je suis pas très rigoureux avec mes propres principes.

Content de voir ta réaction :) Je me demandais comment tu verrais ces changements

J'espère juste que tu as bien changé partout