砂防業務関連のデジタル化ノート

パスワードの新常識：強力にして基本は変えない／流出時は即・全く別に変更 パスワードの新常識：強力にして「基本は変えない」／流出時は即・全く別に変更 ※ ほとんどの流出はフィッシングによるもの。まずは“偽サイトに入力しない”運用が最重要です。 参考動画 基本方針（2025年の実務感） 頻繁な変更は不要。 まず 長く・強力 なパスワードをサービスごとに別で設定。 流出が判明したら即変更。 ただし 過去と似ていない“全く別物” にする（リスト型攻撃対策）。 最大のリスクはフィッシング。 URLの正当性確認／公式アプリやブックマークからログイン。 強いパスワードの作り方 最低12文字、できれば16〜20文字以上。 大文字・小文字・数字・記号を混在。辞書語は避ける。 サービスごとに別のパスワード（使い回し禁止）。 パスフレーズ（例： Blue-Dog?7River+Moon ）やパスワードマネージャーの利用。 必ず二段階認証（MFA）をON。リカバリコードも保管。 危険！“よくあるパスワード”ベスト427 以下は漏洩データに頻出し、攻撃ツールが最初に試す候補です。使っていたら今すぐ変更を。 123456 password 123456789 12345 12345678 qwerty 111111 123123 abc123 password1 1234 1234567 dragon letmein baseball football iloveyou monkey 696969 shadow ...

迷惑メール対策とリスク：メールアドレスを守る完全ガイド 迷惑メール対策とリスク：メールアドレスを守る完全ガイド メールアドレスの流出経路、フィッシング例、ダークウェブ監視、そして主要サービスのエイリアス設定と返信・ブロック運用まで。 まずは基本方針（最重要） 登録は必ずエイリアスで ：ショッピング、ホテル、怪しそうなサイト等は本アドレスを使わない。 返信時の差出人 ：Gmailは設定しないと本アドレスで返信されやすい。 送信元をエイリアスに変更 できるよう最初に設定する。Yahooはセーフティーアドレスを差出人に選べる＝ 受信者からは元アドレスが見えない（匿名運用） 。 漏えい検知＝そのエイリアスをブロック ：届き始めたらフィルタやブロックで隔離／無効化し、別エイリアスに切替える。 エイリアスとは？（利点・注意点） 定義 エイリアスは 本アドレスに紐づく別名アドレス 。受信箱は同じでも宛先で用途を分けられ、漏えい源の特定と自動振り分けに役立ちます。例：本アドレスが sakata@gmail.com のとき、 sakata+shop@gmail.com 。 メリット 登録先ごとに使い分け → 漏えい源の特定 が容易 宛先ルールで 自動仕分け （ラベル・フォルダ） 公開場面で 本アドレスを晒さない 注意点 一部サービスは「+」を拒否/正規化する場合あり 同一受信箱のため 容量やブロック設定は共有 Yahooは「エイリアス」という名称ではなく セーフティーアドレス （無料） Appleは無料で3つのメールエイリアス。iCloud+で 非公開リレー（Hide My Email） 拡張可 メールアドレスの流出経路（売買の実態） サービスの情報漏えい（不正アクセス・設定不備） マルウェア感染でアドレス帳ごと盗難 WebやPDF・SNSの公開情報をクローラーが収集 ...

