taibif / camera-trap Goto Github PK

為了：

1. 減少上傳前資料錯誤
2. 上傳後可連結相機及資料

巡山員、工作站承辦人及林務局承辦人均需有一 SOP checklist 來協助確認上傳前資料資料流程的完整性。

透過系統 API 所提供格式及 endpoint 上傳。

包含：

• 計畫
• 樣區
• 相機位置
• 錄影上傳後的網址
• 開始時間
• 片長
• 播放清單 ID

播放清單用在相機位置資料的檢視頁面，當使用者檢視相機位置，頁面影片表單顯示同時，也啟動播放清單，開始逐筆播放影片。

• 調查 YouTube player 或 API 是否提供暫停時間資訊
• 開發提取該資訊功能

• Uploader
  https://github.com/TaiBIF/camera-trap/tree/master/lambda-youtube-uploader

• YouTube API Example
  https://github.com/TaiBIF/camera-trap/tree/master/youtube-iframe-api

Note.
若在發布的過程中有任何問題的話再麻煩讓我知道，感謝

• 提供本系統與資料三份以上之定期備份，其中至少一份必須為異地備份。
• 提供本系統資料包含修訂歷程之長期備份。

目前前端設計要在上傳資料與現有資料重複時，詢問使用者是否確定上傳。

• 現況
  • csvToJson 會在發現資料時空範圍重複時(不逐筆檢查，太耗資源) 設定一個 hold 屬性。
  • postJsonToMongo 在讀到 hold 屬性為 true 時，不會匯入資料。(測試階段時在程式中用 force_import 強制匯入。)
  • 上傳資料中，樣區、子樣區、相機位置等欄位值若與上傳前的檔案設定(樣區、子樣區、相機位置)值有所出入，csvToJson 會略過該筆資料，並在 UploadSession 中加入錯誤訊息，指名上傳資料中特定 row 的特定欄位資料有誤。內容沒問題的資料仍會匯入。
• TODO
  • 不重新上傳資料的情況下(指定過去上傳資料路徑，可從 UploadSession 著手) trigger postJsonToMongo 並設定 force_import，完成資料匯入流程。
  • 應考慮設計可容許單一檔案內含多個相機位置的資料上傳檢核機制。

理想上，一個設計良好的系統，應該不需要額外設計教育訓練課程，是以專案團隊將儘可能地將系統操作的提示建置好，期使使用者或使用單位的新進人員，能夠自行探索瞭解系統操作。然而，為了說明本案的開發成果，並溝通團隊在設計、開發本系統的思維、價值及方法，本團隊將舉辦兩小時之教育訓練，就特有生物研究保育中心、林務局及其他重要的潛在使用者進行系統介紹及操作說明，期使系統能平順地導入平常的工作當中。
教育訓練將包含一小時的操作示範，及一小時使用者上機實作，以確保目標使用者能上手新系統。

依據期末報告審查意見修正並完成網站建構、介面設計與教育訓練等全案之工作項目。

• 選擇軟體
• 檔名命名規則

• 在專案後期可視團隊運作能量，或與有興趣的團體合作，對標註資料進行分析，將分析結果呈現在專案網站。
• 對於標註資料的分析，本團隊可提供R的操作知識，協助探索標註資訊。

• 若發現程式設計錯誤（Bug）或本案安裝之軟體造成的系統運作異常現象，於通知後24小時內緊急處理並回復系統正常運作。錯誤程式修改方式與修正相關文件資料，均記錄於Github
  專案備查。
• 提供使用者系統問題排除與諮詢。問題及諮詢均透過線上系統表單進行。
• 針對系統問題修正及版本更新（功能增修）詳細在Github上說明，說明內容將保持在最新狀態，若需另行提供光碟可準備之。

• 調查影片 metadata 格式
• 找到「開始時間」（例如 2017-03-03 14:32:03）及片長 （例如 00:15:03）

計畫(project)、樣區(site, sub_site)、相機位置(location)、錄影上傳後的網址(url)、開始時間（錄影起始時間）(date_time_original, date_time_original_timestamp)、片長(length_of_video)、播放清單ID (youtube_playlist_id)

