Bu, NAD 83'te yer alan 10 metrelik bir DEM'den elde edilen tahmini olmayan (NAD 83) verilere ilişkin öngörülen (örneğin, Albers Equal Area) verilerle sınırlandırılmış havzaların etkileri konusunda meslektaşlarla yapılan bazı tartışmalardan kaynaklanan teorik bir sorudur.

Bazıları, projeye karar vermeniz durumunda, programlanmamış verilerden hesaplanan değerlerin basitçe düzeltilmesinden dolayı sorun olmadığını belirtti.

Bir coğrafi koordinat sistemindeki veriler ile öngörülen veriler arasında içsel farklılıklar olduğu için durumun böyle olduğundan emin değilim. Projelendirilmemiş DEM verileriyle başlayan rutinden geçen bir örneği denedim, sonra aynı siteyi öngörülen DEM verileriyle test ettim. Her ikisi için de atılan adımlar 10m DEM verisi kullanılarak (ArcGIS 9.3.1'de yapılan tüm çalışmalar) yapıldı.

Bir çalıştırma NAD 83'te bir DEM kullanılarak yapıldı ve ikinci çalıştırma aynı DEM'in USA_Contiguous_Albers_Equal_Area_Conic_USGS_version'a yansıtılmasıyla yapıldı.

• geoprocessing FlowDirection_sa kullanarak akış yönünü türetir aracını
• FlowDirection_sa aracını kullanarak akış birikimini türetir
• akma noktasını kes50 metrelik bir mesafe kullanarak
• Watershed_sa aracını kullanarak havzayı tanımlayın

İkisini karşılaştırırken Akış Yönü ızgaralarının görüntüsü arasında görsel bir fark görebiliyordum.

NOT: Daha sonraki araştırmalardan sonra, şeritleme etkisinin bir KÜBİK yeniden örneklemenin kullanılmamasından kaynaklandığına, ancak ArcGIS Project Raster aracındaki NEAREST'in varsayılanına göre ayarlandığına inanıyorum. Bunun, bu tartışmaya herhangi bir çözüm getirdiğine inanmıyorum.

Projelendirilmemiş DEM kullanarak akış yönleri

Öngörülen DEM kullanarak akış yönleri

Görsel karşılaştırmanın% 100 bilimsel olmadığını ama iyi bir başlangıç ​​noktası olabileceğini biliyorum.

Buna göre, akma noktası ile her bir çalışma için bağlanma şekli arasında bir fark vardı. Ve, akma noktası noktası aracının, öngörülen / projelendirilmemiş veri setlerine dayanarak akmaya nasıl karar verdiğine bağlı olarak, elde edilen su havzalarında kesin bir fark vardı. Yeşil ile gösterilen havza, yansıtılan DEM ve müteakiben yansıtılan türetilmiş yükselme türev verileri kullanılarak elde edilen havzadır. Mor taslakta gösterilen su havzası, projelendirilmemiş DEM verileri kullanılarak elde edilen su havzasıdır.

Havza

Bu konuyu eski ESRI forumlarında tartışan diğer iki GIS forumunda (aşağıdaki linklerde) rastladım, ancak hala Akış Yönlendirme aracının öngörülen verilere göre tahmin edilmemiş verilere göre nasıl çalıştığı konusunda net değilim (anladım) hidrolojik akış ve akış yönü olsa da). Eğer her bir hücre hala öngörülen bir DEM'e göre yansıtılan bir DEM'de aynı yükseklik değerine sahipse (bu doğru mu?), Neden NAD83'teki DEM verilerinden elde edilene karşı yansıtılan verilerden türetilen akış yönünde rasterde bir fark vardır?

http://forums.esri.com/Thread.asp?c=93&f=995&t=292503

http://forums.esri.com/Thread.asp?c=93&f=995&t=290652

Ayrıca, Virginia eyaletinde Shenandoah Milli Parkı, Teksas eyaletinde suçlamalar yapmak gibi yüksek bir Latitude'da açıklama yaparken, teorik olarak bir sorun daha az olur mu?

