最新の地図
OSM九州(sjisとutf8同梱)→240614.zip
OSM全国→240614_sjis.zip240614_utf8.zip
06.15 14:14 通常更新

zip解凍、gmapsupp.imgにリネーム、microSDのgarminフォルダ内に格納
nuviトップ>ツール>設定>地図情報(myMaps)>□OSM … ←これだけチェック、再起動
2022.04.16 garmin nuviの地図

2022.04.16 garmin nuviの地図

↓以下の地図リンクは置き場の容量の関係で消えてます。

Home 更新記録


(c) OpenStreetMap contributors
 OpenStreetMap for GARMIN、こちらのサイトの地図が 2021年11月23日を最後に更新されなくなりました。 上の地図はそちらの物の築城基地周辺。 御高齢との事でしたので、心配ではあります。 永い事お世話になりました。
 他にも地図を上げてくれているサイトはあるのですが、 更新頻度とか地図のサイズとか見た目とか、 先出のサイトを超える物がない(個人の感想です)。

 自分で地図を生成しなければならなくなりました。


(c) OpenStreetMap contributors
 そちらのサイトにおおよその方法は残してあって、
OSMデータをDL
巨大なデータを処理できるサイズに分割(splitter)
分割データをgarmin地図化し、地図を1つに結合(mkgmap)
 という流れ。その通りに作ったら海と陸の区別が無い、何か方法があるはず。
 地図生成用の膨大なパラメータがフォルダのあちこちにあって、 どれがどう反映されるのかわかり辛い。 別のサイトで少し古いパラメータを公開していたのでそれで地図生成したのが上の地図。 相変わらず海の色が陸と同じですが、海岸線の黒い線が出るようになった、 海から基地を横切る境界線が目障り、 線路が貧弱、細い道路は多め、国道県道の番号表示も多い、 全日本での地図サイズが1G越えで巨大、 細かいところの見え方が違うような。

 これでは公開できない。

 なぜかパラメータは秘密にする文化みたいなんですよね。 海外サイトに、パラメータ置いといたら利用されるばかりだったので止めた、 みたいな記述がありました。利用してもらうために置いとくんじゃないんでしょうかね。
 パラメータ関連サイトを探していたところ、 完成した地図からパラメータ抜いて編集して戻す事が可能らしい。
 以前使っていた地図からパラメータ抜いて新しい地図に入れたらどうか。
→ダメでした、抜く前後でパラメータサイズが違うとエラーで合成してくれない、 やはり正攻法で。

 地図サイズは必要な地方のみで作ることで小さくしました。 九州のみで98M、九州中国で158MB程。あと関東ぐらい足してもいいかも。
 海と陸の色が同じになる問題はいろいろな所で挙がっているのですが、 なかなか答えにたどり着けませんでした。
 何回パラメータいじって地図生成したことか。
 そして、とある海外サイトのとあるコメントを参考にオプションを設定、 生成後のサイズが初めてちょっと増えてまして、98M→100M もしやと表示してみると海が青い(この時は宮崎の日向市と熊本沖の長島が水没してました)。 やっと見つけました。

 その呪文は
java -Xmx1500M -jar .\tools\mkgmap\mkgmap.jar --generate-sea=extend-sea-sectors,close-gaps=1000,floodblocker -c .\split_source\template.args
 --generate-seaというオプションとそれ以下のパラメータ(から-cの前まで)が答えでした。 カンマ以下は海岸線が閉じてなかったら直線で閉じるとか(まあ保険的な)、 海の中に道があったらそこは陸地判定で、海色で塗らないとか (これで宮崎の日向市と熊本沖の長島の水没回避)だったかと。

 この辺デフォでいいんじゃないでしょうか。データがでかくなるといっても2%ぐらいですし。

 久しぶりにOSMの細かい所を修正し、2日待ってからデータDL、地図生成しました。 garmin nuvi地図に修正部分が反映されてました。やっと一歩前進。

 地図眺めていて気付いたのですが送電線は不要、消したい。 無いのを足すのは難易度高いですが、 不要なものを消すのは行頭に#付けるだけなので比較的容易。
