PostGIS Raster verilerini farklı projeksiyonlarla nasıl yönetmeliyim?

Raster bir görüntü - dikdörtgen bir dizi örnek olarak toplanan arkeolojik jeofizik verileri depolamak ve yönetmek için bir gereksinim var .

• Her bir raster genellikle 1x aralıklarla örneklenen 20x20 veya 30x30 kayan nokta örnekleri olacaktır.
• Anket, belirli bir konumdaki bu görsellerden bir veya daha fazlasından oluşur.
• Farklı ülkelerde veya farklı projeksiyonların kullanıldığı alanlarda iki farklı anketin yapılması mümkündür, ancak her ankette bir ve sadece bir projeksiyon kullanılacaktır.
• Asla birlikte görülme olasılıkları yoktur, her anket genellikle kendi başına oturur.
• Verilere yalnızca özel bir kullanıcı arabirimi tarafından erişilir, bu nedenle doğrudan psqlveya benzer bir şekilde doğrudan kontrolü elde eden hiçbir kullanıcı olmayacaktır .
• Her numunenin toplandığı gibi saklanması gerekir, bu nedenle Web Mercator gibi ortak bir CRS'ye yeniden enjekte edemem, çünkü bir örnek orijinal projeksiyondakinden daha fazla veya daha az alanı kapatabilir ve analiz yapılması gerekir veri.

Verileri bir PostGIS Raster veritabanında en iyi nasıl saklamalıyım? Geldiğim seçenekler:

1. SRID kısıtlamalarını yok sayın ve tüm verileri tek bir tabloda saklayarak, verileri tutarlı bir şekilde değiştirmeyle başa çıkmak için ön uç kodumu yaz.
2. Tüm verileri tek bir tabloda depolayın ve SRID kısıtlamasını SRID ve anket kimliğinin bir bileşiği olarak yeniden yazın.
3. Tablo devralma yoluyla, her yeni SRID için yeni bir tablo oluşturun.
4. Tablo devralma yoluyla, her anket için yeni bir tablo oluşturun.

1 ve 2, PostGIS'in güzel otomatik parçalarından bazılarını kırıyor, ancak aksi takdirde ön uç kodunda gizlenecek. Ancak sorgular muhtemelen biraz daha uzun sürecektir.

3 ve 4, FK kısıtlamalarını yönetmeyi zorlaştıracak bir masa patlamasıyla sonuçlanabilir.

Pratik olarak, anket başına raster sayısı 1 ila 100 veya daha fazladır ve anket sayısının yüzlerce kişiye ulaşması muhtemeldir. Ancak, farklı projeksiyonların sayısının çok düşük kalması muhtemeldir, bu da 3'ü tercih eder.

Sorunuza bir düşünce verdim ve nihayetinde her anketi kendi veritabanında saklayacağım sonucuna vardım .

NOT : veritabanına göre, burada verilen postgres terminolojisine göre tek bir postgres veritabanı kümesi içinde oluşturulan bir veritabanı , kendi kullanıcıları, template1, vb. İle tamamen ayrı bir postgres süreci değil kastediyorum .

Bu aşırıya kaçabilir gibi görünse de, aslında, birkaç avantaj sunar:

• yönetilebilirlik: her ankette, verileri yöneterek postgis standartlarına olabildiğince uymanızı sağlayan srid ile yalnızca bir raster tablosu vardır (yani: raster_columns tablosu veya FK'ler veya kısıtlamalarla uğraşmak yok. Tüm postgis işlevleri hala beklendiği gibi çalışır)

• basitlik: Aşağıdaki gibi tutarlı bir adlandırma stratejisini benimsediğiniz ve uyguladığınız sürece: her db'yi srvy_ name olarak adlandırın ve ardından tüm raster tabloları ve sütunları için aynı adı (yani anket verileri ) yeniden kullanın . Eğer çok istekli iseniz (Ben biliyorum ;-) biliyorum) Ayrıca her veritabanına, ne zaman son güncellenme ve benzeri, bu veritabanında ne tür veri depolandığını açıklayan bir meta veri tablosu ekleyebilirsiniz. Böyle bir tutarlı adlandırma ile bir veritabanı yapısının kodlanması / sorgulanması kolay (ve hoş) olacaktır.

• her anket kendi srid'ini kullandığı sürece, gereksinimlerinize göre çalışır

• ölçeklenebilirlik: ölçeklenir çünkü veritabanlarını (farklı tablo alanlarına ayırarak ) farklı iğlere (veya depolama satıcısına bağlı olarak diskler, havuzlar, lun) taşıyabilir, böylece G / Ç paralelleştirilebilir. Tabloları aynı veritabanından farklı disklere taşımak çok daha zor olurdu

• güvenlik: veritabanı güvenliğinden yararlanarak farklı anketlere farklı izinler verebilirsiniz (uygulamanın üzerinde ek bir katman olarak)

• Test edilen: Tek bir örneği veritabanlarının binlerce taşıma Postgres'e arasında olmuştur raporlar, bkz bu bir referans için

• [Bu test edilmelidir, geometriler için çalıştığını biliyorum, rasterler için bilmiyorum] hala aşağıdaki gibi görünümler oluşturarak tüm rasterleri bir kerede sorgulayabilir (ve dönüştürebilirsiniz):

create or replace view v_all_surveys_as_wgs84 as select ST_Transform(raster, 4326) as raster_wgs84 from srvy_number1.rasterdata union all select ST_Transform(raster, 4326) as raster_wgs84 from srvy_number2.rasterdata [...]

Karşı olası bir argüman bu kurulum karmaşık olmasıdır, ama çoğaltmak için yerine çok basittir geri iddia ediyorum kez ilk veritabanı oluşturulmuştur ve uygun adlandırma politikası yerine koymak durumunda o zaman tamamen komut dosyası içinde yönetilebilir.