タグ付けされた質問 「netcdf」

さまざまなラスターファイル形式の議論や比較ベンチマークを見つけるのに問題があります（たとえば、Rでのデータ分析で使用するため）。特定の形式が高速または低速である理由について誰かが洞察を持っていますか？それとも、違いは最小限にすべきでしょうか？ 特に、ラスター（たとえば、GEOTIFFファイル）を別の形式（たとえば、netCDF）に変換することが、読み取り/書き込みやその他の操作を高速化するために価値があるかどうかに興味があります。

25 raster  geotiff-tiff  r  file-formats  netcdf 

gdal-devメーリングリストからの移行： 2013年9月2日月曜日午後7時9分、David Sheanは次のように書いています。 こんにちはリスト、私は配布用の単一のNetCDFファイルとして同一の投影/範囲/解像度を持つGTiffラスターの時系列をパッケージ化しようとしています。過去1時間、オンラインドキュメントを参照し、gdal_translate、gdalbuildvrt、gdalwarpで遊んでみましたが、成功しませんでした。 既存のgdalコマンドラインユーティリティを使用してこれを行う簡単な方法はありますか？NetCDF Python APIを使用したカスタムソリューションに頼る前に、私は尋ねたいと思いました。 ありがとう。-デビッド 2013年9月3日火曜日、午前10時15分、エティエンヌトゥーリニーは次のように書いています。 あなたが望むのはおそらくgdalの範囲外です。gdal_translateがそれらを単一のファイルに入れるためには、巧妙なメタデータ管理が必要になります... gdal_translateを使用してそれらをすべてnetcdfに変換してから、python-netcdf4（numpy / scipyのものではない）を使用して時間ディメンションにスタックすることをお勧めします。 2013年9月3日火曜日午前7時55分、「Signell、Richard」は次のように書いています。 David、質問をGIS stackexchangeグループ/gis// に投稿する場合、 参考になるサンプルコードを提供します。 -リッチ ===================== 更新日9/3/13 17:04 PDT 入力データセットの1つに対するgdalinfoの出力を次に示します。 gdalinfo 20120901T2024_align_x+22.19_y+3.68_z+14.97_warp.tif Driver: GTiff/GeoTIFF Files: 20120901T2024_align_x+22.19_y+3.68_z+14.97_warp.tif Size is 10666, 13387 Coordinate System is: PROJCS["unnamed", GEOGCS["WGS 84", DATUM["WGS_1984", SPHEROID["WGS 84",6378137,298.257223563, AUTHORITY["EPSG","7030"]], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich",0], UNIT["degree",0.0174532925199433], AUTHORITY["EPSG","4326"]], PROJECTION["Polar_Stereographic"], PARAMETER["latitude_of_origin",70], …

12 python  gdal  netcdf 

特定のシェープファイルを使用して、NetCDFからデータをサブセット化する必要があります。データは、1/4度の解像度での海面温度と海の色です。米国を表す4つのポリゴンがあります。北東大陸棚の大規模な海洋生態系とそのデータを抽出するために使用する必要があるサブコンポーネント。私は1982-2014の月次複合ファイルで作業しているので、このデータ抽出ルーチンは自動化する必要があります。ファイルはすでに[35、45、-80、-60]のおおよその作業領域グリッドにサブセット化されています。 以前は、RでHDF5データファイルをラスターに変換してこの方法で処理していましたが、この方法は非常に効率が悪く、現在のNetCDFファイルを使用するpythonでより良い解決策があると確信しています。 これまでは、GDALとフィオナを使用して形状ファイルを読み込み、NetCDF4を使用してデータファイルをロードしてきました。データをサブセット化する方法がわかりません。私はこれを見つけました： GDAL for Python：NetCDFファイルからサブドメインを抽出しますか？ しかし、私はこれらのポリゴンが確かにそうではない単純なバウンディングボックス以外の何かを使用してnetcdfファイルをサブセット化する方法についての最も曖昧な考えを持っていません。 ポリゴンルーチンのポイントはおそらく機能するのに永遠を要しますが、これらの形状に合うように回転された小さな境界ボックスを使用してデータをサブセット化し、最初の開始点としてポリイン検索を行うことができます。 lon / lat境界ボックスを使用して、曲線のnetCDFファイル（ROMSモデル出力）をサブセット化します。 何か案は？ 編集1： OpenClimateGISパッケージに出くわしました。これは法案に完全に適合しているようです... http://ncpp.github.io/ocgis/examples。 html＃advanced-subsetting