# power=line [0x29 resolution 21]
 これですね。消えました。

 現場に行っても見えない県境なんかも不要
# boundary=administrative { name '${mkgmap:boundary_name}' }
# boundary=administrative & admin_level<3 [0x1e resolution 12]
# boundary=administrative & admin_level<5 [0x1d resolution 19]
# boundary=administrative & admin_level<7 [0x1c resolution 21]
# boundary=administrative & admin_level<9 [0x1c resolution 22]
# boundary=administrative [0x1c resolution 22]
# boundary=national [0x1e resolution 17]
# boundary=political [0x1c resolution 19]
 この辺ですね。これも消せました。

 まだまだ暫定ですが、こうなりました。

(c) OpenStreetMap contributors
 上の地図はすべてGarmin BaseCampで表示させてそれをキャプったもので、 nuvi3750で表示させるとまた少し感じが違います。 基地の滑走路は現状でいいけど、 線路はもうちょっと太くしたほうがいいかも。 国道県道の番号表示がちょっとうるさいですかね。

 海が青くなった九州の地図をnuvi3750に入れて3時間150km程、 一般道で使ってみました。 道路の番号は今までのと同じ程度にしか出ません。 BaseCampとnuvi3750の表示はかなり違う。 鉄道の線路も主張し過ぎず、変えなくていいような。 細かい道が出て来過ぎるような気もしますが、わざわざ消すほどでもないかも。
 山の頂上のアイコンと山の名前は必要なんでしょうかねー? 縮尺700mより寄ると細かい道も出るので それに合わせて山頂も出るように調節(resolution 22)しときました。
 nuviで見る限り、道案内や警告など、今までの地図とほぼ遜色ありませんでした。

九州だけですが、ココに
20220416_06.zip
置いときますね

あと気になったのが、
河川の表示が非常に細かい印象。相当引いて(縮小して)も消えない C:\OSM\tools\mkgmap\examples\styles\mystyle\inc\water_lines
waterway=canal [0x1f resolution 21]
waterway=drain [0x1f resolution 22]
waterway=river [0x1f resolution 18]
waterway=rapids|waterway=waterfall [0x1f resolution 22]
waterway=stream [0x18 resolution 22]

C:\OSM\tools\mkgmap\examples\styles\mystyle\inc\water_polygons
natural=bay [0x3d resolution 18]
natural=glacier [0x4d resolution 18]
natural=marsh [0x51 resolution 20]
natural=mud [0x51 resolution 20]
natural=wetland [0x51 resolution 20]
natural=water [0x3c resolution 18]
natural=waterfall | waterway=waterfall [0x47 resolution 21]
natural=sea { add mkgmap:skipSizeFilter=true } [0x32 resolution 10]

C:\OSM\tools\mkgmap\examples\styles\mystyle\lines
waterway=canal [0x1f resolution 21]
waterway=drain [0x1f resolution 22]
waterway=river [0x1f resolution 18]
waterway=rapids|waterway=waterfall [0x1f resolution 22]
waterway=stream [0x18 resolution 22]
このへんですかね

waterway=river [0x1f resolution 18]
↑mystyle\lines と mystyle\inc\water_lines の2箇所にあります
natural=water [0x3c resolution 18]
この2つが特に怪しい
resolution18の所をすべて20にして、縮尺3kmより寄ると河川が出現するように調節。 でも地図サイズはそれほど小さくはならないですね。

 移動中のナビ画面で地面に緑色が付いている所がありました。 BaseCampでは果樹園=orchard、 polygonsファイル内には見つからない、orchardのイメージ番号が0x4eで、 こちらは見つかりました。
# landuse=allotments [0x4e resolution 21]
# landuse=farm |landuse=farmland [0x4e resolution 20]
# landuse=vineyard [0x4e resolution 20]

 さらに低木地帯、湿原も描画されています。