Ekvatordan uzaklaştıkça alacağınız doğu-batı bozulmasının bir sorun olabileceğini düşündüğüm bir kartografi uzmanıyla konuştum (bazı haritalarda Kanada'nın aşırı derecede şişirilmiş ve çarpık olduğu gibi) Ekvatordan 10 derece enlem derecesi, tahmin edilen verilerin doğruluğu ile ilgileniyorsanız gitmenin yoludur.

Bilinmeyen en önemli konulardan biri, ele almaya çalıştığımız, tahmin edilmemiş veriler kullanılarak belirlenen havzalardaki belirsizlik düzeyidir. Bir fark var, ama büyüklüğü nedir?

Bu tartışmaya açık bir cevap verebilecek olan herkese veya bununla ilgili faydalı bir fikir edinebilirsiniz.

Düzenle

İlgilendiğimiz / ilgilendiğimiz ana konu, projelendirilmemiş bir DEM kullanarak başlatılmasının bir sonucu olarak sınırlandırılmış su havzalarında doğruluk sorunları olup olmayacağıdır.

Öyleyse, cevabı anlıyorsam, sınırlandırılmış havzalar akma noktası için drenaj alanını temsil etme açısından iyi olmalı mı? Akış yönleri yanlış ise son su havzasında bir hataya neden olacak gibi görünüyor.

Bu çok ilginç ve gerçekten önemli bir konudur - Su havzalarını sınırlandırmak için BM tarafından öngörülen verileri kullanmanın uygun olmadığını bildiren bir rapor veya belge görmedim. Spatial Analyst eklentisinin (Hidroloji araçlarını barındıran) baş geliştirici mühendisinin öncülüğünde ESRI Kullanıcı Konferansı teknik görüşmelerinde bulundum, burada da eşit alan projeksiyonu (Albers eşit alan gibi) kullanmanız gerektiğini söylediler.

Ayrıca, bunun nasıl yapılacağına dair herhangi bir yetkili "İncil" standardı yok gibi görünüyor - sadece neredeyse kabul edilmiş bir fiili olarak görünüyor yükselme türevlerinizi hesaplamadan önce verileri yansıtmak için yaklaşım .

Hiçbir yerde bunun akış yönü hesaplamasını ve bunun ardından bir su havzasının sınırlandırılmasını nasıl etkilediğine dair kısa ve net bir cevap bulamadım.

Ve, eğer havzalarla çalışılmamışsa, projelendirilmemiş DEM verilerini kullanarak sınırlandırılmışsanız ve o zaman bu havzaları yansıtıyorsanız, hala orada bulunan yanlışlıklar (örneğin, bir havza alanını veya arazi örtüsü oranları gibi diğer özellikleri belirlemek açısından)?

Dahası, projelendirilmemiş bir DEM'den türetilmiş bir akış yönü rasterini yansıtmanın, kaynak verilerinin projeksiyon edilmemesinden dolayı hataları düzeltmeyeceğini farz ediyorum.

teşekkürler - sağlayabileceğiniz her türlü görüş için teşekkür ederiz

EDIT - 20110331

@whuber:

Bu kapsamlı tartışma için teşekkürler. Biz daha bu konuyu araştıran oldum ve aslında aslında daha iyi olduğunu öne süren referanslar rastlamak değil akış dir almadan önce DEM proje., Akış accum. Ve sınırlarını belirleyen.

Anonim bir kaynaktan (ancak oldukça saygın bir kişi olan) gelen bir e-posta yanıtı, 1. soru sorulduğunda () proje DEM 2.) türev üretmek VEYA 1.) türev üretmek 2.) proje DEM:

