Shapefile verilerini veritabanında merkezileştirme


13

Şu anda Postgres / PostGIS ile bunu deneyen tek bir veritabanı platformunda birleştirmeye başlamak istediğim çeşitli farklı CBS projelerinden yüzlerce şekil dosyası var.

Verilerin neredeyse hiçbiri standartlaştırılmamıştır - bu, aynı veri türlerinin çoğunda olduğu anlamına gelir , ancak belirli özellik adları / türleri eşleşmez.

Bununla nasıl başa çıkmalıyım? Her bir şekil dosyasını önce (örneğin Hydro_line, transport_line, Hydro_poly standartları, vb.) Geçirmek için standart bir model geliştirmeli miyim?

Bir alternatif, her şekil dosyasını Postgres'e ayrı ayrı içe aktarmaktır, bu nedenle her shp veritabanında bir tablo haline gelir, ancak performans ve organizasyon açısından bundan emin değilim. Kaçınılmaz olanı geciktirmek gibi geliyor ...

Bu yıldırıcı görevle başa çıkmak için herhangi bir tavsiye var mı?

Yanıtlar:


7

Mekansal ETL yazılımlarına (Özü - Dönüştür - Yük) bir göz atın, bu tür görevlere adanmışlardır. En bilinen FME Safe gelen, ancak bazı açık kaynak (kısmi) alternatifleri artık kullanılabilir gibi SDI (Mekansal Data Integrator) ve GeoKettle .


2
Önceki bir soruda bir karşılaştırma istedim, bu yüzden bu rotaya giderseniz lütfen bir yazma yapın. gis.stackexchange.com/questions/5049/spatial-etl-comparisons
RyanKDalton

FME'nin deneme sürümünü aldım ve hem SDI hem de GeoKettle'ı yükledim. Onları deneyeceğim ve onları anlamlandırabiliyor muyum. FME çorba-fındık çözümüne benziyor, ancak önce öğrenme eğrisini aşmam gerekecek :).
colemanm

1
@ colemanm- Bu konuda ne yaptınız? Hangi ürünü en kullanışlı buldunuz?
RyanKDalton

6

alo

İlk olarak PostGIS'e aktarırdım. Tek tek tablolara birden çok şekil yüklemek için araçlar vardır. QGIS tükürük uzantısı biridir. PostGIS bagajındaki veya deneysel ikili dosyalardaki yeni grafiksel shp2pgsql başka bir alternatiftir. Veya shp2pgsql ile bir toplu komut dosyası yazabilirsiniz.

Oradan başlıyorum, her şeyi orijinal ya da bunun gibi bir şemaya aktarırdım. Sonra verileri yapılandıracağım. Uygun olduğu durumlarda tablolarda birleştirme.

Böyle yapmakla ilgili güzel bir şey, bu dönüşümleri yapmak için kullandığınız tüm sorguları kaydederseniz verilerinizin geçmişi hakkında harika bir dokümantasyona sahip olmanızdır. Gerekirse yeniden yapmak da çok kolaydır. Organizasyon çalışmalarına hazır olduğunuzda şemanızın bir yedeğini "orijinal" olarak atar ve bir yere koyarsınız.

Bunun yapılandırılmış ve temiz bir yol olduğunu düşünüyorum. Ve daha önce de belirtildiği gibi, hangi alanın adını yeni adla değiştirdiği ve hangi orijinal tabloların o büyük yeni tabloya birleştirildiği hakkında çok sağlam bir belge alacaksınız.

FME ve bunun gibi yazılımlarda elbette yaptıklarınızı da kaydedebilirsiniz, ancak dahili veritabanı sorgularına kıyasla çok yavaş olmasının yanı sıra sql-sorguları olarak yapılanların evrensel bir belge biçimi değildir. Metin dosyaları ve ilişkisel veritabanları olduğu sürece kullanılabilir ve okunabilir olacaklardır.

Sonunda aşağıdaki gibi görünen metin dosyaları ile kullanmak için kullanın:

-- A query to merge all roads in Norway

Create table road_tables.all_roads as
SELECT id as roadid, status, the_geom from original.big_roads
union all
SELECT rid as roadid, condition as status, the_geom from original.small_roads;

ve bunun gibi. Metin dosyası olarak kaydedilen bu dosya birkaç yıl sonra büyük bir değere sahiptir.

Saygılarımızla Nicklas


1
+1 Bence bu çok iyi bir yaklaşım. Her şey Postgres içinde yapılır, çok şeffaf ve gerekirse kolayca çoğaltılabilir.
underdark

1
ESRI tabanlı CBS için iyi bir öneri değil. Açık kaynak "sadece" bu kabul edilebilir. ESRI'nin bu yöntemle erişilemeyecek daha fazla bağımlılığı vardır. postgis'e doğrudan bağlanmaya bir birlikte çalışma, gis sunucusu veya arcsde olmadan izin verilmez.
Brad Nesom

2
@Brad Hmm, bunun şeffaf bir tekrarlanabilir ve hızlı bir şekilde bir şeyler yapmanın ya da benim ve verilerimin arasına sde koyarak kilitlenmeye karşı bir argüman olup olmadığını merak ediyorum ... ;-)
Nicklas Avén

1
@Brad: colemanm ESRI'dan bahsetmedi, bu yüzden cevap iyi görünüyor.
underdark

ESRI Sde özellik ve SQL Server 2008 (yerel geometri ile) ile benzer işler yaptım - Önce özellik sınıfını oluşturdum, sonra bir dizi ekleme ifadesi ile yükledim. IIRC, yeni nesneler doğru bir şekilde üretemediğim için, son sınıftaki yeni bir sınıf sınıfına aktarmak zorunda kaldım. bunu bir kez yaptım, her zamanki gibi iş.
Jay Cummins

4

Benim önerim, daha ağır kullanılan veri katmanlarınızın (şekil dosyaları) 2-5'ini seçmek ve bunları bir rdbms'ye taşımak olacaktır.
Bu veriler için iş akışlarını araştırın ve uygulayın. Rdbms ve dosya tabanlı verilerin sınırlamalarına ve gereksinimlerine alışmak.

Sınırlamalar şunları içerir: gerekli ihracat, iniş bölgesi, coordsys, işbirliği için dosya türü.

Teklif ettiğiniz şeyin birçok faydası var.
Side NOT: (Büyükbabam, aileme satın almadan önce 6 milyonluk bir ev aramak için harcama yapmasını söyledi) verileriniz için bir ev (uzun vadeli) aradığınızı düşünün, bundan 30 yıl sonra bir şey ödemek istemiyorsunuz sevmiyorum.

Benim tavsiyem veri kaynaklarınızın bir ağaç listesini yazmak ve büyük bir resimde görüntülemek (bu, verileri daha kısa gruplarda organize etmenizi sağlayacaktır).

Arcgis içinde (benim varsayım: tercih ettiğiniz sistemi belirtmediniz) farklı veriler entegre etmek için yöntemler vardır.

İyi tasarım uygulamaları öğrenmek istiyorsanız bu bilgilerin bir kısmını deneyebilirsiniz ...

Coğrafi veritabanı tasarımı genel bakış
GeoDatabase documentaion
da yay 10 için bazı benzer liinks vardır.
Kaynak Merkezi
arc10 geodatabase

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.