Анализ освещенности - существенные расхождения GRASS и SAGA

13

Я хотел рассчитать и визуализировать значения освещенности для графика. Не знаю почему, но в моей копии QGIS 2.18.5 мне не хватает соответствующего модуля SAGA в « Анализ местности -> Молния », поэтому я выбрал алгоритм GRASS « r.sun ».

Результаты были довольно удивительными. Кажется, что, несмотря на должным образом привязанный к геологическим данным растр, по которому был сделан анализ, участок должен располагаться на Венере, а не на востоке Польши. Просто 21 июня здесь практически невозможно получить почти 5 кВт-ч / кв.

введите описание изображения здесь

Чтобы перепроверить числа, я нашел отдельную копию SAGA 5.0 и повторно провел анализ ( алгоритм «Потенциальное поступающее солнечное излучение» ). На этот раз результаты были более достоверными (растр на скриншоте импортирован в QGIS для сравнения).

введите описание изображения здесь

Эти два алгоритма так сильно отличаются?

Кто-нибудь сталкивался с такой же проблемой?

Все еще только тестирую эту функциональность.

  1. Версия QGIS: 2.18.5
  2. GRASS версия: 7
  3. Версия SAGA: 5.0.0.
  4. Входные данные: растровая высота, уклон и данные об аспектах (3 отдельных). SAGA работала только на высотном растре. ТРАВА использовала все 3.
Протей
источник
2
Я бы разместил этот вопрос в списке пользователей GRASS lists.osgeo.org/mailman/listinfo/grass-user
mankoff
2
Может ли помочь этот вопрос и ответ "r.sun delievering Unrealistic Values" от @Ulf?
Казухито
Спасибо @Kazuhito! Теперь стало понятнее, почему результаты выглядят так. Кстати: то же самое относится к расчетам освещенности в SAGA?
протей
@mankoff - есть ли отдельная группа для пользователей SAGA? Этот вопрос становится более интересным благодаря вашему вкладу, и я хотел бы узнать больше об обоих решениях.
протей
Не могли бы вы проверить эту Potential Incoming Solar Radiationфункцию в SAGA 6.4?
Казухито

Ответы:

3

Я не знаю много о фоне алгоритмов r.sun и SAGA. Однако не может ли это быть проблемой с интерпретацией единиц или интерпретацией входных данных?

В случае r.sun это должна быть ежедневная сумма за кв. Метр. Прикрепление скриншота типичных дневных значений около Кракова из базы данных Solargis , в июне ок. 5 кВтч / м2 / день это просто отлично. Solargis: долгосрочные среднемесячные значения глобального горизонтального облучения, местоположение вблизи Кракова, Польша

В случае единиц SAGA - я не знаю. Просто предположение - значения могут соответствовать мгновенной энергии. В ясное небо летний день легко достигает около 800 Вт, даже до 1000 Вт (= 1 кВт), представленных в виде мгновенного значения.

В обоих случаях изменчивость данных в вашей области слишком высока , нереалистична (по крайней мере, я не вижу какой-либо местности или других объектов, которые должны вызывать эффекты затенения и отвечать за такие результаты).

jurajb
источник
Спасибо за предложение. Попробую запустить анализ еще раз. Забавно то, что когда я хотел проверить результаты с 25-метровой цифровой матрицей, используя те же настройки, результаты были в точности такими, как указывает база данных Solargis ...
proteus
Потребовалось много месяцев, чтобы вернуться к этому вопросу, но я продолжил расследование. Интересно то, что значения ближе к правильным только тогда, когда я запускаю анализ на растре, который был преобразован в WGS84 CRS вместо WGS 84 UTM 34, как я изначально основывал. Значения по-прежнему отключены (в некоторых областях даже близко к 0), но в областях, подверженных воздействию солнечного света, цифры меньше выходят из космоса. Может быть, кто-нибудь выяснит, в чем причина этой ошибки. У меня кончились идеи :)
протей