Форумы GIS-Lab.info

Доброго времени суток.
Пол года назад сделал из растра или вектора (непомню, но для наглядности показываю растр)

: GRASS.png (12.33 КБ) 13901 просмотр

вот такое (по красным и фиолетвым линиям)

: GRASS2.png (43.44 КБ) 13901 просмотр

Но сейчас, хоть убейте, не могу вспомнить как делал. Идея была простая интерполировать линии чтобы получить растр для дальнейших расчетов. Интерполирование поверхности в GRASS перепробовал (yfghbvth r.surf.idw2)...не похоже:

: GRASS3.png (69.96 КБ) 13901 просмотр

На буферные зоны - не похоже.

Подскажите как можна такое сделать. А то, старость не в радость

Спасибо.

А какое требование к результату интерполяции? Чем второй рисунок лучше третьего? Тем, что линии прямые или тем, что на перекрестках значения растра просуммированы или еще что?

Другими словами, какова цель интерполяции?

[ Сообщение с мобильного устройства ]

KolesovDmitry писал(а):А какое требование к результату интерполяции? Чем второй рисунок лучше третьего? Тем, что линии прямые или тем, что на перекрестках значения растра просуммированы или еще что?
Другими словами, какова цель интерполяции?

Цель интерполяции получить/заполнить значениями растр так чтобы значения были свяаны с основной линией (растр 1) и повторяли геометрию линий. На пересечении должно быть либо большее из значений либо сумма. Поскольку дальнейшие рассчеты предполагают использование значений растра из линий, не только в координатах линий, но и по нормали к ним, где в исходном растре NULL, то есть использовать значения из полученной интерполяцией/буферизацией области вне линий. Линии имеют разные значения растра. Это что-то похоже к обратной задаче выделения водотоков по ЦМР. Есть линии, надо получить типа водосборные бассейны, но при этом нет ЦМР. Идеально было бы, если это была бы не интерполяция а просто что-то типа буферизация с заполнением значениями из линии. Но, без потери/обьединения соседних мелких кусков других линейных обьектов.

Растр 2 отличается от растра 3 тем что при интерполяции с растровых линий на растре 3 вылазят артефакты вследствии ячеистости растра. И на пересечениях в растре меньшие значения накрывают большие. Появляются разрывы сплошных линий с большими значениями растра. В этом смысле растр 2 более приемлем.

SBoris, если вы делали это в GRASS, не осталось ли у вас области/набора? Тогда можно было бы просто посмотреть использованные команды...

SBoris писал(а):На буферные зоны - не похоже.

А мне кажется, что именно на них и похоже. В создании растра №2 могли поучаствовать модули r.grow.distance и r.buffer.

Судя по описанию задачи, вам должен подойти модуль r.grow (без distance). Нужно только предварительно убедиться, что в растре 1 в ячейках на перекрестках хранится максимальное значение из пересекающихся категорий.

Да и результаты, приведенные на растре 2, похожи на то, что выходит из r.grow. Хотя есть и отличия: похоже, что при его построении ячейки перекрестков были просуммированы.

[ Сообщение с мобильного устройства ]

amuriy писал(а):SBoris, если вы делали это в GRASS, не осталось ли у вас области/набора? Тогда можно было бы просто посмотреть использованные команды...

Посмотрел. Я импортировал tiff.
Да, нашел/вспомнил откуда ноги растут. У меня тогда под руками был ArcMap9.3 и такое я сотворил там. Но не помню как. Потом результат растр WGS84 -> в laea-> импортировал в GRASS...
К сожалению, на моем ноуте нет ArcMap9.3 лицензия кончилась - и пропробовать поэкспериментировать - не могу.

Если растр 2 был бы создан r.growth.distance, то не было бы суммирования на пересечениях, как это на растре 2.

Буферные зоны сливаются для разных категорий линий при необходимых мне расстояниях по нормали буферных зон.

KolesovDmitry писал(а):Судя по описанию задачи, вам должен подойти модуль r.grow (без distance). Нужно только предварительно убедиться, что в растре 1 в ячейках на перекрестках хранится максимальное значение из пересекающихся категорий.

Да и результаты, приведенные на растре 2, похожи на то, что выходит из r.grow. Хотя есть и отличия: похоже, что при его построении ячейки перекрестков были просуммированы.

r.grow позволяет выростить поли область и присваивать вырощенной зоне только вручную заданное одно значение. Например

Код: Выделить всё

new=6550

, а мне надо количество регионов = количеству линий и задать каждому региону значение, которое соответствует значению на линии. Вот в чём проблемма.

SBoris писал(а): r.grow позволяет выростить поли область и присваивать вырощенной зоне только вручную заданное одно значение. Например
Код: Выделить всё
new=6550
, а мне надо количество регионов = количеству линий и задать каждому региону значение, которое соответствует значению на линии. Вот в чём проблемма.

Нет-нет, сейчас специально проверил, r.grow выращивает области и присваивает ячейкам те категории, из которых эти ячейки выросли.

Действительно, если указать параметр new, то будут созданы ячейки с указанными категориями, но так вы просто не указывайте этот параметр

SBoris писал(а):Пол года назад сделал из растра или вектора (непомню, но для наглядности показываю растр)

