Вопросы к тем, кто работает с UE4/5: как туда подгрузить реальный рельеф (пирамидальный растр) и другие данные (скажем, OpenStreetMap в виде 3D GeoJSON — по некоторым странам все или почти все дома отрисованы в 3D с указанными цветами, материалами и проч.)? Что нужно устанавливать (MacOS), где примеры искать? Можно ли писать расширения на питоне? Видел анонс, что библиотека VTK добавлена в UE4 — пробовал ли кто? Эту библиотеку хорошо знаю, так как пишу расширения для ParaView: https://github.com/mobigroup/ParaView-plugins
Сами понимаете, не стоит вместо медианы брать минимальное значение. Если данных мало — можно первый квартиль взять. Если совсем мало данных — анализируйте в два прохода, на первом оцениваете гистограмму и находите валидный интервал значений, на втором фильтруете по нему. Есть и отдельные алгоритмы фильтрации тени, но если у вас площади небольшие — подход на основе одной гистограммы для всей площади (точнее, одна гистограмма для суши и другая для воды, если нужно) работает отлично. Весь композит я использую только для визуализации, а работаю с данными по каналам — выделяю высокочастотные компоненты для детализации рельефа и потом гравики, что мне нужно для решения обратной задачи гравики и построения 3д модели плотности среды для геологоразведочных проектов. На Linkedin у меня много про это постов и статей, от теории до практики.
Июль 2019 года, в скрипте (см. выше) месяц поменял. Резкие тени фильтруются тоже, это не проблема. Для своих целей я еще удаляю шумовую компоненту пространственного спектра (масштаб одного пикселя) — кажется крохоборством, но это существенно, и полученный композит отлично годится для дальнейшей обработки.
Это именно выделение кольцевых форм, так что можно отличить одно большое дерево от более мелкой растительности. Ну а фильтрация в спектральной области понятно зачем нужна — чтобы работать только с объектами интересующих масштабов.
А вырубки вы, надеюсь, не глазами ищете? Сделайте оконный спектральный анализ и свертку с гауссовой функцией — увидите, что получится. Понимаете, на определенном масштабе кроны достаточно симметричны (круговая симметрия) и это легко выделить.
Тем же методом и радарные данные обрабатываются :) Экстент назовите, который вас интересует, посмотрим — широта_мин, долгота_мин, широта_макс, долгота_макс.
Хорошо, смотрим на ту же территорию июль:
И здесь явно речь не идет про озвученную вами 100% облачность! Притом, что мы использовали простейший скрипт обработки.
Upd. Дополним еще данными Sentinel-2
Тоже взят скрипт из примеров GEE для нужного района и времени с ограничением не более 20% облачности на сцене.
А теперь возьмем минимальное значение вместо медианы — облака это точно отфильтрует:
Итого — ваша задача превратилась из не решаемой в элементарную, верно?:) Последней картинки вам может вполне хватить, трудозатраты на это — запуск официального примера и замена функции фильтрации медианы на минимум. Куда уж проще.
Еще можно посмотреть другие спутники, можно подобрать более подходящий алгоритм фильтрации облаков (обычно для летних снимков оценивают наиболее зеленый и наиболее синий пиксели, чтобы выбрать наилучшее значение для суши и воды, вместо медианной и минимальной фильтрации).
Возьмем скрипт примера из GEE и добавим фильтр облачности (не более 20% облаков) и фильтр по дате (май 2019) и отфильтруем по заданной территории (прямоугольник 29.5, 59.5, 31.5, 60.5 — Санкт-Петербург примерно в центре).
Получаем композитное изображение с полным покрытием:
На мой взгляд, тут есть некоторые небольшие артефакты, их можно вычистить более аккуратной фильтрацией облаков. Как видим, ситуация на деле далека от "не быть никаких снимков вообще".
Вот и сам скрипт GEE:
// This example uses the Sentinel-2 QA band to cloud mask
// the collection. The Sentinel-2 cloud flags are less
// selective, so the collection is also pre-filtered by the
// CLOUDY_PIXEL_PERCENTAGE flag, to use only relatively
// cloud-free granule.
// Function to mask clouds using the Sentinel-2 QA band.
function maskS2clouds(image) {
var qa = image.select('QA60')
// Bits 10 and 11 are clouds and cirrus, respectively.
var cloudBitMask = 1 << 10;
var cirrusBitMask = 1 << 11;
// Both flags should be set to zero, indicating clear conditions.
var mask = qa.bitwiseAnd(cloudBitMask).eq(0).and(
qa.bitwiseAnd(cirrusBitMask).eq(0))
// Return the masked and scaled data, without the QA bands.
return image.updateMask(mask).divide(10000)
.select("B.*")
.copyProperties(image, ["system:time_start"])
}
// Set map area
var area = ee.Geometry.Rectangle(29.5, 59.5, 31.5, 60.5);
Map.centerObject(area, 8);
// Map the function over one year of data and take the median.
// Load Sentinel-2 TOA reflectance data.
var images = ee.ImageCollection('COPERNICUS/S2_SR')
.filterDate('2019-05-01', '2019-05-31')
// Pre-filter to get less cloudy granules.
.filter(ee.Filter.lt('CLOUDY_PIXEL_PERCENTAGE', 20))
.map(function(image) { return image.clip(area); });
var composite = images
.map(maskS2clouds)
.median()
// Display the results.
Map.addLayer(composite, {bands: ['B4', 'B3', 'B2'], min: 0, max: 0.3}, 'RGB')
Еще раз повторюсь — с каждой сцены выбираете не облачные ПИКСЕЛЫ и потом из них строите мозаику. На каждом снимке есть пикселы, не покрытые облаками — вот не припомню такого, чтобы облачное покрытие было 100% для всей сцены.
Возьмите некоторые области СЗФО, там облачность такая, что будет один безоблачный снимок...
Не нужно искать безоблачные снимки! Возьмите облачные и маскируйте облачные пиксели — по соответствующему спектральному каналу и, если хотите, дополнительные маски добавьте. Лично я часто сталкиваюсь с около экваториальными территориями — там безоблачных снимков не бывает вообще, так что только фильтрация безоблачных пикселов с разных сцен спасает (и последующая медианная фильтрация попиксельно).
Ситуация когда полполя в Landsat, а полполя в Sentinel — просто рядовая.
Так и анализируйте раздельно — используя потом разные пороговые коэффициенты для NDVI по Landsat и Sentinel-2. Точнее будет, чем пытаться привести результат к единому NDVI и по нему анализировать.
Вот мозаика по снимкам за 3 года — все отлично с цветами, на мой взгляд. Облачные пиксели исключены из обработки фильтрацией. Делается бесплатно в Google Earth Engine.
Разные спутники с разным оборудованием и разными спектральными частотами каналов и самими каналами — универсально никак нельзя объединить. А вот для конкретной задачи и территории — можно сравнить значения NDVI для перерывающейся области разных снимков и объединить их. Кстати, вы точно не отдельными сценами оперируете, а набором фильтрованных от облаков сцен с медианной фильтрацией значений каждого пиксела? Для Sentinel-2 известно:
With two satellites all regular areas indicated above will be revisited every five days under the same viewing conditions.
Даже если вам нужно как можно чаще анализ делать — можно маскировать облачные пиксели, получая частичное покрытие NDVI.
Как указано — все снимки с весны 2017 доступны. Сравните с «Sentinel-2B is a European optical imaging satellite that was launched on 7 March 2017.» Спутник Sentinel 2A с лета 2015 летает, то есть примерно полтора года архива по нему не обработаны. В любом случае, для существенно большей истории наблюдений смотрите Landsat 8 или предыдущие — по ним тоже есть датасеты TOA и SR.
Слышали ли вы что-нибудь про воспроизводимость исследований?.. Есть же готовый датасет Sentinel-2 Surface Reflectance (c атмосферной коррекцией, коррекцией угла съемки, положения Солнца,..) https://developers.google.com/earth-engine/datasets/catalog/COPERNICUS_S2_SR Берите данные отсюда и ваша работа будет воспроизводима — может, вам же и пригодится в дальнейшем.
P.S. А вообще лучше бы обойтись минимумом коррекций — например, посмотрите TOA (Top of Atmosphere Reflectance). Surface Reflectance снимков с перекрытием заметно отличается, что физически некорректно, так что на практике необходимо использовать серии снимков для создания композитного изображения, при этом фильтровать по маске облачности (приведенные в статье снимки явно очень облачные). Вот как пример, я как раз сегодня интересную статью про композит Sentinel-2 TOA на Google Earth Engine нашел и воспроизвел: https://github.com/mobigroup/gis-snippets/tree/master/GEE
Самого интересного не сказано — Dask это решение кластерное, так что готовый скрипт/ноутбук можно запустить на кластере! Например, можно создать кластер одинаковых инстансов AWS EC2 и на одном из инстансов запустить процесс-планировщик, а на остальных — рабочие процессы. Для примера вот мой скрипт инициализации (включает еще и установку разнообразного ГИС софта) на гитхабе: https://github.com/mobigroup/gis-snippets/blob/master/aws/ec2_launch_ubuntu_bionic_python3_dask_cluster.sh Замечу, что на практике стоит устанавливать dask непосредственно из https://github.com/dask/dask.git Также рекомендую посмотреть на связанные библиотеки визуализации больших данных — в том числе, позволяют легко отобразить сотни гигабайт (бинарных) данных на обычном лаптопе (например, на Apple MacBook Pro 15" 2013, 8GB RAM, не говоря уже про более современные) — https://github.com/holoviz/datashader и https://github.com/holoviz/holoviews
Как раз не проблема — пример с PgRouting я выложить могу, скажем, участок дорожной сети OSM по Германии и роутинг на нем. Интересно? Я уже обещал на хабре статью про роутинг написать, вот как раз думаю, что туда включить. Пока тут комментарии писал, много всего уже вспомнил подходящего:)
В статье вообще не сказано про VRP — вы это придумали уже позже, в комментариях. Потому я и задаю вопрос, что вообще непонятно, что же вы делаете. В статье сказано только про алгоритм Дейкстры.
Погодите, вы же в статье про реальный кейс говорите, а не теоретический. То есть вы считаете матрицу весов для всепланетарного дорожного графа даже при роутинге по одной улице города? И грузите всю матрицу в память? Абсурд какой-то… Хотя приведенное вами время вычислений вполне соответствует такому подходу…
Да, это несложно. Выкладывайте нужный кусок вашего маршрутного графа и набор точек и вашу реализацию и результат. Я лично берусь показать вариант с PgRouting и, если будет смысл, еще каким движком.
Вопросы к тем, кто работает с UE4/5: как туда подгрузить реальный рельеф (пирамидальный растр) и другие данные (скажем, OpenStreetMap в виде 3D GeoJSON — по некоторым странам все или почти все дома отрисованы в 3D с указанными цветами, материалами и проч.)? Что нужно устанавливать (MacOS), где примеры искать? Можно ли писать расширения на питоне? Видел анонс, что библиотека VTK добавлена в UE4 — пробовал ли кто? Эту библиотеку хорошо знаю, так как пишу расширения для ParaView: https://github.com/mobigroup/ParaView-plugins
Сами понимаете, не стоит вместо медианы брать минимальное значение. Если данных мало — можно первый квартиль взять. Если совсем мало данных — анализируйте в два прохода, на первом оцениваете гистограмму и находите валидный интервал значений, на втором фильтруете по нему. Есть и отдельные алгоритмы фильтрации тени, но если у вас площади небольшие — подход на основе одной гистограммы для всей площади (точнее, одна гистограмма для суши и другая для воды, если нужно) работает отлично. Весь композит я использую только для визуализации, а работаю с данными по каналам — выделяю высокочастотные компоненты для детализации рельефа и потом гравики, что мне нужно для решения обратной задачи гравики и построения 3д модели плотности среды для геологоразведочных проектов. На Linkedin у меня много про это постов и статей, от теории до практики.
Июль 2019 года, в скрипте (см. выше) месяц поменял. Резкие тени фильтруются тоже, это не проблема. Для своих целей я еще удаляю шумовую компоненту пространственного спектра (масштаб одного пикселя) — кажется крохоборством, но это существенно, и полученный композит отлично годится для дальнейшей обработки.
Метод имеет кучу названий — кольцевое преобразование Хафа, преобразование Радона, фокальный анализ,… Вот можете на Linkedin посты глянуть:
https://www.linkedin.com/posts/alexey-pechnikov_circlet-transform-robust-activity-6634335533017456640-u4BP/
https://www.linkedin.com/posts/alexey-pechnikov_geophysical-applications-circular-activity-6634334529068859392-Pt7X/
https://www.linkedin.com/posts/alexey-pechnikov_radon-transform-methodology-activity-6629799196331470848-7-X-/
Это именно выделение кольцевых форм, так что можно отличить одно большое дерево от более мелкой растительности. Ну а фильтрация в спектральной области понятно зачем нужна — чтобы работать только с объектами интересующих масштабов.
Хех, ок. А я еще подумал, что это вам в теплые края захотелось ;) Смотрим Sentinel-2 SR:
Это вовсе не 100% облачность, согласны?
Пожалуйте:
А вырубки вы, надеюсь, не глазами ищете? Сделайте оконный спектральный анализ и свертку с гауссовой функцией — увидите, что получится. Понимаете, на определенном масштабе кроны достаточно симметричны (круговая симметрия) и это легко выделить.
Тем же методом и радарные данные обрабатываются :) Экстент назовите, который вас интересует, посмотрим — широта_мин, долгота_мин, широта_макс, долгота_макс.
Хорошо, смотрим на ту же территорию июль:
И здесь явно речь не идет про озвученную вами 100% облачность! Притом, что мы использовали простейший скрипт обработки.
Upd. Дополним еще данными Sentinel-2
Тоже взят скрипт из примеров GEE для нужного района и времени с ограничением не более 20% облачности на сцене.
А теперь возьмем минимальное значение вместо медианы — облака это точно отфильтрует:
Итого — ваша задача превратилась из не решаемой в элементарную, верно?:) Последней картинки вам может вполне хватить, трудозатраты на это — запуск официального примера и замена функции фильтрации медианы на минимум. Куда уж проще.
Еще можно посмотреть другие спутники, можно подобрать более подходящий алгоритм фильтрации облаков (обычно для летних снимков оценивают наиболее зеленый и наиболее синий пиксели, чтобы выбрать наилучшее значение для суши и воды, вместо медианной и минимальной фильтрации).
Возьмем скрипт примера из GEE и добавим фильтр облачности (не более 20% облаков) и фильтр по дате (май 2019) и отфильтруем по заданной территории (прямоугольник 29.5, 59.5, 31.5, 60.5 — Санкт-Петербург примерно в центре).
Получаем композитное изображение с полным покрытием:
На мой взгляд, тут есть некоторые небольшие артефакты, их можно вычистить более аккуратной фильтрацией облаков. Как видим, ситуация на деле далека от "не быть никаких снимков вообще".
Вот и сам скрипт GEE:
Еще раз повторюсь — с каждой сцены выбираете не облачные ПИКСЕЛЫ и потом из них строите мозаику. На каждом снимке есть пикселы, не покрытые облаками — вот не припомню такого, чтобы облачное покрытие было 100% для всей сцены.
Использовать можно, выгрузив как GeoTIFF файл.
Не нужно искать безоблачные снимки! Возьмите облачные и маскируйте облачные пиксели — по соответствующему спектральному каналу и, если хотите, дополнительные маски добавьте. Лично я часто сталкиваюсь с около экваториальными территориями — там безоблачных снимков не бывает вообще, так что только фильтрация безоблачных пикселов с разных сцен спасает (и последующая медианная фильтрация попиксельно).
Так и анализируйте раздельно — используя потом разные пороговые коэффициенты для NDVI по Landsat и Sentinel-2. Точнее будет, чем пытаться привести результат к единому NDVI и по нему анализировать.
Вот мозаика по снимкам за 3 года — все отлично с цветами, на мой взгляд. Облачные пиксели исключены из обработки фильтрацией. Делается бесплатно в Google Earth Engine.
Разные спутники с разным оборудованием и разными спектральными частотами каналов и самими каналами — универсально никак нельзя объединить. А вот для конкретной задачи и территории — можно сравнить значения NDVI для перерывающейся области разных снимков и объединить их. Кстати, вы точно не отдельными сценами оперируете, а набором фильтрованных от облаков сцен с медианной фильтрацией значений каждого пиксела? Для Sentinel-2 известно:
Даже если вам нужно как можно чаще анализ делать — можно маскировать облачные пиксели, получая частичное покрытие NDVI.
Как указано — все снимки с весны 2017 доступны. Сравните с «Sentinel-2B is a European optical imaging satellite that was launched on 7 March 2017.» Спутник Sentinel 2A с лета 2015 летает, то есть примерно полтора года архива по нему не обработаны. В любом случае, для существенно большей истории наблюдений смотрите Landsat 8 или предыдущие — по ним тоже есть датасеты TOA и SR.
Слышали ли вы что-нибудь про воспроизводимость исследований?.. Есть же готовый датасет Sentinel-2 Surface Reflectance (c атмосферной коррекцией, коррекцией угла съемки, положения Солнца,..) https://developers.google.com/earth-engine/datasets/catalog/COPERNICUS_S2_SR Берите данные отсюда и ваша работа будет воспроизводима — может, вам же и пригодится в дальнейшем.
P.S. А вообще лучше бы обойтись минимумом коррекций — например, посмотрите TOA (Top of Atmosphere Reflectance). Surface Reflectance снимков с перекрытием заметно отличается, что физически некорректно, так что на практике необходимо использовать серии снимков для создания композитного изображения, при этом фильтровать по маске облачности (приведенные в статье снимки явно очень облачные). Вот как пример, я как раз сегодня интересную статью про композит Sentinel-2 TOA на Google Earth Engine нашел и воспроизвел: https://github.com/mobigroup/gis-snippets/tree/master/GEE
Самого интересного не сказано — Dask это решение кластерное, так что готовый скрипт/ноутбук можно запустить на кластере! Например, можно создать кластер одинаковых инстансов AWS EC2 и на одном из инстансов запустить процесс-планировщик, а на остальных — рабочие процессы. Для примера вот мой скрипт инициализации (включает еще и установку разнообразного ГИС софта) на гитхабе: https://github.com/mobigroup/gis-snippets/blob/master/aws/ec2_launch_ubuntu_bionic_python3_dask_cluster.sh Замечу, что на практике стоит устанавливать dask непосредственно из https://github.com/dask/dask.git Также рекомендую посмотреть на связанные библиотеки визуализации больших данных — в том числе, позволяют легко отобразить сотни гигабайт (бинарных) данных на обычном лаптопе (например, на Apple MacBook Pro 15" 2013, 8GB RAM, не говоря уже про более современные) — https://github.com/holoviz/datashader и https://github.com/holoviz/holoviews
Как раз не проблема — пример с PgRouting я выложить могу, скажем, участок дорожной сети OSM по Германии и роутинг на нем. Интересно? Я уже обещал на хабре статью про роутинг написать, вот как раз думаю, что туда включить. Пока тут комментарии писал, много всего уже вспомнил подходящего:)
В статье вообще не сказано про VRP — вы это придумали уже позже, в комментариях. Потому я и задаю вопрос, что вообще непонятно, что же вы делаете. В статье сказано только про алгоритм Дейкстры.
Погодите, вы же в статье про реальный кейс говорите, а не теоретический. То есть вы считаете матрицу весов для всепланетарного дорожного графа даже при роутинге по одной улице города? И грузите всю матрицу в память? Абсурд какой-то… Хотя приведенное вами время вычислений вполне соответствует такому подходу…
Да, это несложно. Выкладывайте нужный кусок вашего маршрутного графа и набор точек и вашу реализацию и результат. Я лично берусь показать вариант с PgRouting и, если будет смысл, еще каким движком.