Meetings

May 10 call agenda

  1. Introductions
  2. Workflow overview: hardware and software requirements

  • details on data sources ( size of input sets, output sets)
    • The data to upload for processing a 400x400m area (160,000 sq meters) would be 2-4 GB (500 to 600 overlapping images) which is around 50 GB for a 1 square mile.
    • The figure above is derived from area near NCSU where fixed wing UAS flying around 100m above ground was used. Various quadcopters or octocopters usually fly lower so they would generate more images for the same area but generally they are also used for mapping smaller sites. Lidar could be mounted on UAS as well and I would expect similar size data sets from that, but it is still much more expensive to do lidar on UAS than images.
    • I considered higher overlap with 600 images for 400 m x 400 m and 8 MB per image. For a square mile, which seems to be around size of Dix park, it is around 80 GB for upload.
    • The download depends on what we actually want to produce (e.g. only orthophoto versus water flow or flood inundation result). The usual size of a more complete dataset for the area above is in GBs with 0.3 m resolution which is 100s of MBs per square mile per output.
    • There are ways how to reduce the size of the data sets, especially the point cloud, but that could be part of the research and is highly dependent on applications.
  • data transfer (how to get access to NCNGN?)
    • With WebODM end-user upload the data using web browser.
    • Access to NCNGN: our lab has currently 1Gb connection which we should use as a baseline for comparison with any improvement we will develop. OIT will work with us on potential solutions.
  • operating system
    • The common operating system for all software packages is Linux.
    • GRASS GIS runs on both MS Windows and Linux (an also any unix-like system like Mac OS or BSD).
    • OpenDroneMap is prepared to work on Ubuntu. It is used through Docker (Vagrant in past) on other operating systems.
    • WebODM is used through Docker (WebODM node and one or more processing nodes).
    • Agisoft PhotoScan runs on both MS Windows and Linux.
  • sUAS imagery processing software: OpenDroneMap (ODM) and/or Agisoft PhotoScan
    • OpenDroneMap is open source under GNU GPL.
    • WebODMis open source under MPL and uses ODM (which is GPL).
    • Agisoft PhotoScan is proprietary and requires purchasing a license.
  • GRASS GIS for postprocessing, change detection and fusion with lidar data, future analysis and modeling applications
    • GRASS GIS is open source under GNU GPL.
  • data transfer to city in appropriate GIS format
    • We need to define what data we are actually delivering.
    • There are new technologies such as Greyhound and Entwine for streaming and indexing point clouds and plas.io (to display such stream) and PDAL (to process such stream locally).
  • What software is required on the GPU-equipped server and does it require licenses?
    • The current version of OpenDroneMap does not take an advantage of GPU and neither does GRASS GIS (both can do CPU-based parallelization).
    • Agisoft PhotoScan can take an advantage of GPU and requires to purchase a license(s).
  • What OS needs to be installed?
    • See above.
  • How frequently does the software change?
    • OpenDroneMap is released approximately every 6 moths. Having a latest version is important because many crucial features are being added.
    • WebODM is doesn't have a official release yet, so updating is important.
    • GRASS GIS is released approximately every 6 moths. Having a latest version is not crucial because most of features we would use is stable, but there might be specific new features we want to use (e.g. file format support or parallelization of specific functions).
  • What is the process to bring their code into the server – is there a git repo?
    • We don't have a Git repo with a complete processing chain at this point, we need to first clarify the details of the workflow. We can create a git repo for the process then.
    • The question is how specific this should be to the particular task and architecture.
    • If we decide for the WebODM solution, we don't need scripting for the basic processing of point cloud and getting orthophoto and DEM. We would need to add code for further processing and distribution as needed.