zoukankan      html  css  js  c++  java
  • [*论文] 一时兴趣的产出(新型TLS布站策略)被TGRS录用

    关键词:研究历程 TLS布站策略 心得体会 作者:李二 日期:21/08/2020 - 22/08/2020

    历时2年零1个月,从萌发想法到文章录用,我觉得这个工作还是有些价值的。尤其值得一说的是,整个历程对于那些因个人一时兴趣/冲动而展开某项研究的学生来说,是很有参考价值的,希望各位看官能耐心看完。

    论文题目是:An Iterative-mode Scan Design of Terrestrial Laser Scanning in Forests for Minimizing Occlusion Effects

    1. 研究的缘起

    1.1. 简要背景

    为了看官能看懂这篇博客到底在讲述个什么工作,我先简要介绍一下背景吧。 
    

    当前地基激光雷达(TLS)逐渐成为了森林调查的重要工具,用于树高、胸径、干曲线、生物量的估算,甚至用于叶面积指数、叶面积体密度等生理参数的估算。

    而其中存在的一个关键问题是:主干与主干之间、树冠元素(树枝与叶片)与树冠元素之间,两个层次的遮挡效应,导致扫描不完整甚至缺失严重,最终造成参数估算的不确定性

    我这项工作主要关心的是主干与主干之间的遮挡问题,而降低这一遮挡效应的方式就是布设多个测站。但关键来了,布设多少个TLS扫描站,分别布设在哪里,决定了遮挡问题能否有效缓解,这就是所谓的TLS布站策略

    沿某一视线方向,森林中距视点近的树干遮挡住距视点远的树干
    沿某一视线方向,森林中距视点近的树干遮挡住距视点远的树干

    1.2. 想法的激发

    这项工作的研究兴趣起始于2018年7月份的一次小组会,当时我还在法国,远程听着国内组内万鹏师兄介绍他的近期工作--评估单站TLS扫描中的遮挡效应对于树木干曲线估算的影响

    我清楚地记得当时我问过如下两个问题:

    • 既然数据获取完成之后才评估遮挡效应的影响,为什么不想办法在数据获取时尽量降低遮挡效应呢?
    • 既然现在大家意识到了遮挡效应问题,那么当前是怎么去解决的呢?
    单站TLS扫描时存在的遮挡问题:注意图中粉色扇形较小或缺失的部分圆圈
    单站TLS扫描时存在的遮挡问题:注意图中粉色扇形较小或缺失的部分圆圈

    有点记不清楚万鹏师兄当时具体是怎么答复的了,我印象中可能如下:

    • 单站TLS的优势是高效和低成本,一般单站TLS被置于森林样地中心,大家默认是合理且结果最好的。采用单站TLS来降低遮挡效应的意义不大,一般是多站TLS。
    • 目前几乎没有专门的研究去解决最小化遮挡效应问题(也可能受当时个人知识库所限)。
    张吴明老师说他2-3年前与陈一铭师兄聊过这个事情,但是后来因为其他事情耽搁了,也没做,希望我能做起来。
    
    • 一方面,我觉得这个事情挺有意思,算是一个优化问题,有潜力以后真的用到;
    • 另一方面,彼时我对TLS的数据获取与处理了解尚浅,也希望通过这个机会加深了解。

    最终,我决定开始这个一时兴趣和冲动驱动的研究。

    2. 研究的历程

    其实在这2年的时间中,并非全部精力投入其中。整个研究主要集中在三段时间,分别是研究算法(2018.7-11月)、论文写作与算法改进(2019.4-7月)、投稿与修改(2019.8-2020.7),当然中间还穿插自己的其他工作与博士毕业事宜。其实我想表达的是,工作并非一蹴而就,而是不断有新想法、新讨论,进而不断优化和改进的。

    2.1. 研究价值与意义

    在决定执行这项工作之后,我先去查了查大家怎么看到这个事情(也就是研究价值与意义)以及国内外的研究现状,确实发现大家基本都意识到森林调查中的遮挡问题了:

    • 但是要么是大量随机测试怎么布站得到的模拟结果更好;
    • 要么是已经获取数据之后如何想办法校正遮挡效应。

    在这两年的研究中,我也注意到国际上有多篇相关论文刊出,说明确实到了该好好思考以及探索如何解决遮挡问题的时候了。

    尤其是ISPRS P&RS上的International benchmarking of terrestrial laser scanning approaches for forest inventories这篇明确了TLS布站策略的研究价值:

    Future development must address the redundant yet incomplete point clouds of forest sample plots and recognize trees more accurately and efficiently.

    2.2 模型建立

    其实一句话可以表述传统布站方式的问题,那就是只见树木不见森林。因为不能提前获知树木的位置,所以布站就比较主观了。

    而我一直在做无人机遥感研究,因此知道,树木的位置可以通过无人机SfM点云比较准确地获取,这样相当于无人机可以辅助地面测量,算是将UAV和LiDAR结合的一个点。最终形成既见树木,又见森林

    我意识到其实主干与主干之间的遮挡其实可以简化为二维平面上圆圈与圆圈之间的遮挡,有了圆圈的位置和大小作为基础图,进而通过通视分析,就能知道哪里布站最优,同时也要考虑如何使得扫描站之间冗余小互补性大,这是本算法的基本出发点。

    当然具体的算法并非这么简单,也是花了很长时间很大精力反复修改最终确定的,如下图所示。
    
    算法流程图
    算法流程图

    2.3. 代码编写

    而在具体执行通视分析时,则根据导师的提示,选择了一种高效计算策略。不是遍历所有的空间点,而是仅根据树木所在位置反向计算通视,有点光线追踪的味道。

    高效通视分析计算与全局通视图生成
    高效通视分析计算与全局通视图生成

    这次代码算是我有史以来写的最长最系统的一次了(当然,比不上专门软件开发了)。所以画了个代码结构图,以备后续修改有章法、知道在哪里改。

    代码结构图
    代码结构图

    另外值得一提的是,我们常常说MATLAB比较慢,其实我感觉最重要的是没有把优化加速做到很好,这个代码中我是想尽办法进行加速了,比如向量化编程、影像降低冗余、cellfun等等。其实刚开始写的时候已经注意了,但是最后运行时仍然需要几个小时,才专门花了很大力气来加速的。

    当时代码加速之后的心情
    当时代码加速之后的心情

    2.4. 算法测试与改进

    算法部分花了最多时间的就是在这里。自己生成了大量模拟场景,不断测试,发现可能存在什么算法上尚未考虑到的问题。

    其实最开始的算法并非如上面的流程图那般。 经过与导师、同学、同事以及审稿人的多次讨论才最终定型。这里我想说的是,我们做事情不能图快,太快则会有意无意忽略很多东西,研究的可靠性是要打些折扣的

    3. 论文撰写、投稿、修改

    3.1. 会议报告

    我要特别感谢我的导师阎广建老师和穆西晗老师给提供的经费与机会,让我有幸参加了海南三亚的第一届空间科学会议(口头报告)以及Austria Wien的欧洲地学联合大会(EGU Assembly)(海报报告)。

    在这两次会议上,这项小工作得到了一些小同行的关注,尤其是EGU的session评委对于这个工作质量的评价比较高。 国际知名专家芬兰FGI的梁欣廉研究员更是仔细询问了研究细节。这些无疑给了我极大的鼓励,我默念一定要把这个工作做细好。

    3.2. 论文写作

    这篇论文的写作有点意思,当时我的师兄金秀良博士说,写文章尽量在一周之内把初稿写完,后续再慢慢修改。我做事向来比较慢,但是也听从金师兄的建议集中精力在不到两周的时间内将初稿写完的。

    现在想来,在研究工作已经完成地差不多的情况下,这么做是有些道理的。 当然,文章后续也要经过反复地修改,因为我当时觉得这个工作纯属个人兴趣,整体改了4遍就投了。

    有关论文写作的事情,各位看官如有兴趣,可以移步我的博客博士论文写作总结系列。

    3.3. 投稿与被拒

    我当时期望靠着几篇top期刊文章找教职的,所以想着先投ISPRS P&RS试试,毕竟话题也比较适合。在投稿之前,穆老师跟我说,目前这篇文章最大的弱点是没有实测数据,仅有模拟数据,如果这一点被审稿人指出来,估计就悬了。

    经过3个多月的审稿,果不其然,被拒了。 拒稿原因最主要是的审稿人认为没有实测数据,质疑算法的表现,同时编辑和另外一个审稿人觉得文章的展示方式尚需提高。但是审稿人和编辑均觉得该类研究是重要的,期望我能用实测数据做下去。

    由于我确实也没时间精力去弄实测数据,于是想着改好之后转投吧。

    3.4. 投稿与修改

    2019.12月回国之后,我终于在1月份修改完成,转投了IEEE TGRS。大约两月有余,收到了审稿意见--大修。还算有点小兴奋,毕竟没有直接拒稿。 但是当我看审稿意见的时候,尤其是reviewer 2#的意见,我直接慌了。这位专家密密麻麻写了5页的comments (word中11号字,单倍行距),这可咋改呀。

    看到这么多意见,我确实有点懒惰了,先搁置着,慢慢修改吧,反正给了3个月。 另外,当时我一方面在找工作,一方面在写毕业论文,难有精力抽出来进行修改。 直到4月底,论文预答辩结束,我才真正拿出时间来去仔细看和尝试修改。

    现在想来,这样做反而是好的。 一方面,刚拿到审稿意见时,往往有逆反心理且心情躁动,有的可能觉得没必要改,有的觉得审稿人误解了,有的觉得按照这么改下去基本相当于重做了;另一方面,难以踏下心来,安静思考。

    在我仔细看了审稿意见之后,发现两个审稿人态度都很积极,尤其是审稿人2#提出了非常多中肯切合实际且很有价值的建议。我把审稿人的超长意见分成一条一条地,逐个思考怎么修改合适,写下自己的想法,然后与穆老师讨论,反复讨论了大约三次,最终明确了具体的修改思路。值得一提的是,往往我和穆老师的意见并不一致,是穆老师的坚持与详细解释,我才最终做下去(我是很有惰性的)。

    非常多的好建议,仅摘录几条:

    • 采用国际上的benchmarking 数据进行测试,这样文章的价值性和算法性能参考更好一些;
    • 与森林调查的常用参数保持一致,计算树高、胸径、干曲线;
    • 算法要评估增加一站的贡献量,贡献很小时就别增加了;
    • 方法部分的结构调整为****;
    • 实际布设时肯定有误差,要考虑这个位置误差有多大的影响,可以模拟讨论;

    这些其实都是很大量的工作,除了introduction部分仅有较少修改外,剩余全文的数据、算法、结果与讨论基本相当于全部重写了。 当时改进算法与数据处理部分,因为疫情尚在家中,效率并不高。而论文的重写则因为返回学校一段时间的缘故,写的很快,自我感觉也不错。 后续穆老师又来回修改2次,最终延期一个月提交。

    我想特别说的是:一定要重视审稿人的每条建议,回复要不厌其烦。 我之前的一篇ISPRS P&RS文章有5个审稿人,回复信写了100多页,这次两个审稿人写了整整50页。 并不是说页数多么重要,而要让审稿人看到,我们是如何吸取他们的建议,仔细修改我们的文章的。

    审稿人最后回复道:Thank you for your detailed reply. The design of this study and the algorithm are innovative, and the manuscript improves a lot in this version. You have done lots of work, especially changing to a totally different dataset to match with a influential study in this field. The algorithm and the conclusions are inspiring. Thank you for discussing with me and taking my suggestions.

    论文未经再次修改,直接被录用了,一部分是因为修改认真,另一部分也是运气了。我非常非常感谢这位审稿人,他/她花了很大精力来思考怎么样提高这项工作,是一位了不起的科学家。

    4. 后记

    这完全是一个兴趣驱动的工作,最早想着短平快,但是后来慢慢发现,任何工作如果想做好、做踏实,短平快是不行的,得有时间积淀和反复思考讨论修改才可以。希望这项工作的研究经历对于各位看官也能有所启发,那我也就不胜荣幸了。

    这是我开始写博客后第一篇被录用的文章,后续每发表一篇也会适当总结一下。

  • 相关阅读:
    后端——框架——视图层框架——spring_mvc——《官网》阅读笔记——第一章节26(过滤器,ShallowEtagHeaderFilter)
    后端——框架——视图层框架——spring_mvc——《官网》阅读笔记——第一章节27(过滤器,CorsFilter)
    后端——框架——视图层框架——spring_mvc——《官网》阅读笔记——第一章节28(过滤器,其他Filter)
    后端——框架——视图层框架——spring_mvc——《官网》阅读笔记——第一章节29(注解,Controller类注解)
    后端——框架——视图层框架——spring_mvc——《官网》阅读笔记——第一章节30(注解,Handler方法注解)
    任务日历关联(Project)
    新建日历(Project)
    例外日期(Project)
    自定义日历(Project)
    日历的种类(Project)
  • 原文地址:https://www.cnblogs.com/ludwig1860/p/13544966.html
Copyright © 2011-2022 走看看