Спроба відповісти на моє власне питання:
Причини нанесення смужок у наведених нами прикладах повністю пов’язані з моїм робочим процесом, а не будь-яким застарілим питанням того, як спочатку дані збиралися або мозаїкувалися разом. DEM, з якими я мав справу, були породжені новішими методами, про що свідчить ця карта:
Два методи, які охоплюють області, з якими я працював, - це LIDAR та інші активні датчики або складна лінійна інтерполяція. Старі методи, на які посилається @Dan Patterson, - це методи ручного профілювання та гештальт Photomapper. Дійсно, USGS посилається на це у посиланні NED @Dan Patterson ділиться:
Старі джерела DEM, вироблені за допомогою застарілих методів, були відфільтровані в процесі збирання NED, щоб мінімізувати артефакти, які часто зустрічаються в даних, отриманих цими методами. Видалення артефакту значно покращує якість схилу, затіненого рельєфу та синтетичну інформацію про дренаж, яка може бути отримана з даних висот. Процес фільтрації видалення артефактів не усуває всіх артефактів. У районах, де єдиний доступний DEM виробляється старішими методами, тоді "роздягання" все ще може відбуватися. Обробка NED також включає кроки для коригування значень, де сусідні DEM не відповідають нормам, та заповнення областей прокрутки відсутніх даних між DEM. Ці етапи обробки гарантують, що в NED немає порожніх ділянок і мінімальних штучних розривів.
Отже, що спричинило мої смугасті проблеми?
Хоча для правильного обчислення значень TI в ГІС SAGA нам потрібні одиниці комірок у метрах, а не вимірювання ступеня вихідної географічної координатної системи, і тому перший крок нашого робочого процесу складався з використанням ArcMAP (я ненавиджу набір проекційних інструментів SAGA) для спроектуйте DEM у правильній проекції UTM. У межах цього кроку існують різні варіанти перекомпонування DEM. У всіх DEM і результатах, які мали смугу, ми неправильно залишили техніку перекомпонування за замовчуванням як наш вибір- алгоритм перекомпонування за замовчуванням - Найближчий сусід, який ніколи не повинен використовуватися з безперервним набором даних, як дані евеляції, присутні в DEM. Коли ДЕМ проектували за допомогою передіамплікації за дволінійною інтерполяцією, у DEM або будь-якому з отриманих продуктів не спостерігалося жодних горизонтальних чи вертикальних артефактів.
ESRI знав про це:
DEM піддаються артефактуванню. У багатьох DEM вже є деякі артефакти, представлені під час створення; пагорби цих ДЕМ збільшують аномалії та роблять їх видимими. Якщо DEM не має жодних артефактів, перш ніж вона буде представлена як схил схилу, проблема може бути викликана використанням неправильного методу перекомпонування при проектуванні даних DEM. DEM - це суцільні растрові дані. Біліарний метод перекомпонування повинен застосовуватися при растрових проекціях або будь-яких растрових перетвореннях. Під час проектування растрових даних за допомогою інструменту Project Raster GP не використовуйте метод перекомпонування за замовчуванням. Виберіть замість білінеарного перекомпонування або кубічного методу перекомплектування згортки.
Джерело: http://support.esri.com/en/knowledgebase/techarticles/detail/29127
І USGS знає про це, заявляючи в FAQ:
Питання: Які способи перекомпонування найкращі для збереження точності даних NED та характеристик рельєфу?
Відповідь: Кубічна згортка та білінеарна інтерполяція є кращими методами перекомпонування даних цифрових висот, і це призведе до більш плавного вигляду. Найближчий сусід має тенденцію залишати артефакти, такі як східчасті та періодичні смуги в даних, які можуть не бути очевидними при перегляді даних про висоту, але можуть впливати на похідні, такі як затінений рельєф або растрові схили. *
Джерело: http://ned.usgs.gov/faq.html#RESAMPLE
Отже, моє нерозумне прийняття налаштувань за замовчуванням в ArcMap (і моє незнання результатів) спричинило це. Напевно, дуже очевидна помилка.
Живи й учись.