# natural=scrub [0x4f resolution 20]
# natural=wetland [0x51 resolution 20]
 これらを消しました。こっちはサイズ縮小に効果あり、99M→97M程に。

 地図側から見て不要そうな表示はほぼなくなりましたか。 polygonsパラメータファイルなどを眺めてもこれ以上は消しようがないような。 あと消すとすれば小さい道路や公園、自衛隊の駐屯地、工場ぐらい?
 しかし小道データは内包されていて、 それを表示するしないだけではデータ縮小にほとんど寄与しないはず。 POIは座標とアイコンコードだけですが、 数が多ければそれなりにデータ量もあるだろうし、少し消してみますかね。 そういえば自転車屋(あさひ)がやたらと目立ってました。

2022.04.18のOSMから全国地図sjisのgmapsupp.img
758MB程で1G以下にはなりました。nuviに使ってるSDカードが1Gなんで、 地図サイズ1G以下は必要要件。
20220418_0108.zip



(c) OpenStreetMap contributors
 あさひがどうやっても消えない(最終的には原因判明)のでstyleをデフォに戻したら、 海岸線の黒いラインが消えましたが、海と陸の塗り分けは出来ていました。 海岸線ラインは不要らしい、データ圧縮にも有利だし、むしろこっちのほうが見た目好ましい。 地図は九州で120Mぐらいで大きくなってました。 style内のファイルの要素をいろいろ消して (飛行場内の滑走路は消してもほとんどサイズ変わらず)、 少しずつサイズは小さくなったのですが、サイズ縮小の決定打がわからない。 そこで拾ったstyle内の一部をデフォと差し替えて地図生成していったところ、 polygonsが決定打、 それ以外はほとんど変わりませんでした(上の地図)。九州で95M、 見た目ほとんど違いがわからない。 これ以上の縮小は小道などの必要な情報が消えますかね〜。
 良くみると小さな池にpoiの点が入ってます。これは消してもいい。
 94.98Mまで小さくなりました 220420_06.zip


(c) OpenStreetMap contributors
 全日本地図を生成して眺めていた所、四国の西側の宇和島海岸に直線的な部分がある。 フェリーが地上を走っており、おかしい(下の図)。
 ここ、四国だけで生成すると問題ない(上の図)のですが、 全国で生成すると直線的(下の図)になる。 元データは同じはず(違うのか?)だし、原因がわからない。 初期に作った海岸線が黒線の地図もココは直線的になっているので、 海岸線に黒線を引かないのは原因ではない。
 OSM for GARMINサイトの2021.11.23地図ではここは正常(上の状態)なので、 何か手はありそう。

 mkgmap --generate-seaのパラメータを大きく振ってみたのですが、 どう振っても四国だけならOK、全国だとダメは変わらず。

 それ以前の問題?splitterのパラメータを振ってみました。
--max-nodes=1500000→2000000
 これで四国西海岸の直線的な部分が増えました
 mkgmap中に[重大]が皆無(初期のパラメータで四国のみ生成の時は結構出てた)でした。
 方向性は真逆ですが反応はありました(生成時間は延長、地図サイズは少し縮小)。

 数字増やしたら直線部分が増えたので、数字減らしたら直線部分が減るはず。
--max-nodes=1500000→1000000
 これで宇和島海岸の問題が解決しました\(^O^)/。
 mkgmap中に[重大]は皆無でした(生成時間は初期と同等、地図サイズは少し肥大)。

 呪文の答えは↓これでした。
java -Xmx1500M -jar .\tools\splitter\splitter.jar --keep-complete=true --description="OSM JAPAN" --output-dir=.\split_source --max-areas=512 --max-nodes=1000000 --search-limit=1500000 --mapid=08100001 .\pbf\japan-latest.osm.pbf

 そうやって完成したのがこれ 220423_0108.zipです。
 あとは少しずつ振って生成時間と地図サイズの落とし所を探っていけばいいかと。