Özetle, bu türevine bağlıdır. Görselleştirilecek olan sürekli türevler için, türetmeli ve sonra yansıtmalısınız - bu, kiremit sınır artefaktlarının geliştirilme veya tanıtılma riskini azaltır (projeksiyon algoritmasıyla) ve sonra eğer önce DEM'i yansıtmak istiyorsanız türevine geçirin. Bunun istisnası, türev hesaplamanızın temeli olarak mesafe veya alan kullandığınız zamandır. Bu, elbette, mesafelerin / alanların ne kadar büyük olduğuna ve ekvatordan kabul edilebilir bir şekilde ne kadar uzağa gidebileceğinize bağlıdır. Öyleyse, hücre boyutuna bağlı olan eğim veya tepe gölgesi gibi türevler için sonuçların olduğunu düşünün. Bu türevler ekvatorda en doğru olacak ve doğruluk kuzeyden veya güneyden 60 derece geçerek önemli ölçüde bozulacaktır. Her iki durumda da, DEM'in çok geniş bir alanı (1.5 UTM Bölgelerinden daha geniş) ve karoların keyfi ya da USGS Quad levha sınırları gibi mevcut standartlara uygun olduğu geleneksel karo tabanlı bir yaklaşımı kapsadığını farz ediyorum. Bu nedenle, bu düşüncenin çoğunun, daha az yorum yapamadığım mozaik veri kümelerini önceden yücelttiği söyleniyor. Benim için asıl endişe DEM çinilerinin ne kadar iyi eşleştiğini bilmek istemekti. Eğer iyi eşleşirlerse (NED gibi) o zaman işlerin iyi çalışmasını bekliyorum, türevlerin fayanslardan türetilmesi (mozaik veri setine uygulanan fonksiyonlar gibi) ve sonra bunlar anında görüntüleniyor. Onlar iyi eşleşmediyse, çöp içeri, çöp dışarı. Asıl sorunuza dönersek, bence sadece havza sınırları ise,

Söylemeye devam ettiler:

Öngörülemeyen metodolojiye bağlı kalmamın nedeni, kendi içinde bir DEM türevi olan rasterleri kullanmamızdır (tipik olarak sahip olmadığımız ama LiDAR nokta bulutu olduğunu düşünüyorum). Nispeten ince çözünürlük seviyelerinde olan kıtalar gibi çok geniş alanları kapsayan rasterler için, Albers gibi bir şeye yansıtma, raster normal boyutlu hücreler kullandığında (Esri'nin rasterleri gibi) bilgi kaybına veya bilgisine neden olur. Bu, Akım Birikimi gibi araçların kısmi veya enterpolasyonlu bilgilere dayanan sonuçlar üreteceği anlamına gelir. Temel olarak, rasterlere uygulanan tüm projeksiyon algoritmaları, piksel genişliğinin mesafesinden daha fazla bir genişleme veya daralma olduğu anda sorunlara neden olacaktır (Albers gibi çıkıntılar, iki eski piksel arasına yeni pikseller ekleyerek hata verebilir). Bunlardan türetmek, kümülatif hata potansiyelinin yüksek olduğu anlamına gelir.

Bu tam tersi gibi görünüyor - 60 derece enlemin üzerine çıkmazsanız, yansıtma daha fazla gürültü çıkarır.

Ayrıca, GIS için Dağıtılmış Hidrolojik Modelleme'den, projelendirilmemiş olanın daha küçük su havzaları için kabul edilebilir bir yaklaşım olduğu (bölüm 1.6'nın son 2 paragrafı) benzer olduğunu bildiren yayınlanmış bazı kaynaklara rastladık: (Vieux, 2004): http: //www.springerlink. com / content / x877238532533g20 / fulltext.pdf

Yani, sonunda, sadece 1. akış yönü algoritmasını etkileyen nitelikleri daha iyi koruyacak, uygun olmayan bir şeye yansıtmanız gerekip gerekmediğini belirlemek için, denetlenmemiş verilerin (kutuplara doğru ilerledikçe artan fayda) ortaya çıkardığı bozulmadan daha az olacağını?

Bu konuyu kazmaya başladığınızda, daha büyük fikir birliği yansıtmak gibi görünüyor, ancak bunun zor ve hızlı bir kural olmadığını söyleyenler var.

Projeksiyondaki çarpıklıkların akış yönü (ve akış birikimi) tahminlerini önyargılı yapabileceği doğrudur. ("Projected" verilerini kullanmak, yüksek derecede deforme olan Plate Carree projeksiyonunu kullanmakla aynıdır.)

