GISのラスターおよびベクターデータとは何ですか？
回答:
ベクターデータ
利点：データは、一般化せずに元の解像度と形式で表現できます。通常、グラフィック出力は、より見た目が美しい（従来の地図表示）。ハードコピーマップなどのほとんどのデータはベクター形式であるため、データ変換は不要です。データの正確な地理的位置が維持されます。トポロジーの効率的なエンコードを可能にし、その結果、トポロジー情報を必要とするより効率的な操作、例えば近接、ネットワーク分析を可能にします。
欠点：各頂点の位置を明示的に保存する必要があります。効果的な分析を行うには、ベクトルデータをトポロジ構造に変換する必要があります。多くの場合、これは集中的な処理であり、通常は大規模なデータクリーニングが必要です。また、トポロジは静的であり、ベクターデータの更新または編集にはトポロジの再構築が必要です。操作および分析機能のアルゴリズムは複雑であり、処理が集中する場合があります。多くの場合、これにより、多数の機能など、大規模なデータセットの機能が本質的に制限されます。標高データなどの連続データは、ベクター形式で効果的に表現されません。通常、これらのデータレイヤーには、実質的なデータの一般化または補間が必要です。ポリゴン内の空間分析とフィルタリングは不可能です
ラスターデータ
利点：各セルの地理的位置は、セルマトリックス内の位置によって暗示されます。したがって、左下隅などの原点以外は、地理座標は保存されません。データ保存技術の性質上、データ分析は通常、プログラムが簡単で実行が迅速です。ラスターマップの固有の性質（1つの属性マップなど）は、数学的モデリングと定量分析に最適です。林分などの離散データは、標高データなどの連続データと同様に適切に収容され、2つのデータタイプの統合を促進します。グリッドセルシステムは、ラスターベースの出力デバイス（静電プロッター、グラフィックターミナルなど）と非常に互換性があります。
短所：セルサイズによって、データが表示される解像度が決まります。セルの解像度に応じて、線形フィーチャを適切に表現することは特に困難です。したがって、ネットワークリンケージを確立するのは困難です。大量のデータが存在する場合、関連する属性データの処理は面倒な場合があります。ラスターマップは、本質的にエリアの1つの属性または特性のみを反映します。ほとんどの入力データはベクター形式であるため、データはベクターからラスターに変換する必要があります。処理要件の増加に加えて、一般化と不適切なセルサイズの選択により、データの整合性に関する懸念が生じる可能性があります。グリッドセルシステムからのほとんどの出力マップは、高品質の地図作成のニーズに適合していません。
ピクセルと座標 Rasterマップを考えるとき、最初に考えたのは衛星画像です。都市部の詳細な衛星画像のほぼすべてのピクセルには、一意の情報を含めることができます。ウェブ・マップ（の典型的変異体における単一タイルメルカトル緩く「という球状メルカトル」または「ウェブメルカトル」とによって支持グーグル、ビング、ヤフー、OSMおよびESRI）は、典型的には256×256 = 65,536画素を有し、各ズームレベルには（2 ^ zoom * 2 ^ zoom）タイルがあります。私がベクターを考えるとき、私はポリゴンとラインを考える。たとえば、都市全体（潜在的に数百万のラスタータイル）のゾーニング境界を詳述するシェープファイルには、65,000のベクターシェイプしかありません。
正確なスケーリング ラスターの固定ピクセルとベクター（座標マップ）の最も明らかな違いは、あなた（そしておそらくほとんどの読者）が既に知っているようです。ベクターデータには座標パターン（ポイント、ポリゴン、ラインなど）が含まれているため、ベクター描画（およびマップ）はピクセルよりも高い忠実度でスケーリングできます。画像のアーティファクトをもたらす平滑化アルゴリズム。
画像圧縮と構造圧縮 実際には、ほとんどの画像は100％固有のピクセルを持たないため、より小さなデータパケットに圧縮できます。また、多くのベクターファイルには、多くの低詳細ズームレベルでは不要な詳細が含まれています。画像圧縮はよく知られた非常に効率的なプロセスであり、ほぼすべてのコーディングライブラリがこの作業を行うためのクラスを組み込んでいます。ベクトル座標圧縮、または「ジオメトリの単純化」は少し一般的ではありません（GISは一般に一般的な画像操作よりも一般的ではないため）。私の経験では、画像圧縮について考える時間（単純にオフまたはオンにする）に0時間近く費やし、空間圧縮について考える時間はかなり長くなります。例についてはDouglas Peucker Algorithmを確認するか、QGISを試してみてください およびいくつかの国勢調査の境界ファイル。
クライアント側とサーバー側のレンダリング 最終的に、コンピューターで表示されるすべてのものが、特定の解像度（ズームレベル）で画面上のピクセルにレンダリングされます。多くの場合（特にWeb上で）、これらのピクセルをユーザーの前にできるだけ効率的に配置することが課題です。米国勢調査トラクト＆ブロックグループのシェイプファイルWebブラウザでベクターデータとしてレンダリングするには「大きすぎる」ベクターデータセットの境界を超えているため、特に興味深いものです。対照的に、米国の郡はベクターダウンロードとして最新のブラウザでほとんどレンダリングできません。米国国勢調査のブロックグループのベクターシェイプファイルは、複数のズームレベルで米国全体をカバーするようにレンダリングされたラスタータイルセットよりも確実に小さくなりますが、ブロックグループシェイプファイルは大きすぎて（1 GBに近い）Webブラウザーがオンデマンドでダウンロードできません。Webブラウザーがファイルをすばやくダウンロードできたとしても、膨大な数の図形をレンダリングする場合、ほとんどのWebブラウザーは（フラッシュを使用していても）非常に低速です。そのため、大きなベクターデータセットを表示するには、多くの場合、Webブラウザーに送信するためにそれらを圧縮画像に変換する方が適切です。
いくつかの実用的な例 数日前に、Googleマップで大きなデータセットをレンダリングするという同様の質問に答えました。今日のニューヨークタイムズなどで使用されている「ベストプラクティス」の質問と詳細な分析をご覧いただけます。
数年前、フラッシュの重いクライアント側のベクトルレンダリングから、圧縮された画像タイルを純粋なhtmlおよびJavaScriptに配信するサーバー側のベクトルレンダリングに移行することを決定しました。Html + Raster（サーバー生成イメージタイル）とFlash + Vector（クライアント側の重いレンダリング）のいくつかのバージョンを含むマップギャラリーがあります。
この写真は、データのラスター対ベクトル表現の良いアイデアを提供します。
Rastorでは、検討中の領域は等しい正方形とそれに割り当てられた特性に分割されます。したがって、ラスターのデータ構造を作成することを検討する場合、それは2D配列であり、各x、y座標は領域内の正方形を参照し、建物、道路、植生、水域などの特定の事前定義された特性を持つことができます
ベクターでは、データはポイント、ライン、ポリゴンという用語で表されます。したがって、観光スポットはPOINT（x、y）として表され、川または道路は線ストリング（一連の接続されたポイント）として表され、湖またはスタジアムなどはポリゴンとして表されます（ポイントのリスト閉じた領域を形成する）-詳細はこちら：https : //en.wikipedia.org/wiki/Well-known_text
画像はウェブ検索からのもので、その時点でスクリーンショットを撮りましたが、ウェブ上の元のソースへのリンクはありません！そのことをおologiesびします！
しかし、この回答がGISの初心者に説明するのに役立つことを願っています：D
ラスターデータを特別な種類のベクターデータと考える方が適切です。ベクターデータでは、マップ上の線は特定の現象によって決定されます。ラスターデータでは、この描写は、マッピングしようとしている現象とは無関係の任意のグリッドによって定義されます。通常、このグリッドは、特定のセンサーが情報をキャプチャする方法の結果です（カメラなど）。ただし、すべての場合において、ラスターデータはベクトルで表すこともできます。