11 python  shapefile  gdal  polygon  netcdf 

私はgdalwarpを使用して、静止からランバート正角に再マッピングしようとしています。入力データはnetcdfにあり、地理座標（度）にあります。再マップしたデータをnetcdfに出力したいと思います。入力netcdfデータに対応するvrtファイルを作成しました。Gdalwarpはnetcdfファイルを出力しますが、出力データはすべてゼロであり、次のエラーを受け取ります。 Creating output file that is 5120P x 5120L. Processing input file netcdf.vrt. ERROR 1: Too many points (441 out of 441) failed to transform, unable to compute output bounds. Warning 1: Unable to compute source region for output window 0,0,5120,5120, skipping. 0...10...20...30...40...50...60...70...80...90...100 - done. 私は次のコマンドを試みました： /usr/bin/gdalwarp -s_srs "+proj=geos +h=35785831 …

11 gdal  coordinate-system  proj  gdalwarp  netcdf 

英国の雨の日数のデータを含むNetCDFファイルがあります。それをGeoTIFFに変換したいのですが、GDALを正しくジオリファレンスできません。以下のgdalinfoからのダンプを参照してください。 「raindays_tmean_abs」変数を示すシングルバンドTIFFが必要です。「lat」および「lon」変数には、英国にデータを配置するための適切な最小値/最大値があるようですが、gdal_translateで変換すると、アフリカの西海岸に到達します。 最初のディメンションが「時間または垂直」ディメンションではないという警告があります。私はgdalがデータが特定の順序であることを期待していることを読んだので、おそらくこれが問題ですが、それを変更する方法がわかりません。 このデータを変換/再投影するにはどうすればよいですか？ gdalinfo NETCDF：RainDays1_1961-1990_LTA_25km.nc Warning 1: dimension #0 (meaning_period) is not a Time or Vertical dimension. Driver: netCDF/Network Common Data Format Files: RainDays1_1961-1990_LTA_25km.nc RainDays1_1961-1990_LTA_25km.nc.aux.xml Size is 39, 52 Coordinate System is `' Origin = (-17.650008352179277,11.329999312758446) Pixel Size = (0.219999614514803,-0.219999998807907) Metadata: axis_0#units= meaning_period#comment=Meaning periods are all months (12) beginning …

10 gdal  coordinate-system  netcdf 

netCDFラスターファイルを取得しましたが、ラスターが構築されている座標系の名前を取得するためのメタデータを取得できませんでした。ラスター自体には座標系が埋め込まれていません。WGS84だけだと思っていましたが、最初はそのように見えましたが、ArcMapをさらに調査したところ、それほど一般的ではないシステムであることがわかりました。表示方法は次のとおりです。 オレンジ色のラスターは、比較のためにここに挿入したWGS84の通常のラスターです。紫色のものは、座標系が不明なラスターです。これが何かの手掛かりはありますか？ 一部の更新：ここでのnetCDFラスタがある：https://www.dropbox.com/s/nottbl9yt6dwss6/sic_average_nclimate.nc?dl=0 私も画像提供者からいくつかのメタデータを取得することができました： netcdf sic_average_nclimate { dimensions: nlon = 361 ; nlat = 90 ; nseas = 4 ; variables: float SIC_Change(nlat, nlon) ; SIC_Change:Title = "Gridded Multi-Model Ensemble Mean Annual Mean Change in Ice Concentration 21C-20C" ; float SIC_Season_Change(nseas, nlat, nlon) ; SIC_Season_Change:Title = "Gridded Multi-Model Ensemble Mean …

10 arcgis-desktop  coordinate-system  netcdf  antarctica 

