タグ付けされた質問 「file-formats」

コンピュータファイルに格納するために情報をエンコードする標準的な方法


5
シェープファイルよりも空間ライトを使用する利点は?[閉まっている]
空間ファイルには形状ファイルの制限がなく、移植性もあるため、空間ファイルの方が形状ファイルよりも有用であることがわかりました。ここで多くの人々がデータを交換するためにシェープファイルを使用しており、専門家でさえこの新しいフォーマットについては知りません。 シェープファイルよりも空間ライトを使用する利点は何ですか? シェープファイルの代わりに使用できますか? ポータブルである、つまりUSBスティックを使用して交換できる形式のみに注目してください。GML、GeoJSON、KML、CSVはオプションではなく、GISで直接編集することはできません。 更新:5年以上が経過しており、新しい開発は空間ライトに関連するジオパッケージに向けられています。 だから今質問は、GEODATABASEよりもGEOPACKAGEを使用する利点に似ていますか?

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

3
GeoTIFFピラミッド/概要はどのように標準化されていますか?
ピラミッド/概要はGeoTIFF標準の一部ではありませんが、多くのツールがピラミッド/概要の作成をサポートしています。たとえば、vips / nip2、Orfeo Toolbox(otb)、およびossimは、これらを作成するための何らかのサポートを約束します。しかし、それらがすべて他の人がサポートする形式でファイルを作成するかどうかはわかりません。ツールのドキュメントを調べても、それについては何も言及されていません。 vipsは地理空間ツールではなく、エンドユーザーフレンドリーなドキュメントは見つかりませんでしたが、IIPImageのドキュメントでは「Tiled Pyramidal TIFF」のサポートについて言及されています:http : //iipimage.sourceforge.net/documentation/images/ otbは、「Multi Resolution Pyramids」の形式や仕様については何も言及していません:https : //www.orfeo-toolbox.org/CookBook/CookBooksu65.html ossimは、「解像度の低下したデータセット」のさまざまな出力形式をサポートしていると言いますが、実際の意味はわかりません:https : //trac.osgeo.org/ossim/wiki/img2rr GDALは、その「概要画像」に関することも実際には指定していません:http : //www.gdal.org/gdaladdo.html したがって、それらはすべてピラミッド/概要を持っていますが、それらが相互互換性があるかどうかは明確ではありません。 より一般的なページでは、次の引用を見つけました。 http://iipimage.sourceforge.net/documentation/images/は言う タイル型多重解像度(またはタイル型ピラミッド型)TIFFは、タイル型のマルチページTIFF画像であり、各解像度はTIFF内の個別のレイヤーとして保存されます。これは標準のTIFF拡張機能であり、Photoshop、GIMP、VIPS、ImageMagickなどのほとんどの画像処理アプリケーションでサポートされています。libtiffコーデックライブラリは、このような画像を完全に読み書きすることもできます。 それは誰もが使用するものですか? 米国議会図書館はまた、いくつかの情報を持っている:http://www.digitalpreservation.gov/formats/fdd/fdd000237.shtml 彼らは注意してください。 異なるアプリケーションによって作成されたPyramid TIFFファイルは、必ずしも同じ構造ではありません。特に、JHOVEによる分析とImageMagickの識別コマンドから判断すると、AdobeのPhotoshopとImage Magickは異なる内部TIFF構造を持つファイルを生成します。どちらの場合も、TIFFを処理できるほとんどのソフトウェアは、問題なくプライマリ(フルサイズ)TIFFを認識するようです。 それで、それらのフォーマットはどこかで標準化され、指定され、文書化されていますか?他のツールと互換性のある方法でそれらを生成できるツールを見つけるにはどうすればよいですか?概要/ピラミッドに地理空間タグがありますか、それともソフトウェアを使用して画像データにタグを作成できますか?