(c) OpenStreetMap contributors
 また全国地図を眺めていたら、 対馬周辺と男鹿半島南の秋田火力発電所海岸におかしな部分があります(上の図)。
 --max-nodes=1500000の時には少なくとも対馬周辺は問題なかったのですが、 男鹿半島南は既にダメですね。 splitterのオプション --max-nodes=1200000で作り直し。宇和島OK、対馬もOKですが、 男鹿半島南の小さい所ですが改善しない。さらに宇和島の北側の東西に伸びる海岸がおかしい。 splitterのオプションをいろいろ振って、 --max-nodes=1100000で宇和島の北側はOKですが、男鹿半島南は改善せず。 ここはsplitterが原因ではない模様。

 mkgmapのオプションを振っていて、floodblockerを外したら改善(下の図)、 その代わり各地に水没発生。floodblockerのパラメータを調節し、 fbgap=200これを加えて問題なくなりました。

 splitterの呪文はこうなり、
java -Xmx1500M -jar .\tools\splitter\splitter.jar --keep-complete=true --description="OSM JAPAN" --output-dir=.\split_source --max-nodes=1100000 --search-limit=1500000 --mapid=08100001 .\pbf\japan-latest.osm.pbf

 mkgmapの呪文はこうなりました。
java -Xmx1500M -jar .\tools\mkgmap\mkgmap.jar --generate-sea=multipolygon,extend-sea-sectors,close-gaps=1000,floodblocker,fbgap=200 -c .\split_source\template.args

 これで海岸線は大丈夫だと思いますが、まだ見落としがあるかもしれません。 ソースは上のと同じ日付、
全国で753.11MBあります 220423_0108b.zip

 鉄道が途切れてる、トンネル部分なので地上から見えないし目印にもならない。 とりあえずなくていいですかね。

 山口の日本海側、角島の東におかしな海岸線がありました。 海岸線のパターン的にsplitterのパラメータ由来っぽかったので max-nodes=1050000にして回避できました。

 東京湾の埋立地がgarmin地図では一部水没してます、道路はたくさん見えているのに。 これがsplitter、mkgmapではどうやっても回避できない。 埋立地の消える所と消えない所で何か違うのか。 OSMの元データの海岸線のリレーションに、[島 本州 outer]と[湾 東京湾 outer] がある所は水没してない、リレーションが何も無い所は水没している? ためしに水没する小島の海岸線にこれを付加してみました、結果は2日後。 別の湾の小島の海岸線にも何らかのリレーションがありますね。
↑違いました。 東京湾内のgarmin地図に描画されている所は島のように見えて島じゃなかった、 水路を横切って海岸線が陸につなげてある。眺めていて気付いたのですが、 東京湾(砲台のある人工島があったはず)、相模湾内(江ノ島とか)の 完全な島設定の所は一つもgarmin地図に描画されてない、湾内に島が無い。 本土に陸続きの所は湾のouterですが、完全な島は湾のinnerのはず。

 東京湾の埋立地に良く似た構造の博多湾の埋立地も島は[湾 博多湾 inner]で、 garmin地図にも表示されていました。
 唐津湾内の表示されている島は[小島]で リレーションは[湾 唐津湾 inner]になっています。 隣の表示されて無い島はリレーションがない。 これを同じく[湾 唐津湾 inner]にすると、 数日後にgarmin地図にも表示されるようになりました。 答えは[湾 ○○湾 inner]のようです。