当たらない道路防災点検は税金の無駄？――予測性能で見直す時が来た 【元記事】太田ジオ 技術基準が間違ってるからこの仕事はやらない。 道路防災点検担当の職員が「いま、私がやっている仕事は無駄なのでしょうか？」という質問が来ました。「残念ながらそうです」 http://blog.livedoor.jp/ohta_geo/archives/52056844.html http://blog.livedoor.jp/ohta_geo/archives/52051713.html 当たらない道路防災点検は税金の無駄？ ――予測性能で見直す時が来た タグ: 公共事業 道路防災 費用対効果 結論： 現行の道路防災点検は、点数式の安定度評価が当たらず、最後は「主観」に寄る運用に。にもかかわらず、豪雨で実際に崩れた斜面の事前的中率は 国道で約35％ 、 都道府県道で20％未満 。 この精度で全国に同じ方式を続けるのは、 納税者価値の観点から正当化しづらい 。点検は「やったか」ではなく、 “当てて被害を減らしたか” で評価すべきだ。 なにが問題？（超ざっくり） 斜面の危険度を「点数」で判定するが、 その点数があまり当たっていない 。 当たらないため、最終判断が 主観（総合評価） へ後退。 結果、 危ない所を見逃し、安全な所へ過剰投資 というミスマッチが起きる。 どれくらい当たらない？ 豪雨で実際に崩れた斜面のうち、事前に「危ない」と当てられた割合（適中率）は、 国道：およそ35％／県道：20％未満。 → つまり 半分以上を見逃している。 なぜ「税金の無駄」に直結する？ 資源の誤配分 ：当たらない評価で優先順位を決めると、限られた予算が間違った場所に流れる。 主観頼みの限界 ：主観は仮説として有用だが、 翌年に数字で当否を検証 しなければ精度が上がらない。 全国一律の固定費 ：低精度のまま全国で繰り返すほど、外れ分の支出が積み上がる。 どう直す？（シンプルな処方箋） 予測のKPIを公開 ： 適中率（PPV）70％以上 を下限目標、 見逃し率（FN）は年次で低下 を約束。 外れ学を制度化 ：...

ArcGIS Desktop 10.x：arcpy.mappingでMXDのデータソース一括置換（実例つき） ArcGIS Desktop 10.x： arcpy.mapping で MXD のデータソース一括置換 現場でよくある「レイヤの参照切れ」を、Pythonだけで安全に “上書き修復” する手順とサンプル。今回の実案件（ Set_Data 配下）を題材に、再現性のあるスクリプトと運用のコツをまとめました。 今回の事例（要約） 対象ルート： Q:\R06CHIBA\NARITA\TAKO\KYUKEI\Set_Data 上書き保存 （相対パス維持）＋ 同名を BACKUP に退避（同階層に BACKUP フォルダ作成） レイヤ名とSHP名を厳密に突き合わせ： KTAISEKI_3M は KTAISEKI_3M.shp が 同じフォルダに存在する時だけ 差替え（無ければ何もしない） KIDO_100KN も同様。DM系は色崩れ防止のため 非表示化・削除はしない （既存の正規パスが生きていれば再接続のみ） 右クリック実行（UTF-8）メニューからワンクリックで動かせる設計 置換ルール（今回案件） レイヤ名 期待ファイル 無い場合 備考 KTAISEKI_3M ./KTAISEKI_3M.shp 触らない（残置） ダミー生成・誤接続を禁止 KIDO_100KN ./KIDO_100KN.shp 触らない（残置） 同フォルダにある時のみ差替え DM/ラスタ 既存パス 触らない 正規の共通ベースから再接続のみ 実運用スクリプト（短縮版・そのまま動作） ArcGIS Desktop 10.4 / Python 2.7。MXDと同じフォルダに対象SHPがある時だけ置換します。ログはUTF-8、コンソールはASCIIに落として出力します。 # -*- coding: utf-8 -*- from __future__ import unicode_literals import os, io, sy...

JPG / PNG / BMP / GIFをGeoTIFF（TFW付き）に一括変換する方法 空中写真やスクリーンショット等の JPG / PNG / BMP / GIF を、座標付きの GeoTIFF（.tif） に一括変換する手順です。 同名のワールドファイル（ .jgw , .pgw , .bpw , .gfw , .wld ）が隣にあれば、自動的に取り込まれます。変換時に TFW（.tfw） も同時出力します。 対象と前提 対象画像: .jpg , .jpeg , .png , .bmp , .gif オプションで圧縮 ( COMPRESS=LZW )、タイル化 ( TILED=YES )、TFW出力 ( TFW=YES ) を有効化 ワールドファイルがあれば座標を自動解釈（例: photo.jpg と photo.jgw ） 座標系（EPSG）はワールドファイルに含まれないため、必要に応じて後述の方法で付与 方法①：コマンド一発（単発変換） GDAL が入っていれば、1枚だけなら以下でOK。 gdal_translate -of GTiff ^ -co COMPRESS=LZW -co TILED=YES -co TFW=YES ^ input.jpg output.tif TFW=YES により output.tfw も生成されます。 同名ワールドファイル（ input.jgw など）があれば自動で反映。 方法②：フォルダ内を一括変換（Pythonスクリプト） フォルダを選ぶだけで、JPG/PNG/BMP/GIFをまとめてGeoTIFF化します。 出力先は「同じフォルダ」または「サブフォルダ（ _tif ）」に変更可能です。 import os import tkinter as tk from tkinter import filedialog from osgeo import gdal # ===== 設定（必要なら変更）===================================== VALID_EXTS = {".jpg", ".jpeg", ".png",...