由影片上傳程序寫回資料庫的 write URL.

目前將影片上傳到 Youtube 的設計會被每日上傳限制與 spam detection 卡死，需要想辦法解決此問題。看是與 Google 談合作？或要找其他可談的串流服務？或降低畫質或轉GIF照存AWS？

Tutorial_get_refresh_token.pdf

• lambda 取 s3 權限
• s3:ListBucket
• s3:GetObjectTagging
• s3:GetObject
• s3:PutObject

Lambda 寫 cloudwatch 的 log - CloudWatchLogsFullAccess
Lambda 環境變數 (紅字部分從附件PDF取得)

• CLIENT_ID = # 從 credential
• CLIENT_SECRET = # 從 credential
• REFRESH_TOKEN = # 從 credential
• SRC_BUCKET = # video source bucket name on AWS S3
• DIR = /tmp/
• ENDPOINT_MMA = /multimedia-annotations/bulk-update
• ENDPOINT_MMM = /multimedia-metadata/bulk-update
• YOUTUBE_VIDEO_URL = https://www.youtube.com/watch?v=
• TAIBIF_API_URL = https://camera-trap.tw/api/v0.8/

期末報告及附件

• 大綱
• 委員意見：預估平台運作費用
• 功能實作與否之緣由 (例如 OI 值之計算及實作)
• 前端測試大綱、情境

附件

• 教育訓練計畫書
• 各階段訪談大綱
• 需求訪談逐字稿
• 第二期開發項目
• 伺服器環境規格書
• 系統架構
• 系統檢核表
• 系統測試報告書(含弱點掃描與源碼檢測)
• 軟硬體清冊

期末報告光碟

• 期末報告電子檔
• github上的內容
• 各階段訪談文字紀錄、逐字稿

Github內容

• 開發規劃建議規格說明書
• 系統設計與分析
• 美工圖片與程式設計
• 安裝、測試、訓練、技術文件及產生或開發原始碼之提供。不包含廠商使用之第三人軟體原始碼。

由於系統將有多個單位的各個角色參與使用，而各單位、計畫的相片資料在使用、分析及資訊公開作為上可能會因為不同的授權及行政規定需要系統協助滿足管理需求，故法律諮詢項目的工作在於確認資料管理及使用的規範是否能保護與相片資料、分析結果相關單位及人員的權益，同時確保規定的細節不至於限制自動相機調查成果在保育政策的制定，或是民間資料加值應用的創意。本團隊未來將就法律諮詢項目的工作結論以清楚的文字準確地在專案系統中列出說明。

• 大予正式簽約
• 大予提案簡報設計
• 訪談會議紀錄→因為現有紀錄未整理乾淨，時間緊迫下先以訪談大綱替代
• 後端開發項目
• 下半年工作安排
• 摘要計畫及工作計畫便利審閱
• 工作計畫書委員意見

• 確認 YouTube player 或 API 提供與 containing 網頁 app 之間的溝通機制
• 確認需要與 #31 連動的功能有那些

可能的連動功能

• 將暫停時間存在 cookie (可取得自 iframe API)
• 通知 containing 網頁 app 播放中的影片編號，讓資料表能指示播放中影片與資料的關係

驗收時至少要有資料進去。

• 與各單位聯繫，建立第一年度資料匯入的計畫清單
• 清單在共享資料夾可供檢視

以已建好的帳號與 YouTube API 介接，上傳影片。
取得下列資訊：

• 確認 client credential
• 應該要能夠由 project/site/sub_site/location, 以及原檔名與影片開始時間(date_time_original) 判斷檔案是否已上傳過。
• 若曾經上傳過，則回傳已存在之 youtube 連結 (如果 youtube api 不方便做這個操作，TaiBIF 可提供 query 用的 API)

查找是否已建檔的 API: https://camera-trap.tw/api/v0.8/media/query

• upload_file_name
  上傳到 S3 的原檔名，不含路徑
• date_time_original_timestamp
  錄影起始時間的 timestamp (單位到秒)