(c) OpenStreetMap contributors
 左が初期状態、右が[湾 東京湾 inner]を数箇所に付加して数日後、 埋立地がgarmin地図に描画されるようになって来ました。 相模湾の江ノ島も見える。 修正の方向はこれで良いようです。
 2022.05.02 東京湾をぐるっと回って、[湾 東京湾 inner]を付加しました。 まだ忘れている所があるかもしれませんが、 OSMとgarminを見比べつつ少しずつ修正ですね。
 九州は最短1日ぐらい?割りと早く反映されるのですが、 関東は3日ぐらいかかるみたいです。←特に地方で違いありませんでした。 修正したタイミングで反映が早かったり遅かったりのようです。
 OSM for Garmin の地図ではこの辺も描画されてるんですよね。 OSMデータから海岸線を引くのではなく、 別データからもってくるという手法があるらしい。 陸と海の塗り分けの境界と海岸の黒線とが微妙にずれている部分があったり、 そのサイトの方が海岸塗り分けするとデータが巨大化するとおっしゃっていたのは その為なのかもしれません。

 東京湾はほぼ修正が反映されました。

 2022.05.07 条件をいろいろ振っても海岸線が水平垂直な直線状になる所が1箇所以上出現して、 あちらを立てればこちらが立たず状態がずっと続いてます。

良く直線状態になるのが、
 四国の八幡浜から宇和島
 四国の中土佐
 山口県の角島の東
 福岡の博多湾から壱岐対馬の広範囲
 天橋立
 秋田の男鹿半島の南
 駿河湾の東
 岩手の久慈市から陸前高田市にかけて
この8箇所に限る?(気付いてない所がまだあるかも)。
 この辺にも不具合ありました。舞鶴 館山 尾鷲の南西の田辺市

 地図生成を効率化すべく、PC2台使って同時進行、splitterからmkgmapまでbatで自動化。
--max-nodes=1500000 ←これを振ると確かに地図は反応するのですが、 直線状態が必ずどこかに残る。数字を大きくすると地図サイズが少し小さくなります。
--search-limit=2000000 ←これは反応なし
--resolution=13 ←これも反応はあるにはあります。 デフォ13で、12から16まで試しましたが、やはり直線部分がどこかに残る。 17以上にするとメモリ不足で2時間経過しても終わらなくなりました。 各エリアごとならデフォで十分、全国なら16が直線部分が少なくなるみたい。

各エリアごとに生成すると異常部分が無いのを思い出しまして、
 各エリアごとのデータをDL
 各エリアごとにsplitter
 各エリアのtemplate.argsをくっつけて
 mkgmapしてもみましたが
かえって異常部分が増えました。

 ここでふと、OSMforGarminサイトの方の有難いお言葉を思い出しまして、
 完璧を求めてはいけない
 そうでした、妥協も必要。1データで条件振って2つ作って良い方を採用することにします。

 全国で747.09MBあります 220506_0.zip
 駿河湾の東が広域で変ですが寄ればOK。
--max-nodes=2500000 --search-limit=2000000 --resolution=16
splitterにこのオプションで生成してます。元データが変わるとどうなるかわかりません。

 2022.05.08 今日のデータを条件振って地図生成した所、海岸線の異常部分がないみたい。 完全にチェックするのは難しいのですが、今まで異常があった所はすべてOK、
 土佐清水周囲の海岸線に広範囲に異常がありました。
splitterの条件はこれです。
--max-nodes=2550000 --search-limit=2550000 --resolution=16
 全国で747.47MB 220508_0.zip

 splitterの呪文はこうなり、
java -Xmx1500M -jar .\tools\splitter\splitter.jar --max-nodes=2550000 --resolution=16 --search-limit=2550000 --keep-complete=true --description="OSM JAPAN" --output-dir=.\split_source --mapid=08100001 .\pbf\japan-latest.osm.pbf

 mkgmapの呪文はこれで固定してます。
