GISデータを含むファイルおよびフォルダーの適切な分類または命名規則とは何ですか?[閉まっている]


13

私の会社は過去8年間で約30 TBのGISデータを収集しており、常に次の質問をしていることに気づきました。

  1. 特定の地域についてどのような種類のデータがありますか?
  2. そのデータに関する詳細は何ですか(たとえば、ピクセルあたりのメートル単位の解像度)。
  3. 実際に使用できるように、データはハードドライブのどこにありますか?
  4. データはすでに処理されていますか、またはソースからの変更されていない形式ですか?

現在まで、適切なフォルダとファイルの分類法/階層を考案することにより、これらの質問に対処しようとしました。ファイルやフォルダを使用してGISデータを整理するための、おそらく標準的な方法でさえ、誰かが理解できる、または提案しているものはありますか?

また、データベースの使用がどのように私の会社に利益をもたらすかについて、もっと学ぶことができます。私たちはGISの専門家ではなくソフトウェア開発者であるため、使いやすさのためにGISデータの保存/整理の問題にどのようにアプローチするのが最適かという点で、私たちはかなり遅れていると思います。地理空間データを管理するためのベストプラクティスの質問を見ましたが、ジオデータベースにあまり慣れていないため、回答からわずかな使用しか引き出すことができませんでした。

更新:先週、GISデータベースについてかなりの時間を読んで、PostGISに慣れ始めました。長期的には、地理空間データを管理するためのベストプラクティスで JasonBirchが推奨しているように、データベースとメタデータサーバーの使用に移行すると考えています


7
この質問をチェックアウト: gis.stackexchange.com/questions/2976/...
デレクSwingley

おかげで、その質問は間違いなく関連しており、いくつかの良い背景情報を提供します。
Sipp

回答:


2

実際にデータを編集したりマップを開発しようとしている場合は、作業中のデータを開始時のデータとは別に保管する必要があります。プロジェクトを開始するとき、データのタイプ(DEM、Orthophoto、Hydrologyなど)で名前が付けられたサブディレクトリを使用してSourceDataフォルダーを作成します。これにより、参照用に使用しているすべてのレイヤーが保持されます。作業中のデータは、Workingという別のフォルダーにコピーされます。Workingフォルダーには、データ、MXD、およびプロジェクトのフェーズ(MXD、RoadEdit、Deliveryなど)に通常相関するサブディレクトリで変更または作成するその他のものが保持されます。

実際のGISデータに加えて、CommunicationsまたはSpecificationsフォルダーを作成して、クライアント/内部クライアント/教授からのドキュメントを保持する必要があります。これは、後日プロジェクトに戻ったときにメタデータとして機能し、他の人が何が起きているのかを誰でも見ることができる集中管理された場所を作成します。


1
良い点; 当社はソフトウェアが使用するマップを作成し、「生の」データと「作業中の」データを「最終的な」データから分離するためのフォルダースキームを既に開発しています。問題の1つは、最終マップの元の基礎として使用された生データのセットを追跡することです。「仕様」フォルダに対するあなたの提案がそれに対処するようです。作成するマップごとに、マップの作成に使用された未加工のデータソース(現在行っていないこと)を必ず確認してください。ヒントをありがとう!
シップ

1

この情報を保存するにはメタデータのセットと、メタデータを使用して情報に基づいてデータを抽出できる検索システムが必要なようです。

相互運用性を最大限に高めるには、OGCカタログサービスをサポートするソリューションが必要だと思います。同僚がDeegreeを使用しているのを見ました -もちろん、チェックすべき他のソリューションもあります。

Deegreeをソフトウェアに結び付けた例を次に示します(ライブデモは現在メンテナンスのためダウンしています-わかりません!-来週またバックアップする必要があります)

ファイルの命名については、カタログサービスと配信メカニズムがあれば、ファイルの名前と場所に関する問題はそれほどありません。それ以外の場合は、データの検索方法に依存すると思います。最初に、地理的エリアまたはデータのタイプを絞り込むことから始めますか?データをタイルに分割してから階層を開始するかどうかを決定し、次にタイルごとのデータの種類を決定します。または、それぞれをタイルのセットを持つデータのタイプに分割します。

もちろん、空間データベースでは、データをタイルに分割することに関して同じ問題はありません。そのため、多くの場合、これは優先的な方法です。


提案をありがとうマーク。ここにはいくつかのコンポーネントがあることを示唆しているようです:メタデータ自体(XMLファイルなど)、ユーザーからの特定のメタデータの要求に基づいてデータを見つける方法を知っている検索システム(Deegree?)、データとメタデータの両方を保存するストレージバックエンドコンポーネント(PostGISなど)。正確ですか?
シップ

1

単一ファイルのデータベースであるSpatiaLiteを選択しますすべてのシェープファイル、ラスター、およびテーブルを挿入できるです。次に、リレーショナルSQLデータベースとして、属性とファイル間で必要なすべてのアクション(結合、選択、マージ、結合、分割など)を実行するSQLクエリの力を利用できます。

SpatiaLiteは、Pythonなどのプログラミング言語からもアクセスできるため、より高度な自動化が可能です。空は限界です。

SpatiaLiteのドキュメントとチュートリアル


0

「マップ名またはテーマ-メタデータcomments.doc」というタイトルのWord文書を作成すると便利です。各マップおよび/またはデータセットテーマの主要な編集とワークフローを時系列(YYYY-MM-DD)で文書化します。データセットの履歴を把握する必要がある場合:i)履歴参照または潜在的なソースファイルとして役立つ関連ファイルの変更日/作成日を含めます。一般的な類似点または相違点(マップまたはデータセットの各バージョンの新機能)に注意しながら、各ファイルの内容(レイヤー名、レコード数)の簡単な要約を含めます。「-メタデータコメント」ファイルは、マップまたはデータセットの最新バージョンと同じ作業フォルダーに保存してください。古いバージョンのマップまたはデータをArchiveサブフォルダーに配置します。3段階のプロセスはソフトウェア開発に適していますが、データベース開発とファイル管理:1)開発(&ドキュメント); 2)テスト(&ドキュメント); 3)公開(メタデータを含む)。1)作業フォルダー。2)サブフォルダーをアーカイブします。3)公開バージョン。

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