3
PythonとGDALを使用してファイルジオデータベースのフィーチャクラスにアクセスする方法は?
Python + GDALを使用して、ESRIファイルジオデータベースのベクターデータセットにアクセスしようとしています。ファイルジオデータベースAPIを使用してGDALを正常にコンパイルしました。FileGDBドライバーは、 ogrinfo --formats FileGDBドライバーを表示して ogrinfo myfilegdb.gdb データベースの内容に関する正しい情報を教えてくれます。 ただし、Pythonでコンテンツ自体にアクセスする方法はわかりません。シェープファイルにアクセスするには、次のように書きます。 driver = ogr.GetDriverByName('ESRI Shapefile') ds = driver.Open('shapefile.shp', 0) FileGDBフィーチャクラスにアクセスするとき、次のコマンドを使用すると仮定します。 driver = ogr.GetDriverByName('FileGDB') ds = driver.Open('myfilegdb.gdb/feature_class', 0) しかし、これはデータセットを特定/特定できないため、機能していないようです。ESRI FileGDBから個々のフィーチャクラスを呼び出す方法を知っている人はいますか。 Ubuntu 12.04 x64でPython 2.7、GDAL 1.9.1、filegdb api 1.2を使用しています。提案をありがとう!

3
Googleの新しいベクターマップタイルのワイヤー形式は何ですか?
Googleは最近、モバイルマップ用の新しいベクトル地図作成をリリースしました。ここで誰かが送信に使用するワイヤー形式についての洞察を持っているかどうか興味がありますか?私には、長年にわたっていくつかの形式を試してきましたbencode、BSON、の変異体WKTとWKB、およびgzip圧縮された、限られた精密にGeoJSON私はわかりやすさとファイルサイズで最高のトレードオフであることがわかってきました。Googleが何を決めたのか知りたいのですが、テストするAndroidデバイスがありません。

2
Esriの.ascファイルを理解していますか?
ArcGISヘルプを読む:サポートされているラスターデータセットファイル形式で、16ビットの符号付き整数(離散データ用)と32ビットの浮動小数点ファイル(連続データ用)の両方について、ASCIIグリッドファイルタイプが単一のファイル拡張子.ascでアドレス指定されていることを読みました)。 Esri Grid形式のセクションで次のように述べています。 グリッドは、Esri固有のラスターデータストレージ形式です。グリッドには、整数と浮動小数点の2つのタイプがあります。 次に、両方の形式について説明します。 私の混乱は、次のヘルプセクションEsri ASCIIラスターフォーマットで発生します。そこでは、浮動小数点形式のみに言及しています。だから、私は知りたい: 離散データの16ビット符号付き整数形式も、グリッド以外にラスター形式と見なされますか? 「ESRIグリッド形式-グリッドデータストレージ」セクションでは、.bnd、.hrdなどの他の拡張機能をいくつか挙げています。16ビットの符号付き整数の.ascファイルは、Esriの離散データグリッド形式のASCIIバージョンですか? この質問の動機は、拡張子が.ascのファイルを説明/理解することです。

1
標準化された空間データ交換フォーマットの次の大きなものは?
数か月前、2012年後半に、地理的/空間的データを共有するための新しい標準を設計するためのグループでの協調的な取り組みについて読みました。すべてのデバイスとプラットフォーム間でデータを広く共有するための選択肢として、Esri シェープファイルの表示年齢(20年以上)の事実上の標準を置き換える可能性を持っているか、目指しています。最も差し迫ったシェープファイルの制限に対処するだけでなく、この新しいものにはラスターとメタデータも組み込まれています。 私が覚えていないこの重要なものはSpatiaLiteではありません-未来のシェイプファイルですか?または、シェープファイルを置き換える試みはありますか?しかし、その周りを渦巻く会話の一部は似ていました。今日はこれを追跡するためにかなりの時間を費やしましたが、私の検索フーはタスクに応じていないことが判明しました(これは将来にとって良い兆候ではないかもしれません)。 すべてのワークフローに大きな影響を与える可能性のあるこのとらえどころのないプロジェクトの名前は何ですか?(それが図面から外れると仮定すると、主は私たちが何かを必要としていることを知っています。)そして、どのように、どこで関与するか、少なくともそれを追跡しますか?