Bununla birlikte, sadece havza taslak havzalar için gerçekte az bir sorun vardır: akış yönleri ve akış miktarları yanlış olsa da, projeksiyon suyun gitmediği alanlara akmasına neden olmaz. Yokuş aşağı hala yokuş aşağı.

Basit örnekler sayesinde, önyargının nereden geldiğini görmek zor değil . Biri diğerinin kuzeydoğusundaki 141 metre mesafeli ve derhal aşağı inen iki nokta olarak düşünün. Bu nedenle akış yönü kuzeydoğudan kaynaklanmaktadır. Koordinatlarda, düşme noktası x yönünde 100 metre ve y yönünde 100 metre kaydırılır. Enjekte edilmemiş verileri kullanarak 60 derece enlemde iseniz, ofsetler aslında x yönünde 200 metre ve y yönünde 100 metre gibi görünecektir. (200 = 100 / cos (60).) 45 dereceden ziyade kuzeydeki 63 derecelik bir yatağa dönüşür. Birçok akış yönü / akış birikimi / tasvir algoritmalarında sadece 8 kardinal yön mümkündür. Bu nedenle, kuzeydoğu akışını göstermek yerine, ızgara bu durumu doğu akışına çevirebilir.

(63 derece yüksek bozulma yönünde ve minimum distorsiyon yön arasındaki çıkıntının nispi bozulma bir fonksiyonu olarak trigonometrik hesaplanır. Bu başlar ölçmek unprojected verileri kullanarak etkisini.)

Bunu görselleştirmenin iyi bir yolu, 8 pusula yönünü lastik bir kağıda doğru çizmek. Kauçuğu yanlara doğru gerin (daha yüksek enlemler için daha fazla esneme ile): ne kadar uzarsanız, oklar o kadar fazla doğu-batıya yönelir. Bu yönlerde açılar küçülür, kuzeye ve güneye doğru açılar genişler. Bu arada, ızgaradaki yükselmeler değişmeden kalır. Sonuç olarak, arazinin hem eğimi hem de yönü bozulmuştur, çünkü bunlar konumsal koordinatlara göre yükselme değişim oranına bağlıdır .

Aslında olacaktır daha bu nedenle Teksas'ta daha Virginia'da bir sorun. Kartografın doğru . (10 derecelik kesimin nereden geldiğini bilmiyorum. Yine de kulağa mantıklı geliyor ama bunun gibi kurallara uymak, doğruluk gereksinimleriniz ışığında değerlendirilmeye ihtiyaç duyuyor. çok daha fazla doğruluk isteyebilir.)

Uygun bir iş akışını benimsediğinizde bu sorunların çoğu tartışılmaz hale geliyor. Verilerinizi bulabileceğiniz en iyi uyumlu projeksiyonla yansıtmaya başlayın (çünkü göreceli açıların bozulması yoktur). Akışı ve yön bilgisini içeren herhangi bir şeyi hesaplayın. Daha sonra, sonuçları analiz veya haritalama için kullanmak istediğiniz koordinat sistemine geri götürün (veya yeniden programlayın). Örneğin, belirlenmiş havzaların alanlarını hesaplamak için eşit alanlı bir projeksiyon ile yeniden projelendirilir. Mesele şu ki, yeniden projelendirmenin gerçekleştireceğiniz hesaplamaları ve haritalandırmaya uyum sağlamak için ihtiyaç duyduğunuz şekilde projeksiyonları karşılayabileceğiniz ve değiştirmeniz gerekebilecek kadar basit : tek bir uzlaşma projeksiyonuna sıkışıp kalmadınız.

Düzenle

Orijinal soruya yapılan bir ek, havza tarifine odaklanmaktadır. Bunu ele alalım. Bunu yapmak için, akış yönlerinin nasıl tahmin edildiğini anlamamız gerekir.

Eğimleri ve yönleri hesaplamak için ArcGIS yöntemi belgelenmiştir :

Akış yönü, her bir hücreden en dik iniş yönü ile belirlenir.