GeoTIFFからワールドファイルを作成する方法 GISでよく使う GeoTIFF には、位置情報（座標系やピクセルサイズ）が画像内部に埋め込まれています。 一方で、古いソフトやCADに取り込むときには、 ワールドファイル（.tfw など） が必要になることがあります。 ここでは「既存のGeoTIFFからワールドファイルを生成する方法」を紹介します。 ワールドファイルとは？ ワールドファイル（TFW, JGW, PGWなど）は、ラスタ画像を地図上に正しく配置するための 6つの数値 が書かれたテキストファイルです。 pixel size in X direction rotation about Y axis rotation about X axis pixel size in Y direction (通常は負) X座標（左上ピクセル中心） Y座標（左上ピクセル中心） 例： sample.tfw 0.500000000000 0.000000000000 0.000000000000 -0.500000000000 345000.250000000000 4275000.250000000000 方法① gdal_translateを使う（最も簡単） GDALをインストールしていれば、コマンド一発でGeoTIFFからTFWを出力できます。 gdal_translate -of GTiff -co TFW=YES input.tif output.tif -co TFW=YES を付けると、 output.tfw が生成されます。 GeoTIFF本体（ output.tif ）は元のコピーなので中身は変わりません。 方法② Pythonスクリプトで一括生成 複数ファイルをまとめて処理したい場合はPythonが便利です。 以下のスクリプトは、指定フォルダ内の .tif を探して、対応する .tfw を生成します。 import os import tkinter as tk from tkinter import filedialog from osgeo import gdal def write_tfw(tif_path): ds = gdal.Ope...

ズームレベルについて 0. ズームレベルとは？ Google Maps、国土地理院地図、OpenStreetMap (OSM)、Bing Maps などのWeb地図は、 ズームレベル (Zoom Level, ZL) で表示倍率を管理しています。 ZLが小さいと広域（世界全体）、ZLが大きいと詳細（街区レベル）になります。 これは世界中で共通の仕組み（Web Mercator投影 / EPSG:3857）に基づいています。 1. 計算式と一覧 ズームレベルごとの解像度（1ピクセルあたりの地上距離）は次の式で表されます： 解像度 [m/px] = (cos φ × 2πR) / (256 × 2^Z) φ = 緯度（ラジアン） R = 地球半径 6,378,137 m（WGS84） Z = ズームレベル 256 px = タイル1枚の大きさ 日本（北緯36度付近）の目安表： ZL 縮尺の目安 ZL 12 1:250,000 ZL 13 1:120,000 ZL 14 1:60,000 ZL 15 1:30,000 ZL 16 1:15,000 ZL 17 1:8,000 ZL 18 1:4,000 ZL 19 1:2,000 ZL 20 1:1,000 ZL 21 1:500 ※緯度によって多少変動しますが、日本の本州（北緯36°付近）では上記でほぼ問題ありません。 2. URLのどこにズームレベルが書かれているか Google Maps ：URL末尾の「◯◯z」がズームレベル 例： https://www.google.com/maps/@36.5844,136.6651, 11z 国土地理院地図 ：URLの #◯◯/緯度/経度/ の「◯◯」がズームレベル 例： https://maps.gsi.go.jp/vector/ #12 /36.6710/136.8362/ 3. WGS84について ズームレベルを扱うWeb地図は「WGS84」という地球基準座標系をもとにしています。 ただし表現方法に2種類あります： ✅ EPSG:4326 (WGS84) ：緯度・経度（度）。GNSSや測量で...