2
グリッドvs TIF vs IMG
グリッド、TIF、およびIMGは、ラスタファイルの3つの形式です。 ArcGIS Desktopでは、明らかに違いはありません。 これら3つの形式の違いは何ですか?

5
最も普及しているGIS形式?
最も普及しているGIS形式はどこで確認できますか? たとえば、GISファイル形式の Wikipediaページには、4つの広範なカテゴリがあり、それぞれに多くの一般的な形式があります。 ラスター形式(13の形式がリストされています) ベクター形式(19) グリッド形式(4) その他の形式(5) これは目を見張るような選択肢の配列であり、それぞれに存在理由があります。 ただし、一般的な形式に関しては、最も普及している形式は何ですか? 編集:広範には、GISデータを使用しているすべての企業からGISデータを使用している企業がランダムに選択された場合に遭遇する上位3つの形式を探しています。

5
Open Dataの配信に最適なデータ形式はどれですか?
ロックされています。この質問とその回答はロックされています。なぜなら、質問はトピックから外れていますが、歴史的に重要だからです。現在、新しい回答やインタラクションを受け入れていません。 オープンデータの配信を検討する場合、さまざまなデータ形式(パフォーマンス、ファイルサイズなど)の長所と短所は何ですか? 私たちの組織は、データをオープンデータとして公開したいと考えています。ただし、使用するデータ形式について明確な考えはありません。もちろん、データ形式が「オープン」であればあるほど、使いやすくなります。 以下のタイプを考慮した場合、どのデータ形式が最も「オープン」であり、したがってオープンデータの配布に最も有用ですか? ラスターデータ(考えている:GeoTIFF、Erdas IMGを想像しますか?) ベクターデータ(考えているのは、GML、CSV、ESRI Shapefile、DXF?) 表形式データ(私は考えています:CSV?) 3Dデータ(考えているのはCityGML?) 3Dポイントの可能性/ LIDAR(私は考えています:LAS?) ここで何かを忘れていますか? また、オープンデータ形式に関するドキュメントがある場合は、共有したいと思います。


3
プレーンテキスト形式の国境データはどこにありますか?(XML、JSON、CSVなど)
世界のすべての国の国境を表すいくつかのデータを取得しようとしています。このデータは非常に正確である必要はなく、コンピューター画面に国を描くことです。私は少しの研究を行い、このデータがさまざまなプログラムで開かれるかどうかにかかわらず、バイナリ形式につまずき続けました。これは良いリソースですが、私には使用できないものの例です。 可能であれば、バイナリ形式のパーサーを記述する必要はありません。したがって、私の質問は2つあります。 プレーンテキストで簡略化された国境のリソースはありますか?(XML、JSON、CSVなど) そうでない場合、Web全体で見つかったバイナリデータをこれらの形式でエクスポートできるプログラムはありますか?

1
ENVI(クラシック)ROIのバイナリ形式は何ですか?
私は、ENVI / IDLユーザーでいっぱいのオフィスのPythonistです。ギャップを埋めるためのツールをいくつか作成しましたが、大きな障害の1つはENVIクラシック.roiファイルであり、同僚がよく使用します。 テキストベースの形式は解析が容易なので、ENVI 5 ROIをPythonに簡単にインポートできます。ただし、グループ内のデータ交換の大部分を構成するENVIクラシック.roiファイルのバイナリ形式については、あまり意味がありません。これらのファイルを読み書きするコードはありますか、それについてどう考えますか? ENVI 5をやり取りするたびに起動するのは少し面倒です-可能であれば、ソースで問題を解決したいです。


弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.