A Lightweight, Robust Exploitation System for Temporal Stacks of UAS Data: Use Case for Forward-Deployed Military or Emergency Responders

Round 1

Reviewer 1 Report

Overall very interesting article; thanks for contributing. Here are my recommendedations: 

Line 34 & 36 use 20M & 18M (to represent Mega-pixels); however, on line 63, you use MP. Recommend using MP throughout. 

line 77 - (115 MB vs 25MB). be consistent with the use of a space or no space between measurement and unit of measurement. 

Line 108-110 - "image scale was set...leading to a very similar output". Was accuracy affected by this change?  

Line 127 - 128 -- "all scenes appeared...in absolute space." What was your GCP error? Less than GSD? Pix4D provides this as part of its report.

Line 151 - Do the changes that occur with longitude from the equator to the poles have any impact the accuracy of your equation? Did you consider using UTM instead of long. & latitude? 

Line 214 - Figure 6 - y axis mentioned twice. I believe your scenes should be the x-axis

line 219 - confusing- "confidence is use"

Line 252 - awkward - "As organizations repeatedly to collect"

Author Response

Response to Reviewer 1

We would like to thank the reviewer for careful and thorough reading of this manuscript and for the thoughtful comments and constructive suggestions, which have helped to improve the quality of this manuscript. Our response follows in red.

Thank you again for your assistance.

~Andrew, Yu-Hsi, Kevin and Rich

Response to Reviewer 1 Comments

Overall very interesting article; thanks for contributing. Here are my recommendations:

Point 1: Line 34 & 36 use 20M & 18M (to represent Mega-pixels); however, on line 63, you use MP. Recommend using MP throughout.

Response 1: We agree with your recommendation and have changed the text accordingly.

Point 2: line 77 - (115 MB vs 25MB). be consistent with the use of a space or no space between measurement and unit of measurement.

Response 2:  We agree with your recommendation and have changed the text accordingly to no space

Point 3: Line 108-110 - "image scale was set...leading to a very similar output". Was accuracy affected by this change?  

Response 3: Accuracy was not significantly affected by using ½ image scale because there was a high degree of overlap in the flights.

Point 4: Line 127 - 128 -- "all scenes appeared...in absolute space." What was your GCP error? Less than GSD? Pix4D provides this as part of its report.

Response 4:  GCP error on average was 3.8cm, and the average GSD was 1.41cm

Point 5: Line 151 - Do the changes that occur with longitude from the equator to the poles have any impact the accuracy of your equation? Did you consider using UTM instead of long. & latitude?

Response 5: There may be some difference due to use of a geographic coordinate system instead of a UTM coordinate system. However, voxelization is a largely aggregative function that in nature creates a case of the modifiable areal unit problem (MAUP). However, the system is geared for quick visualization and rendering of point clouds, thus although there may be error introduced from voxelization the tool provides a method to quickly render scenes and to reach back into the original UTM data for further analysis in noteworthy voxel regions.

Point 6: Line 214 - Figure 6 - y axis mentioned twice. I believe your scenes should be the x-axis

Response 6: We agree with your recommendation and have changed the text accordingly.

Point 7: line 219 - confusing- "confidence is use"

Response 7: We agree and have changed the syntax to make sense.

Point 8: Line 252 - awkward - "As organizations repeatedly to collect"

Response 8: We agree with your recommendation and have modified the text.

Author Response File: Author Response.docx

Reviewer 2 Report

Figure 1 need to be georeferenced and presented by location, Figure 2 is confusing and need to be improved model of presentation and explanation of errors.

The authors use Cesuim.js which is a large library and therefore not good fit for slow connections. They did not mention other web based point cloud visualization solutions like Potree.

There is lack of experimental results that proves the method provides good visualization in slow connection environment. 

The hardware configuration of testing environment is also missing.

Author Response

Response to Reviewer 2

We would like to thank the reviewer for careful and thorough reading of this manuscript and for the thoughtful comments and constructive suggestions, which have helped to improve the quality of this manuscript. Our response follows in red.