Spesifik olarak, x [0,0] 'ın bir hücrede değeri belirtmesine izin verin ve x [i, j] i hücresindeki değeri sağa doğru atayın ve aşağıdaki j satırlarını belirtin. Lavabolarla ilgili ve bağları çözen bazı özel durumlar dışında, algoritma sekiz yönlü eğim tahmininin en büyüğünü seçer (x [0,0] -x [i, j]) / Sqrt [i ^ 2 + j ^ 2] | i | <= 1 ve | j | <= 1 ve bunun akış yönü olduğunu varsayar. Bu sayılar oranlardır: payerler, yükseklikteki farklılıklardır ve paydalar, kullanılan koordinatlarda, Pisagor Teoremi ile hesaplanan mesafelerdir .

Izgarayı yeniden enjekte ettikten sonra iki şey olur: (1) hücreler taşınır (ve bu şekilde çarpılır) ve bu nedenle (2) ızgara değerleri (yükselmeler) yeni ızgara için hücre kafesine yeniden yerleştirilir. Yeniden yapılanma nedeniyle kottaki küçük değişiklikler meydana gelebilir ve bunlar tahmini akış yönünde ara sıra değişikliklere neden olabilir. Tipik olarak bu tür değişiklikler nadirdir, bu yüzden onları görmezden gelelim. Bu değişiklikler, yeniden yapılanmadaki metrik bozulmaların neden olduğu değişikliklerle cüce olacak. Örneğin, Plate Carree'den (temel olarak bir coğrafi koordinat sistemi) konformal bir projeksiyona yeniden projelendirilmesinde, doğu-batı yönü enlemin kosinüsü ile büzülür. Bir hücrenin sığdığı kullanılan (bir sıra boyunca) uzayda, 1 / cos (enlem) hücrelerinin şimdi sığması gerekir. Bu genellikle büyütmekherhangi bir görünen eğim, doğu-batı bileşenine sahip herhangi bir yönde (yani NE, E, SE, SW, W ve NW yönleri) tahmin eder. Oysa daha önce bu gibi eğimler en büyük görünmeyebilirdi ve bu nedenle ArcGIS algoritması tarafından seçilmediyse, daha büyük hale getirilerek şimdi akış yönü olarak seçilebilirler. Buna göre, birçok yerde bir kuzey veya güney akış yönü NE, NW, SE veya SW'ye dönüştürülecek ve bir NE yönü E, vb.

Herhangi bir yeniden yapılanmanın etkileri benzer bir hesaplama kullanılarak tahmin edilebilir: Birinden diğerine geçerken meydana gelen yönlü çarpıtmaları bilmeniz gerekir.

Bir "akma noktası" x'in "havzasında" olmanın ne demek olduğunu düşünelim . En herhangi bir yer kabul edelim Y "bir havza yatmaktadır x yüzeyi, çıplak sürtünmesiz, geçirimsiz, ve düz ve su halinde olsaydı (saf Advektif akış) yaymadan akmaya olduğu anlamına gelir", o zaman ortaya çıkaracağı y için x . Bu, yine de, GIS'in (su havzası sınırlandırmasının merkezinde olan) akış birikimini hesaplamakta yaptığı şeydir.