GCSに正の範囲（0度から360度）がある世界のデータセットを扱うことについてアドバイスを求めています。私が扱っているデータはNetCDF海洋データであり、前述のように正の座標値を持っています。ESRIのArcGIS 10の通常のGCS WGS84で表示すると、-180〜180の範囲に存在する他のデータからオフセットされます。再投影すると、主子午線の周りにギャップが発生します（主にその起源が原因で、場合によってはオフ25度W）。私の考えは、正の値を持つカスタムの投影/座標系を作成し、他の世界のデータセットがその場でうまく再投影されることを期待することです。誰かがこれで何か問題を見たり、他の解決策を持っていますか？これが理にかなっているといいのですが。よろしくお願いします。 **更新**これは、GCSの通常のCRSを示すために経緯線が上にある国データセットのスクリーンショットです。NetCDFデータをそのままインポートするだけでインポートされますが、値は本初子午線の20.5度東まで開始されません。 通常のGCS http://grafa.co/rnd/img/GCS_Normal.png NetCDFのCRS（実際には同じ）を使用することを選択した場合、ワールドデータが定義されていれば、オンザフライで再投影されます。経緯線が未定義であるため、再投影されないことに注意してください。 再投影されたGCSの一種http://grafa.co/rnd/img/GCS_Other.png しかし、すべてを負の値で通常のGCSに再投影しようとすると、それは世界中のデータのフラットマップをラップするようなものであり、それが本初子午線に当たると消えます。 再投影されたGCSの一種http://grafa.co/rnd/img/reprojected.png メタデータに記載されているように、0〜20.5の値はありません。しかし、残りのデータの値をギャップに表示できないのはなぜですか？ラスターツールでシフトを試しても無駄になりました。

8 arcgis-10.0  coordinate-system  tools  latitude-longitude  netcdf 

かなり簡単に思えるようなことをやろうとしています。私はftp://eclipse.ncdc.noaa.gov/pub/OI-daily-v2/NetCDF/2011/AVHRR-AMSR/からnetcdfファイルを取得し、4096x4096 pngに変換してタイル表示できるようにしていますグーグルマップで使用するためにそれを。私は次のコマンドを使用してきましたが、東と西の境界に常に空白の領域が作成されるようです。 /usr/local/bin/gdal_translate -a_srs EPSG:4326 -outsize 4096 4096 -a_ullr 0 90 360 -90 NETCDF:"input.nc":sst -of netCDF output.nc /usr/local/bin/gdaldem color-relief output.nc -b 1 -alpha colorscale.txt -of PNG output.png /usr/bin/convert output.png -transparent #FFFFFF output.png 私はこれに間違った方法でアプローチしていますか？間違ったツールを使用していますか？ FWIW-gdal_translateはv1.8.0です 前もって感謝します。 更新： Dija（私の同僚）からの以下の "Answer"は、実際には質問自体に対するコメントへの応答です。 更新 コメントではなく誤って回答を追加しました。ここに移動します。 私はここで体重を測ると思いました。私はこの問題にしばらく取り組んできました。私はプロセスの多くの反復を試みてきました。これらの画像を実際に4096x4096にスケーリングしました。つまり、画像をネイティブサイズのままにすると、（このデータセットの）子午線と他のデータセットの180番目の子午線では、1440x720のギャップが大きくなります。出力画像を256の倍数にスケーリングして（Googleにうまくフィットさせるため）、さまざまな結果を得ました。 1536x768にスケーリングすると、ギャップは0子午線の右側まで表示されます。1280x640に拡大すると、左側になります。そのままにしておけば、かなり分割されてしまいます。 私はgdaldemが吐き出す基本画像を撮り、それを半分にカットし、エッジを一致させました...それらは完全に整列しています。これにより、gdal2tiles.pyで奇妙なことが起こっていると思います 私は自分のタイラーを書いて、ギャップが残っているかどうかを確認するために、画像を緩める準備をしています。 スクリーンショットをいくつか組み合わせて、話している内容とギャップの方法を示し、タイラーの機能についてレポートします。 ご意見をお寄せいただきありがとうございます。ありがたいです。 更新2オリジナルのラスターに対して作成したマップティラーを実行しましたが、ギャップがなくても問題なく動作しました。gdal2tiles.pyが問題のようです。180番目の子午線に接する最後のタイルに透明なエッジを導入します。

8 google-maps  gdal  netcdf