• full_location_md5
  md5("$project/$site/$sub_site/$location)
• Method
  POST
• Content-type
  application/json
• Data

{
  "query": {
    "uploaded_file_name": "IMG_0082.JPG",
    "date_time_original_timestamp": 1486728000,
    "fullCameraLocationMd5": "7621f2d15b1fb16ff04424baa6b08831"
  }
}

以檔案帶的 tags 「計畫」、「樣區」、「子樣區」、「相機位置」資訊，將同一相機位置的檔案組成播放清單，提供相機位置資料瀏覽頁面持續播放使用。

若 tag 資料是空值則設為字串的 NULL。

• 網站前台與後端管理介面之文字編碼必須採用萬國碼（UTF-8），確保多種語言資料能同時顯示無礙。歷史資料，特別是以大五碼（Big5）記錄者，應在此開發案中轉換為UTF-8。
• 靜態網頁在快取的情況下應在 4 秒內回應，無快取的情況下 7 秒；編輯寫入作業應在 10 秒內回應，負載高及複雜度高的查詢應在最多 15 秒內回應。使用機器或安排人力模擬壓力測試，若採用人力則需計畫委辦單位協助安排。
• 非因硬體、網路或電腦病毒因素所造成之系統當機（無法提供正常服務），全年不可超過8次。
• 每次系統當機時間不可超過4個時鐘小時。

檔案會帶「計畫」、「樣區」、「相機位置」等tags。

• 上傳路徑範例: {$bucket}/upload/{$upload_session_id}/video/.../J01-10260071_2015-10-26-18-33.MP4
• $bucket: camera-trap
• $upload_session_id: 上傳路徑 upload 的下一層目錄名稱會在上傳時給定，稱為 upload_session_id。
• S3 Trigger Prefix: upload/
• S3 Trigger Suffix: .mp4 and .avi
• tags for test
  -- keys: project, site, sub_site, location, user_id
  -- values: 測試計畫1, site1, NULL, location1, OrcID_0000-0003-1335-0184
  -- 測試時可先用以上設定值，實際值則由 s3 tags 讀取。

將以下資訊以存成兩份 json(.mma.json 與 .mmm.json) 至特定 S3 位置，內容包括
project、site、sub_site、location、錄影上傳後的網址(url)、開始時間(date_time_original)、片長(length_of_video)、播放清單ID (youtube_playlist_id) 等資訊。

• 位置規則: 以上傳原檔名為 J01-10260071_2015-10-26-18-33.MP4 為例
  -- {$bucket}/json/{$upload_session_id}/J01-10260071_2015-10-26-18-33.MP4.mma.json
  -- {$bucket}/json/{$upload_session_id}/J01-10260071_2015-10-26-18-33.MP4.mmm.json
• .mma.json 範例 (mma => multimedia annotations)

{
  "endpoint": "/multimedia-annotations/bulk-update",
  "post": [
    {
      "_id": md5($some_youtube_url),
      "project": "測試計畫1",
      "full_location_md5": md5("測試計畫1/site1/NULL/location1"),
      "$set": {
        "modified_by": "OrcID_0000-0003-1335-0184",
        "type": "MovingImage",
        "date_time_original": "2017:02:09 17:28:27 // 格式以metadata 中擷取出來的為準",
        "length_of_video": (暫時以 metadata 中擷取出來的為準),
        "youtube_playlist_id": $some_playlilst_id
      },
      "$setOnInsert": {
        "url": $some_youtube_url,
        "url_md5": md5($some_youtube_url),
        "date_time_original_timestamp": 1486661307 (由date_time_original 轉換而來),
        "date_time_corrected_timestamp": 1486661307 (這邊此值等於 date_time_original_timestamp)
        "project": "測試計畫1",
        "site": "site1",
        "sub_site": "NULL",
        "location": "location1",
        "full_location_md5": md5("測試計畫1/site1/NULL/location1"),
        "uploaded_file_name": "J01-10260071_2015-10-26-18-33.MP4",
        "timezone": "+8",
        "tokens": [
          {
            "data": [
              {
                "key": "species",
                "label": "物種",
                "value": ""
              }
            ]
          }
        ]
      },
      "$addToSet": {
        "related_upload_sessions": $upload_session_id
      },
      "$upsert": true
    }
  ]
}

• .mmm.json 範例 (mmm => multimedia metadata)

{
  "endpoint": "/multimedia-metadata/bulk-update",
  "post": [
    {
      "_id": md5($some_youtube_url),
      "project": "測試計畫1",
      "full_location_md5": md5("測試計畫1/site1/NULL/location1"),
      "$set": {
        "modified_by": "OrcID_0000-0003-1335-0184",
        "type": "MovingImage",
        "date_time_original": "2017:02:09 17:28:27 // 格式以metadata 中擷取出來的為準",
        "length_of_video": (暫時以 metadata 中擷取出來的為準),
        "youtube_playlist_id": $some_playlilst_id
        "device_metadata": {與相機相關但非 EXIF 的 Metadata 整組直接以 json 先塞在這},
        "exif": {EXIF 整組先以 json 塞在這},
        "make": 相機製造商(如果有此項資訊的話),
        "model": 相機型號(如果有此項資訊的話),
        "modify_date": device_metadata 中的檔案編修時間
      },
      "$setOnInsert": {
        "url": $some_youtube_url,
        "url_md5": md5($some_youtube_url),
        "date_time_original_timestamp": 1486661307 (由date_time_original 轉換而來),
        "date_time_corrected_timestamp": 1486661307 (這邊此值等於 date_time_original_timestamp)
        "project": "測試計畫1",
        "site": "site1",
        "sub_site": "NULL",
        "location": "location1",
        "full_location_md5": md5("測試計畫1/site1/NULL/location1"),
        "uploaded_file_name": "J01-10260071_2015-10-26-18-33.MP4",
        "timezone": "+8",
      },
      "$upsert": true
    }
  ]
}

委員意見：確認「地點的選擇、設置、記憶卡的取回頻率、資料量多少」等資訊是否各個訪談中都有記錄到。

"Function statement not at top level of a program or function is prohibited."

機器學習的研究在自然史研究領域的應用近年來十分熱門，許多軟硬體修正、演進使測試、應用的成本愈來愈低，技術門檻亦是。成功的應用對於專業人力日漸凋零的領域現況將會有很高的成本效益，也是我們希望未來的影像管理系統能夠幫忙分擔人力的功能。然而，雖然從現有文獻發表及或iNaturalist等組織可以看到目前機器自動影像辨識的進展，距離這類開發成果能否真正用在本地的正式系統中，仍有許多待釐清的細節。針對資料流程（如圖1）中第三項物種鑑定單元，本團隊計畫以專案中管理影像資料，利用諸如Google Vision API ，嘗試在物種鑑定步驟引進機器學習與自動辦識，並以人力鑑定結果提高機器學習的準確率。
由於自動影像辨識技術發展快速，為免過早投入過多開發成本，此部分工作主要以桌面調查研究方式進行，輔以機器學習公開API之測試。本團隊將在結案時提出照片自動化鑑定開發評估報告，設定對資料自動辨識的期望，及評估實務上建立正式服務所需的資源、技術、經費規模及預期效益，供管理單位未來進一步發展系統考慮。未來主管單位決定實作後，亦應測量其對於資料管理作業成本的影響，以決定是否大規模投資建設。

未來系統將曝露在網際網路上，為了避免遭受攻擊，或使用者資料外洩，專案團隊在系統建構時使用Amazon Web Services的 Trusted Advisor 協助安全的系統規劃，而在開發的系統上，將以高標準進行網站應用程式的資安漏洞掃瞄，並修補發現的問題。提供資安掃瞄的廠商很多，使用的工具也有不同。本團隊除了**研究院資訊服務處針對院內系統的免費檢測 之外，亦將針對重點功能頁面使用中華電信提供的付費服務 ，進行細部的掃瞄及檢測。

設計能提供「計畫、樣區、相機位置、錄影上傳後的網址、開始時間、片長、播放清單 ID」等資料上傳的 JSON 格式，供工程團隊實作。