если я правильно понял задачу, то мы делали (в похожих обстоятельствах) примерно так:
1) создать бланковку (растр с нулями)
2) цикл по всем линиям
2.1) растеризовать линию
2.2) сделать дистанционное преобразование
2.3) применить к каждой ячейке функцию от расстояния и типа линии) - получим число вдоль линии,
убывающие от него значения по нормали, и нули за некоторым порогом
2.4) Прибавить результат к бланковке (или взять максимум, или иную функцию по вкусу)

Будет очень похожий результат; считали антропогенную нагрузку от транспорта.

KolesovDmitry писал(а):
SBoris писал(а): r.grow позволяет выростить поли область и присваивать вырощенной зоне только вручную заданное одно значение. Например
Код: Выделить всё
new=6550
, а мне надо количество регионов = количеству линий и задать каждому региону значение, которое соответствует значению на линии. Вот в чём проблемма.
Нет-нет, сейчас специально проверил, r.grow выращивает области и присваивает ячейкам те категории, из которых эти ячейки выросли.

Действительно, если указать параметр new, то будут созданы ячейки с указанными категориями, но так вы просто не указывайте этот параметр

Да, работает в терминале. При больших радиусах получается очень похожее на растр3.

Попробую ка я увеличить разрешение растра линий чтобы избавится от артефактов зазубренности...

gamm писал(а): Будет очень похожий результат; считали антропогенную нагрузку от транспорта.

Считали по ОНД-86?

SBoris писал(а):Считали по ОНД-86?

не, экологи дали эмпирику. Типа на какое расстояние от дороги может забрести сборщик краснокнижных растений

Спасибо всем!

SBoris писал(а):Спасибо всем!

Спасибо в копилку знаний не положишь.

Лучше расскажите, чем дело-то кончилось? Помог <r.grow> или нашёлся другой способ?

amuriy писал(а):
SBoris писал(а):Спасибо всем!
Спасибо в копилку знаний не положишь. Лучше расскажите, чем дело-то кончилось? Помог <r.grow> или нашёлся другой способ?

r.grow - работает, но не совсем так как хочется (просто иначе и не может быть с точки зрения алгоритма буферных зон). Либо делать цикл как советовал

gamm писал(а):1) создать бланковку (растр с нулями)
2) цикл по всем линиям
2.1) растеризовать линию
2.2) сделать дистанционное преобразование...

а потом все растры сложить (пока что не хочу питонить - интуитивно лень почему-то, хотя для меня это не проблема - могу R, SciPy, Octave, SciLab). Поскольку буферная зона заокруглена, то в местах пересечения линий получаются треугольники, которые как бы налазят на линию и пробивают её тонкой линией насквозь. В этом случае они накрывают большие значения растра меньшими, что несовсем корректно даже на растрах с большими разрешениями. Скорее всего я когда-то в ArcMap нашел функцию которая делает растр по алгоритму

gamm писал(а):

(растр 2 в начале поста), но, к сожалению не имею возможности сейчас проверить.

: GRASS5.png (7.49 КБ) 13784 просмотра

. При этом i3-380M/4Gb RAM Debian wheezy на больших значениях радиуса
r.grow долго считает (1-3 часа) и жрёт где-то 80% ресурсов 4х CPU.
Параметр наращивания. В мануале написано - в единицах ячеек. Поставил разрешение растра 1 задал параметр = 100 (для меня оптимально будет 250-300).

Код: Выделить всё

r.grow --overwrite input=dp_car@ruska output=dp_car_growth radius=100

. Дождался пока посчитает...

: GRASSgrow.png (19.69 КБ) 13784 просмотра

Из спортивного интереса посчитал v.surf.rst - дает

: GRASSrst.png (39.7 КБ) 13784 просмотра

- значения меньше нуля - артефакты...
И для полной картины r.surf.idw - в следующем посте (лимит).

Таким обраом две процедуры дают почти идентичный конечный реультат на низких разрешениях растра, а на высоких выскакивают "-" артефакты в интерполяционной процедуре v.surf.rst.
r.grow в пределе (при больших значениях радиуса) даст r.surf.idw. На этом и остановился. С точки зрения правдоподобности распределения параметра в пространстве от линейного источника - правдоподобность на 50%. Других кроме предложеного gamm, как найболее правдоподобного, вариантов не вижу.
Для нескольких линий (2-4) можно вручную поставить значение, а вот при значительном их количестве и наборе вариантов...
Доделаю до конца покажу что получилось, а потом решу програмить или и полученного варианта достаточно будет. Скорее всего надо будет либо делать вариант gamm либо искать ArcMap.

Если есть идеи буду рад услышать.

Вот так вот.

Форумы GIS-Lab.info

Интерполяция линейных обьектов

Интерполяция линейных обьектов

Re: Интерполяция линейных обьектов

Re: Интерполяция линейных обьектов

Re: Интерполяция линейных обьектов

Re: Интерполяция линейных обьектов

Re: Интерполяция линейных обьектов

Re: Интерполяция линейных обьектов

Re: Интерполяция линейных обьектов

Re: Интерполяция линейных обьектов

Re: Интерполяция линейных обьектов

Re: Интерполяция линейных обьектов

Re: Интерполяция линейных обьектов

Re: Интерполяция линейных обьектов

Re: Интерполяция линейных обьектов

Re: Интерполяция линейных обьектов