java -Xmx1500M -jar .\tools\mkgmap\mkgmap.jar --generate-sea=multipolygon,extend-sea-sectors,close-gaps=1000,floodblocker,fbgap=200 -c .\split_source\template.args

 オプション、パラメータあれこれいじっていたのですが、 mkgmapのパラメータはこれ以上いじりようがないみたい。
 fbgap=200は秋田の火力発電所にのみ有効で、fbgap=85まで減らしてもほぼOKでしたが、 fbgap=80だと秋田に不具合が出たのと、 splitter後のデータ次第では85でも不具合が出た。 その同じsplitter後データで、200にすると出ないので、ここは200固定に。
 splitter後のデータを固定して、mkgmapのパラメータいじっても 海岸線の不具合部分は変化しませんでした。地図サイズも全く同じ。
 splitter後のデータ次第では不具合頻発箇所に不具合が出てないので、 原因はsplitterにありそう。

 splitterの方は、resolutionの数字を増やせば不具合が減り、 数字を減らすと不具合が増える傾向。 17とか18にしてみたいのですが、メモリが足りないらしく実行できない。 セーフモードのDOS窓のみでどうか。
 max-nodesは変化させると不具合部分が移動しますが、消える事はないようです。

 という事でsplitter and or mkgmapのver up待ち。

 2022.05.15 海岸線に異常がないような地図が出来ました。220514_0.zip
今まで異常が発生した所、
 対馬-博多湾 北九州 佐伯 鹿児島湾 枕崎
 角島の東 尾鷲の南西田辺市 尾鷲市 天橋立 舞鶴 石川x2
 駿河湾東 館山 岩手県久慈市-陸前高田 秋田
 宇和島-八幡浜 中土佐 土佐清水 四国宿毛市 阿南市南の小勝島
 これらはすべて大丈夫、また新しい所に発生している可能性はあります。

 呪文はこれです。(verは、splitter651 mkgmap4902 2022.05.14のOSM日本全国。splitter13分、mkgmap18分ぐらい)
java -Xmx1600M -jar .\tools\splitter\splitter.jar --max-nodes=2010000 --resolution=16 --search-limit=5000000 --keep-complete=true --description="OSM JAPAN" --output-dir=.\split_source1 --mapid=08100001 .\pbf\japan-latest.osm.pbf

java -Xmx1600M -jar .\tools\mkgmap\mkgmap.jar --generate-sea=multipolygon,extend-sea-sectors,close-gaps=1000,floodblocker,fbgap=150 --improve-overview -c .\split_source1\template.args

 splitterのオプションで、--max-nodes=2020000にすると、 角島の東側から江津市まで今までになく広範囲にガタガタでしたが、それ以外の部分は正常。 このパターンは初めてで、mkgmapのverが2つ進んだ(これ以前は4900使用)ことで なにか描画に関する部分に変更があったのかも。
 splitterの--max-nodesの値を精査中ですが、 今の所、上位4桁振って
 1800000 OK
 1900000 館山から横須賀広域でダメ、他は大丈夫
 1980000 対馬から山口広域でダメ、他は大丈夫
 1990000〜2014000までOK、
 2015000〜2020000でダメ、
という事がわかりました。各値で生成された地図は微妙にサイズが違います。
 だめな部分が対馬から山口北部に集中するようになった? パターンも今までに無い形。mkgmapのver upのおかげでしょうか、 海岸線がおかしくなりにくい、なったとしても広範囲なので気付きやすい。 やっと次に進めます。

 九州のみで地図生成した場合、四国の佐田岬の先から水平または垂直に細長い地面が出来る。 これがsplitterのパラメーターを振っても変化しないので、どうもOSM側データの問題らしい。 海上で、しかも四国側だから実用上問題ないのですが、 気になったのでこの辺のデータを修正してみました。
 後日九州のみで地図生成して、佐田岬近辺の四国が寄りで消えましたが、これが本来の姿? 全国でも地図生成しましたが、こちらは問題なし、海上のラインが切れていたのが原因みたい。
 更に元データを修正して佐田岬は一応描画されるようになりました。

 2022.05.20 海岸線は安定しました。地図サイズを小さくしようとしています。 stylesフォルダ内のlinesの設定で、resolutionやlevelの数字をいじると lineが出現する縮尺を変えられる事になっているのですが、 実際にはBase Campでは3km、700m、200mの3段階しか機能しない。 garmin nuviでは若干縮尺が違いますが、やはり3段階、今の所原因不明。 ここはOSM for GARMINの地図も同じでした。
 この辺の設定ですが、 \mkgmap\examples\styles\default\options この中で設定するらしい。
