Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...





Notes for meeting on 29 August 2018

Dan Slayback

Fritz Pollicelli

David Landis

Greg Ederer

Gang Ye

Diane Davies


    • Dan met up with David an hour before the meeting to explain the background
    • David has been studying perl tutorials - and looking at code and substituting cloud shadow for water detection
      • Dan is open to David / Greg coming up with more efficient waya ways to run the code
  • Steps
    1. David to make write the code for the cloud shadow detection
    2. Gregory Ederer can provide the information needed to run the code.
      • Greg has a test framework set up already that was used to test the water detection algorithm. Can be modified to test cloud detection algorithm. this will use pieces of production system to run the test.
    3. Dan Slaybackwill need to validate the output
    4. If happy with output – then they will run a science test. The code will be run in as if in production code but only visible internally. then it moves in to production
  • Dan requested that David document the the code so it can be modified in the future. The cloud shadow algorithm could do with being refined as the input data not great (it is 1km data and needs to be smoothed).
  • David thought in a month he might have the cloud shadow part complete (eg step 1).
  • David should ask if he has any questions or suggestions on how the code could be improved.
  • Next meeting will be on 26th September 2018
Notes for meeting on 21 August 2018

Dan Slayback

Fritz Pollicelli

Greg Ederer

Diane Davies

Gang Ye

Brief meeting. David Landis has been hired to work on transitioning the code to Pearl.

Dan to drop by and see him in Building 33 G316

Dan and Greg to try and set up weekly meetings with David to touch base on any issues that might arise.


Plan to meet next Wednesday 29th if David is free.

Notes for meeting on 19th March 2018

Dan Slayback

Fritz Pollicelli

Ed Masuoka

Diane Davies

  • Current Status: Step 1 is complete. The initial swath based water product is running as a PGE and Dan has checked the out put product and is happy with it.

Next steps

  • Greg is going to amend the PGE to include a cloud shadow mask. Dan and Greg are discussion whether to use the existing cloud shadow mask (likely) or whether to use a different one.
    • Dan needs to provide Greg with the code for the existing cloud shadow mask that uses MOD35.
      • the current code Dan uses has IDL operators. this will need to be re-written.
    • Diane and Dan to meet with Greg this week to discuss next steps this.

  • Dan to provide an outline for code to composite and tile the initial product. Dan to work with Greg who will write the code.
  • Terrain shadow filter (monthly product computed as part of this process) is to be applied to the tiled product
  • HAND (Height Above Nearest Drainage) filter, which identifies areas where flood water should not be present, will also be applied to the tiled product.


Notes for meeting on 22 February 2018

Dan Slayback

Greg Ederer

Diane Davies

  • Greg amended PGE code and has completed step 1. Dan happy with the product
  • Discussion on how to implement the cloud mask.
    • looking at options
    • this should be done as part of the PGE running in step 1
    • Diane to contact Eric Vermote to see if there was an improved cloud shadow mask. He said
    • "There is a cloud cloud shadow mask in the MOD09 product (at 1km resolution), at this resolution it is very difficult to evaluate cloud shadow mask and I am not sure about the performance. 

      Cloud shadow masks are currently being evaluated for Landsat 8 and Sentinel 2 data (using an operator derived  validation mask) we can probably gain a lot of experience from this and then transition the “best” algorithm to MODIS the best way we can. That will not be right away unfortunately but more like in a year timeframe,

      As far as terrain shadow it is an interesting problem quite feasible if you have a good Digital Terrain Model but could be computationally expensive because my guess is that you have to do it  at a finer spatial resolution than what your actual resolution but that can be studied too once again with Landsat 8/Sentinel 2 data.



...