CBS verilerini içeren dosya ve klasörler için iyi bir sınıflandırma veya adlandırma kuralı nedir? [kapalı]

Şirketim son 8 yılda yaklaşık 30 TB CBS verisi topladı ve kendimi her zaman aşağıdaki soruları sorurken buluyorum:

1. Belirli bir coğrafi bölge için ne tür verilerimiz var?
2. Bu verilerle ilgili ayrıntılar nelerdir (ör. Piksel başına metre cinsinden çözünürlük)?
3. Aslında kullanabilmem için sabit diskte veriler nerede bulunur?
4. Verileri zaten işledik mi, yoksa kaynaktan değiştirilmemiş bir biçimde mi?

Şimdiye kadar dahil olmak üzere, uygun bir klasör ve dosya sınıflandırması / hiyerarşisi oluşturarak bu soruları yanıtlamaya çalıştım. Herkes, dosyaları ve klasörleri kullanarak GIS verilerini düzenlemenin bazı anlaşılabilir, belki de standart yollarıyla ilgili fikir / önerileri var mı?

Ayrıca bir veritabanı kullanmanın şirketime nasıl fayda sağlayabileceği hakkında daha fazla bilgi edinmeye açıkım; biz yazılım geliştiricileriz, CBS uzmanları değiliz, bu yüzden kullanım kolaylığı için CBS verilerinin depolanması / düzenlenmesi sorununa en iyi nasıl yaklaşılacağına dair eğrinin biraz gerisinde olduğumuzdan şüpheleniyorum. Jeo-uzamsal verileri yönetmek için en iyi uygulamalar sorusunu gördüm, ancak coğrafi veri tabanlarına çok aşina olmadığım için cevaplardan sadece marjinal kullanım sağlayabiliyordum.

GÜNCELLEME: Bu geçen hafta CBS veritabanlarını okumak için epey zaman geçirdim ve PostGIS'i tanımaya başladım. Uzun vadede, JasonBirch tarafından jeo-uzamsal verileri yönetmek için en iyi uygulamalarda önerilen bir veritabanı artı meta veri sunucusunun istihdamına doğru ilerleyeceğimizi düşünüyorum .

Aslında verileri düzenlemeye veya bir harita geliştirmeye çalışıyorsanız, aktif olarak üzerinde çalıştığınız verileri başladığınız verilerden ayrı tutmanız gerekir. Bir proje başlattığımda, veri türü (DEM, Orthophoto, Hydrology, vb.) Tarafından adlandırılan alt dizinleri ile bir SourceData klasörü oluşturmak Bu yalnızca başvuru için kullandığım tüm katmanları tutacak. Üzerinde çalıştığım tüm veriler, Working adlı farklı bir klasöre kopyalanacaktır . Çalışma klasörü verileri, MXD'leri ve genellikle projenin bir aşamasıyla (MXD'ler, RoadEdits, Teslimat vb.) İlişkilendirilen alt dizinlerde değiştirdiğim veya oluşturduğum diğer her şeyi içerir

Gerçek CBS verilerine ek olarak, müşterinizden / dahili istemcinizden / profesörünüzden herhangi bir belgeyi tutmak için bir İletişim veya Özellikler klasörü oluşturmalısınız. Bu, daha sonraki bir tarihte projeye geri döndüğünüzde meta veri olarak işlev görmenin yanı sıra, başkalarının ne olması gerektiğini görebileceği merkezi bir konum oluşturmak için de kullanılabilir.

Bana öyle geliyor ki, bu bilgiyi saklamak için bir dizi meta veriye ve bilgiye dayanarak veri ayıklamanıza izin veren meta verileri kullanan bir geri alma sistemine ihtiyacınız var.

Maksimum birlikte çalışabilirlik için OGC Katalog Hizmetini destekleyen bir çözüm istediğinizi düşünüyorum. Meslektaşlarının Deegree kullandığını gördüm - tabii ki kontrol etmeniz gereken başka çözümler de var.

İşte Deegree'yi yazılımımıza nasıl bağladığımıza bir örnek (canlı demo şu anda bakım için kapalı - bilmiyordunuz! - ancak gelecek hafta tekrar gelmeli)

Dosya adlandırmaya gelince, bir katalog hizmeti ve dağıtım mekanizmanız varsa, dosyaların adı ve nerede oldukları hakkında daha az sorun vardır. Aksi takdirde veriyi nasıl aradığınıza bağlı olduğunu düşünüyorum. Öncelikle coğrafi alanı veya veri türünü daraltarak başlıyor musunuz? Bu, hiyerarşinin verileri döşemelere bölerek, ardından döşemelik veri türlerini başlatarak başlayıp başlamadığını belirler; veya her biri bir dizi döşemeye sahip olan veri türlerine bölerek.

Tabii ki, uzamsal bir veritabanı ile verileri karolara bölme konusunda aynı sorunlarınız yoktur, bu nedenle genellikle tercih edilen bir yöntemdir - son kullanım uygulamasının bu tür verileri kullanarak desteklemesini sağlamak.

Ben seçsin SpatiaLite bir olan tek dosya veritabanı tüm şekil dosyaları, rasterları ve tablolar ekleyebilirsiniz. Sonra ilişkisel bir SQL veritabanı olarak, öznitelikler ve dosyalar arasında gerekli tüm eylemleri (birleştirme, seçme, birleştirme, birleştirme, bölme vb.) Yapmak için SQL sorgularının gücüne sahipsiniz.

SpatiaLite , daha fazla otomasyon için Python gibi programlama dillerinden de erişilebilir. Gökyüzü, limittir.

SpatiaLite Belgeleri ve eğiticileri

"Map name or theme - Metadata comments.doc" başlıklı Word belgeleri oluşturmakta fayda var. Her bir harita ve / veya veri kümesi teması için büyük düzenlemeleri ve iş akışlarını kronolojik sırada (YYYY-AA-GG) belgeleyin. Bir veri kümesinin geçmişini bulmanız gerekiyorsa: i) Tarihsel referanslar veya potansiyel kaynak dosyaları olarak yararlı olan ilgili dosyaların oluşturulduğu / değiştirildiği tarihi ekleyin. Genel benzerliklere veya farklılıklara (yani bir haritanın veya veri kümesinin her sürümündeki yeniliklere) dikkat ederken her dosyanın içeriğinin kısa bir özetini (katman adları, kayıt sayısı) ekleyin. "- Meta veri yorumları" dosyasını, haritanın veya veri kümesinin en son sürümüyle aynı çalışma klasöründe tutun. Haritanın veya sürümlerin eski sürümlerini Arşiv alt klasörüne yerleştirin. Üç aşamalı süreç yazılım geliştirme için iyi çalışır, veritabanı geliştirme ve dosya yönetimi: 1) Geliştirme (& belge); 2) Test (ve belge); 3) Yayınlayın (meta veriler dahil). 1) Çalışma klasörü; 2) Arşiv alt klasörü; 3) Yayınlanan sürüm.