Çoğu yerde bir akış yatağı boyunca noktası x yalan dökün , yeniden projeksiyon yapmak hiçbir temel fark çarpıtma: bunlar daha açık bir akış yolu neden y için x değişiklik, ancak sonuç olarak su, yine de, aynı akış yatağında geldiğinde olsa belki biraz farklı bir yoldan. Herhangi bir tutarsızlık olursa, (a) akış yolunun x boyunca akış boyunca daha aşağıdan aşağıya doğru gelmesi gerekir (ve böylece y , x'in su havzasında olduğu düşünülmez ), (a ') akan y' noktaları şimdi x'in aşağı akışındaki noktalara akın x(ve böylece şimdi x'in havzasına dahil edilmiştir ) veya (b) yeni akış yolu farklı bir akışa girmektedir (bu gerçekten (a) ve (a ') özel bir durumdur). Birincisi (a ve a ') çok şey olabilir, ancak esas olarak akarsu akışları tarafından sınırlanan su havzalarının kısımları içinde değil , akış bölümleri boyunca akma noktaları için farklılıklar yaratacaktır . İkinci değişiklik, bir akış yolu bir sırttaki boşluğa yakın bir yerde yürüdüğü zaman gerçekleşebilir. Oysa bir projeksiyonda, aralığın bir tarafına yönlendirilmiş olabilir, diğerinde ise - bozulmadaki küçük farklılıklar nedeniyle - diğer tarafa yönlendirilebilir. Bunun nispeten nadir olduğundan şüpheleniyorum ve temel olarak herhangi bir büyük havzanın çevresi boyunca yüksek olan küçük su havzalarını etkilemelidir.

Bu nedenle, sonuçta, havza yapısının niteliksel niteliği az değişmeli, fakat kantitatif olarak (göreceli alan açısından) yeniden yapılanma üzerine gözle görülür biçimde değişebilir .

Ne yapmalı o zaman? Bu yalnızca sekiz yönlü algoritmaya sıkışmışsanız , anahtar göreceli yönleri doğru elde etmektir . Tanım olarak, bu , uygun bir çıkıntının veya en az birine uyumlu olanın kullanılmasını gerektirir . Ancak, uygun projeksiyonlar (tam olarak) eşit alan olamayacağı için, geniş alanlı çalışmalar için havza alanlarını hesaplamak için uygun projeksiyonlar kullanmak istemezsiniz. Çözüm başlangıçta önerdiğim şeydi:

• Akış yönlerini hesaplayın ve uygun bir çıkıntı kullanarak su havzalarını temizleyin.

• Sınırlı su havzalarının alanlarını (ve arazi örtüsü yüzdesini, vb.) Eşit alanlı bir izdüşüm kullanarak hesaplayın.

(Bunun doğru akış birikimi hesaplamalarını garanti etmediğini unutmayın . Bunlar, akış yönlerini doğru alırken aynı zamanda alanların iyi tahminlerini gerektirir. Bir yaklaşım, çok fazla belirsizliğin, şekerlemenin ve varsayımın devam edeceğini kabul etmektir. Bu noktada sadece saçları bölüyor olabileceğimizi gösteriyor: Bir başka yaklaşım - kıta düzeyinde hesaplamalar yaparken göz önünde bulundurmaya değer - konformal bir projeksiyonda akış birikimleri yapabiliyor ancak girişleri (havzaya düşen "yağmur" miktarı) ayarlayabiliyor. (1) alaeal distorsiyona göre, bu, Mercator veya Stereographic gibi basit uyumlu projeksiyonlar kullandığınızda, areal distorsiyonunun matematiksel olarak hesaplanması kolay olan seslerden daha kolaydır.)

Küçük alanlı hesaplamalar için, her zaman iki projeksiyon kullanarak uğraşmanıza gerek kalmayacak, uygun ve eşit alan olmaya çok yakın projeksiyonlar vardır (örneğin, tek bir UTM bölgesine sığacak alanlar için UTM koordinatlarını kullanın). Bu şey gerçekten eyalet veya ülke veya kıta büyüklüğündeki çalışma alanları için önemlidir.

Bir GCS sadece ekvatorun yakınında (yani (lat, lon) yaklaşık olarak uyumlu ve eşit alandır) bozulma içermediğinden, iyi bir kural, ızgara hesaplarınızı lat-lon koordinatlarında yapmaz !

Hala bütün nüansları kapsamamıştım (örneğin, tahmini akış yönlerinde küçük neredeyse rastgele değişiklikler, bir ızgarayı 90 derecenin katları dışında tekdüze döndürdüğünüzde meydana gelir , lavabolar ve düz alanlar hakkındaki tüm tartışmaları anlattım, Alternatif (ArcGIS olmayan) algoritmalardan bahsetmedim), ama umarım bu analiz durumun temel yönlerini aydınlatmaya yardımcı olur.