Thank you again for your assistance.

~Andrew, Yu-Hsi, Kevin and Rich

Response to Reviewer 2 Comments

Point 1: Figure 1 need to be georeferenced and presented by location, Figure 2 is confusing and need to be improved model of presentation and explanation of errors.

Response 1: Because the data was collected over a private residential building we choose not to identify the specific location. We have amended the caption for Figure 1 to address this. The caption for Figure 2 was significantly lengthened to address the reviewers comments.

Point 2: The authors use Cesuim.js which is a large library and therefore not good fit for slow connections. They did not mention other web based point cloud visualization solutions like Potree.

Response 2:  While we agree that Cesium is a large library,  it can be tailored to run with minimal library resources and even offline. Most the heavy computation work with the library is taken care of by the server and not the front end device. We did consider other web based point cloud visualization solutions, such as Potree, however Cesium is more widely supported and documented making it a good platform for development and production.

Point 3: There is lack of experimental results that proves the method provides good visualization in slow connection environment.

Response 3: We agree that there is lack of experimental results and have soften the language in the abstract (ln 20, ln 77, ln 254 and 265)

Point 4: The hardware configuration of testing environment is also missing.

Response 4: A new section (2.3 Computing Resources) was added to address this.

Author Response File: Author Response.docx

Reviewer 3 Report

Detailed comments can be found in the attachment.

Comments for author File: Comments.pdf

Author Response

Response to Reviewer 3

We would like to thank the reviewer for careful and thorough reading of this manuscript and for the thoughtful comments and constructive suggestions, which have helped to improve the quality of this manuscript. Our response follows in red.

Thank you again for your assistance.

~Andrew, Yu-Hsi, Kevin and Rich

Response to Reviewer 3 Comments

This manuscript presents an exploitation system for temporal stacks of UAS data (voxel of point cloud data) for quick analysis, a quite interesting way to visualize 3D scene. Voxelize point cloud data to compress data size is not new. The main concern of this system is the ability to processing large data. The manuscript claims that a scene of total 113MB point cloud a large file size, yet this is not true. To the reviewer’s experience, point cloud data size acquired by UAV could easily be several GBs.

Point 1: Line 27, the abbrev. UAS comes before “unmanned aerial systems”, please check the journal style.

Response 1: We agree that UAS should come after and have changed the text accordingly.

Point 2:Line 34 and 36, the “20M” and “18M”, meaning million pixels?

Response 2: Our intention is for M to represent Mega-pixels. We have updated the text accordingly.

Point 3: Line 151-153, why is the latitude and longitude presented in the test case? Why not use a UTM projection coordination for Pix4D could directly yield a UTM projected coordinates since photogrammetry and bundle adjustments should be applied on a Cartesian Coordinate. Besides, for longitude the 1 degree maybe can approximate to 92,133.39m, while for a high latitude, this is approximation could not apply.

Response 3: Coordinates are frequently utilized within the GIS user community and were used for the front end of the system to make it easy to interact with the point cloud data. This system does not currently perform any vector based analysis, but instead links data across time and space. Since the system is largely retrieving data from specific coordinate locations, it is fitting to implement a global geographic coordinate system. If more analytical tools were created to allow manipulation of point cloud data or other similar operations, a projected coordinate system would instead be utilized.

Point 4: Line 194, does the system offer a real-time interaction (scene 3D rotation and zooming) for one scene rendering takes 9.98 seconds?

Response 4: The system offers real time 3D interaction after a scene has been loaded into the viewer. It takes on average 9.98s to load scene into viewer, but once loaded it can interacted with in real time. KM

Point 5: Line 202, how much time does the system takes to query a voxel information on the Database?

Response 5: It takes 1.17s to query the database.

Point 6: Line 257, “and aligns data”, to the reviewers understanding, the proposed approach does not have such functionality

Response 6: We have changed this line as well as line 16 in the Abstract.

Author Response File: Author Response.docx

Round 2

Reviewer 2 Report

I suggest to accept in present form