Reproducibility question: canonical VIIRS source and discovery-time contract
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 25/100
- issue の種類
- ドキュメント
- 明瞭さ
- 説明が足りない
- 活発さ
- 活発
- 技術スタック
- python
調査の方向性
Start by reading pipeline.py and inspecting the released canonical VIIRS feature table, especially the entries for FOD_ID 400645736. Compare the pipeline revision and available source metadata with the reported candidate matches. Done requires maintainers to identify the release inputs, timestamps, filtering rules, and provenance details or provide a construction manifest.
索引モデルが issue の本文から書いたものです。
説明
Hello WildfireIA maintainers, I am independently auditing the discovery-time input contract of the publicly released WildfireIA benchmark. This is a reproducibility request, not an assertion that the benchmark contains an error.
Could you please clarify:
- Which exact code commit or script revision constructed the released canonical VIIRS features? Was the public pipeline.py implementation the version actually used for the release?
- Which original NASA FIRMS sources, sensors, processing versions, and source snapshots were used? If available, could you provide a version identifier, checksum, or construction manifest?
- What timezone convention applies to the underlying FPA-FOD DISCOVERY_DATE and DISCOVERY_TIME fields? How were missing discovery times, apparent 00:00 values, UTC conversion, and daylight-saving time handled?
- Were VIIRS detection acquisition times filtered against each individual fire's discovery timestamp, or were detections matched by calendar date and spatial proximity? Were original publication/ingest timestamps retained?
- For FOD_ID 400645736, the released canonical feature table contains two VIIRS detections within 1 km. Our retrospective lookup using current standard-processed SNPP and NOAA-20 sources returns four candidate matches. Could you identify the original two detections (sensor, acquisition timestamp, coordinates, FRP, or stable detection/granule ID) and any additional filtering or nearest-fire assignment rule? The audit uses a deliberately selected 30-event sample and does not establish a population leakage rate. Original source identity and timestamp semantics would help us distinguish genuine temporal issues from source-version differences. Thank you for your work and for any provenance details you can share.
- 主要言語
- Python
- スター
- 3
- フォーク
- 0
- PR マージ指標
- 30日以内にマージされた PR はありません
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
似ている issue
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
micropython/micropython#19906 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
FinanceFlash/unvibecode#597 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
TomAnthony/YourOwnWeigh#21 ·
メンテナーはふだん 1 日以内に返信
-
[BUG]: Compliance rules never see Unity Catalog views as views対応中かも @wagnercsantos が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
databrickslabs/ontos#1348 ·
メンテナーはふだん 3 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 2 日以内に返信