現在↓のようになってまして、
levels = 0:24, 1:22, 2:20, 3:18
左から200m/700m/3km/それ以上のようですね。 More levels may make zooming smoother, but it will generate larger map tiles. ということなので、この辺が妥協点なのかも。

(c) OpenStreetMap contributors

 駐車場内の道路などは200mより寄って出れは十分なのでその辺の設定を探しつつ、 resolutionの数字は24(=200mで出現)を増やしつつ地図生成して、 効果が良くわからない所は#で削除し、 全国で700MBちょっと、九州で89MBまで小さくなりました。 各尺度での道路の密度はOSM for GARMIN地図(719MB)と同じで19MB程小さく出来、 とりあえず満足いく状態になりました。 まだpointが手付かずなのでもう少し小さく出来るかも。
全国sjis220519_0.zip
九州sjis220524_6s.zip
九州utf8220524_6u.zip

 2022.09.18 地図を生成していて、九州のsjisを作った後に、 操作ミスったのかutf8が出来ていなかったので再度作ったのですが、 海岸線がおかしいものが出来てました。先に作ったsjisの海岸線は大丈夫。 あとから作ったutf8と同時にsjisも生成されるのですが、そちらのsjisも海岸線がダメ、 先のsjis比で地図サイズが若干小さい。条件変えて地図生成して原因を探った所、 どうもPCのメモリー不足らしい。他のアプリ起動して後ろで地図生成すると 少し小さめで海岸線がおかしいのが出来る、 アプリ終了させてDOS窓だけで生成すると成功します。

 2022.11.12 batファイル内でcurlコマンドを使って地図の生データをDLし、 地図生成までをワンタッチで行おうとしました。 win7なのでcurlを別途DLして、system32フォルダに格納してDOS窓内では"curl --help"などで 正常に動作していました。
 ところがbat内で起動すると、
 'curl' は、内部コマンドまたは外部コマンド、操作可能なプログラムまたはバッチ ファイルとして認識されていません。
 これでつまづきました。
 DOS窓内で直接コマンドをコピペすると実行されるのに、 batファイルから実行させると上記エラー。
 この時curlはsystem32内に置いてあって無論パスは通っています。 master seekerというファイル検索アプリでcurlを検索するとsystem32内に見つかる。 TFというファイラーでsystem32内を見るとcurlが見えないという不思議な現象が。 無論隠しファイルにはしてないし、ファイラーは隠しファイルも見える設定。 explorerだと見える。
 これ実はcurlに限った現象ではなく、 以前empty.exeでメモリ開放しようとした時も見られましたが放置してました。
 ググっても解決方法はみつかりません、 所有者とか権限とか変えたのですがダメ。 直接curlコマンドをDOS窓にコピペするとOK、 batから実行するとダメ、管理者権限でbat実行してもダメ、 管理者権限でDOS窓開いてそこでbat実行してもダメ。
 回避策として、 system32内にcurlがあるとダメ、他の普通のフォルダ内にあればOK。
 なぜこうなるのか不明ですが、 system32は何かスペシャルなフォルダなんでしょう。

 2022.11.13追記。確かにスペシャルなフォルダでした。 ここにヒントがありました。 要は64bitのwin上で32bitアプリからsystem32(64bit置き場)を見に行くと C:\Windows\SysWOW64(32bit置き場)に差し替えられると。 だから32アプリのTFからsystem32を見に行くとコピーしたはずのcurlが見えない、 64アプリのmaster seekerからsystem32を見るとcurlが見える、explorerからも見える。 という事で32bitアプリはbatから起動するときはSysWOW64に置けばok、 コマンドラインから直接起動したいときはsystem32にも置く。 C:\Windows\SysWOW64にはpath通ってないけど置いているアプリは起動するので、 そういう解釈で良いかと。


Home 更新記録













inserted by FC2 system