Нравятся функции с неявным возвратом значений через изменение аргументов (побочные эффекты)? Ну тогда не используйте предложенную конструкцию. На SO достаточно веток, обсуждающих "правила безопасности" функций с побочными эффектами, но все реально.
Хотите создавать функции без побочных эффектов с явным возвратом значений ("Explicit is better than implicit." — Zen Of Python)? Можете использовать как одну, так и другую конструкции. Оба варианта будут полностью работоспособными. На SO есть ветки обсуждающие что "правильнее".
На суть статьи ни один из вариантов никак не влияет, хотя-бы потому, что "как нужно" не указано. Мы же не будем, устраивать полноценный code review для синтаксического, учебного примера?
Ну и не надо забывать, что вариант с s is None не является эквивалентом s or set(), надо четко представлять в чем разница и плюсы и минусы обеих конструкций. В жизни приходится применять оба подхода. Всегда лучше иметь выбор и знать о том, что логические операторы в Python могут использоваться подобным образом.
Да, вы правы но, если мы обсуждаем коня сферического в вакууме то:
идиоматичным (причем не только в Python), как раз, является возврат значения из функции, а не изменение входных аргументов и, таким образом, неявный возврат значения (да исключения бывают).
в данном примере ничего не планировалось возвращать из функции, это синтетический пример, суть которого в объяснении одной из особенностей языка Python, связанной с временем вычисления аргумента по умолчанию.
Если ваша цель изменять входные аргументы, то, естественно, предложенное решение не подходит. Но потом не удивляйтесь советам типа, передавайте в функцию копию вашей структуры, чтобы функция не могла изменить ее.
А еще добавьте сюда, что ФИАС сам не слишком адекватен ситуации. Столкнулись с тем, что (в провинции) объединились два сельских поселения, а ФИАС об этом ни слухом ни духом.
Вообще странно, почему в ФИАС до сих пор нет координат у адресов. При наличии Почты России можно было-бы сделать хоть жилые дома. Причем достаточно быстро, почтальоны везде ходят, смартфоны у всех.
Полностью согласен. В нашей глубинке все сервисы "ломаются". И подобное тестирование, в лучшем случае, сравнивает техническую сторону сервисов. Хотелось-бы увидеть тестирование покрытия.
Что хорошо с OSM, так это то, что можно самому нарисовать объект, если их единицы.
А как вы находите резкие тени? Вы их потом тоже маскируете и меняете значения?
Вы такие композиты классифицируете или у вас только для визуальных целей? Если классифицируете то насколько точно у вас получается находить требуемые объекты?
Это июль одного года? Какого? Визуально выглядит хорошо.
Да, итоговая облачность далеко не 100% но она явно есть. Вопрос в том, что здесь явно будут присутствовать резкие тени от барашков и сервис на таких данных опасно построить. Если останется даже 20% облачности, то это означает, что из 10 заказов 2 выполнить не удастся, и заранее неизвестно будет облачно или нет. В остальном вопросов нет, для визуального представления все отлично.
Сделайте оконный спектральный анализ и свертку с гауссовой функцией — увидите, что получится.
Если не сложно, можете ссылку на метод? Это к какой поляризации относится? У меня подозрение, что вырубка, при определенных условиях ничем не отличается от невырубки на радаре. Отражение что у вырубки, что у окружающего леса одинаковое.
Экстент (широта_мин, долгота_мин, широта_макс, долгота_макс) 58.5407855054331 37.2814375455109 59.5382353517154 39.1725811832316. За июль, без облаков, без резких теней от "барашков", пожалуйста :-)
Ну с радарами отдельная пестня, там погода влияет, но не как в случае с облаками. Если вам надо найти вырубку, и вы даже знаете квартал, то далеко не всегда она будет видна на радаре. Может быть видна сегодня, а через 3 дня не видна. И вырубка быстроизменяющийся объект, для них подходят или одна сцена или ближайшие друг к другу сцены.
:-) собственно мы обсуждаем метод, но не определили цель, что немного наоборот :-). Конечно, ваш метод применим, особенно для получения визуальных мозаик, собственно я с этим никогда не спорил. Да, метод применим даже для более глубокого анализа когда есть серия близкорасположенных по времени снимков. Но:
у вас в июле много облачности, не факт, что интересующий вас объект будет виден под облачностью
попробуйте собрать мозаику на экстент тайла 37VDF за июль.
Собственно весь вопрос: какую цель мы хотим достичь? Ну а от цели можно и метод выбрать и да, ваш метод важен и нужен и вполне может быть применен. Но есть области, где он работать просто не будет и тогда нужны другие методы. Собственно к радарам обратился именно из-за нехватки оптических данных. За всю осень может не быть ничего кроме "молока"!
почти всегда в начале мая есть немалое количество солнечных дней;
в мае только начинается рост растений, для с/х не подойдет.
Возьмите, например, северную часть Рыбинского водохранилища и Череповец, тайл 37VDF, и возьмите июль. Скорее всего ничего не получится, а даже если получится, то будут четкие тени от маскированных облаков — барашков. Это в том случае если облака замаскируются хорошо. Перистые регулярно пролетают через все фильтры и маски.
Возьмите облачные и маскируйте облачные пиксели — по соответствующему спектральному каналу и, если хотите, дополнительные маски добавьте. Лично я часто сталкиваюсь с около экваториальными территориями — там безоблачных снимков не бывает вообще, так что только фильтрация безоблачных пикселов с разных сцен спасает (и последующая медианная фильтрация попиксельно).
Извините, но никак в толк не возьму, что маскировать если облачность 100%? Наверное на экваторе нет смены времен года и такой подход оправдан. Но если у вас один приемлемый снимок в начале мая, потом облачность непролазная, потом один в июле, следующий, может быть осенью, а потом зимой в морозы и больше ничего. Правильно ли я понял, что надо майские пиксели смешивать с июльскими? Что даст маскирование? Ну уберется 75% снимка, как это поможет при условии, что больше на эту территорию снимков нет за интересующий период нет? Бывает необходимость анализа внутри определенного периода, например только во время цветения определенного растения, так запросто в цветение может не быть никаких снимков вообще, только 100% облачность.
Ну и облака бывают мелкими барашками и солнце низко, но яркое, тогда будут четкие тени от облаков на земле, которые пока непонятно как автоматически находить и маскировать. В СЗФО не получается даже подобрать ближайший Landsat 8 под "гребенку" Landsat 7.
Могли бы вы привести пример того о чем вы говорите, но не за 3 года, а внутри сезона, желательно лета, например, для средней полосы европейской части РФ?
Ну средняя за 3 года конечно получится, даже по СЗФО, внутри одного года с высокой вероятностью не получится, точнее зависит от региона. В Даурии получится, там под 300 солнечных дней в году, в других регионах по 60 солнечных дней в году.
А Google Earth Engine потом в как WMTS у себя в проекте можно использовать?
Спектральные диапазоны каналов в значительной степени пересекаются у разных КА, поэтому можно попытаться найти общий знаменатель. Вопрос в том, насколько это применимо. Думаю для задач анализа тренда, например NDVI, — более чем. Тут попытались Harmonized Landsat Sentinel-2, признаюсь, однако, что результат не проверял.
Кстати, вы точно не отдельными сценами оперируете, а набором фильтрованных от облаков сцен с медианной фильтрацией значений каждого пиксела?
Вы про композитный результат на основе серии снимков (я так понял revisit time вы для этого привели)? Нет, я так не делаю. Причин несколько:
Возьмите некоторые области СЗФО, там облачность такая, что будет один безоблачный снимок в мае, один в июле, а следующий в декабре-январе. И revisit time даже чаще чем 5 дней, бывает даже через день, но увы… облака.
На данный момент мои интересы в стороне от сельского хозяйства, мне не особо сейчас нужны атмосферные коррекции и фильтрации. Меня больше интересует лес и обработка радаров Sentinel-1.
Но да, про фильтрацию я согласен, если есть набор данных, то делать можно.
Все же, гармонизация Landsat и Sentinel важный вопрос в районах с частой облачностью. Ситуация когда полполя в Landsat, а полполя в Sentinel — просто рядовая.
А не в курсе ли вы на счет подвижек по гармонизации данных Landsat и Sentinel? Проблема в том, что в СЗФО всегда очень облачно и приходится использовать часть данных Landsat, а часть Sentinel-2. Из-за отсутствия гармонизации, что TOA, что BOA будут разными. А если у вас поле, у которого часть на S2, а часть на L8, то получается полная жесть, про анализ NDVI можно забыть.
Помню, что где-то мелькал проект по гармонизации этих данных, но как-то перестал следить и где-то потерялось все.
Честно говоря не знаю. Можно посмотреть или OrfeoToolbox или, кажется, видел это в ScanEx Image Processor. Orfeo хорош тем, что там есть API, в т.ч. для python.
Но общая проблема в том, что из-за облачности очень тяжело найти тайлы примерно совпадающие по периоду съемки. Это приведет к тому, что с одного края у вас будут тайлы июльские, а с другого майские, а такие, сильно не совпадающие по времени тайлы, практически невозможно отбалансировать, ну только если это не пустыня. Так что для моих задач тональная балансировка не актуальна.
Хотя, сам долго жил в Даурии, солнца там очень много, может для Даурии и актуально делать бесшовные тонально сбалансированные мозаики.
Мне кажется вы путаете тональную балансировку снимков и атмосферную коррекцию — Atmospheric Correction. Для первой задачи подходит растровый редактор, вторая — очень сложная научная задача.
По ссылке в моем комментарии есть информация о проекте MAJA от ФранцКосмоса, похоже, что там более соответствующие друг-другу результаты получаются. MAJA бесплатна для некоммерческого использования, но сразу скажу, что сам не пробовал. Ну и задачи атмосферной коррекции могут быть разными, если нужно прямо вот суперточный BOA, то это одно, а если нужно, например, отслеживать динамику NDVI, то главное, чтобы результаты отражали реальный тренд.
Нравятся функции с неявным возвратом значений через изменение аргументов (побочные эффекты)? Ну тогда не используйте предложенную конструкцию. На SO достаточно веток, обсуждающих "правила безопасности" функций с побочными эффектами, но все реально.
Хотите создавать функции без побочных эффектов с явным возвратом значений ("Explicit is better than implicit." — Zen Of Python)? Можете использовать как одну, так и другую конструкции. Оба варианта будут полностью работоспособными. На SO есть ветки обсуждающие что "правильнее".
На суть статьи ни один из вариантов никак не влияет, хотя-бы потому, что "как нужно" не указано. Мы же не будем, устраивать полноценный code review для синтаксического, учебного примера?
Ну и не надо забывать, что вариант с
s is Noneне является эквивалентомs or set(), надо четко представлять в чем разница и плюсы и минусы обеих конструкций. В жизни приходится применять оба подхода. Всегда лучше иметь выбор и знать о том, что логические операторы в Python могут использоваться подобным образом.Эпитеты, пожалуйста, оставьте при себе.
Да, вы правы но, если мы обсуждаем коня сферического в вакууме то:
Если ваша цель изменять входные аргументы, то, естественно, предложенное решение не подходит. Но потом не удивляйтесь советам типа, передавайте в функцию копию вашей структуры, чтобы функция не могла изменить ее.
Мне кажется, что во второй задаче, вместо решения
будет более идиоматично использовать:
Ну и это решение сразу показывает другую особенность Python, когда логический оператор возвращает значение.
А еще добавьте сюда, что ФИАС сам не слишком адекватен ситуации. Столкнулись с тем, что (в провинции) объединились два сельских поселения, а ФИАС об этом ни слухом ни духом.
Вообще странно, почему в ФИАС до сих пор нет координат у адресов. При наличии Почты России можно было-бы сделать хоть жилые дома. Причем достаточно быстро, почтальоны везде ходят, смартфоны у всех.
Полностью согласен. В нашей глубинке все сервисы "ломаются". И подобное тестирование, в лучшем случае, сравнивает техническую сторону сервисов. Хотелось-бы увидеть тестирование покрытия.
Что хорошо с OSM, так это то, что можно самому нарисовать объект, если их единицы.
А как вы находите резкие тени? Вы их потом тоже маскируете и меняете значения?
Вы такие композиты классифицируете или у вас только для визуальных целей? Если классифицируете то насколько точно у вас получается находить требуемые объекты?
Это июль одного года? Какого? Визуально выглядит хорошо.
Да, итоговая облачность далеко не 100% но она явно есть. Вопрос в том, что здесь явно будут присутствовать резкие тени от барашков и сервис на таких данных опасно построить. Если останется даже 20% облачности, то это означает, что из 10 заказов 2 выполнить не удастся, и заранее неизвестно будет облачно или нет. В остальном вопросов нет, для визуального представления все отлично.
Спасибо, посмотрю.
Если не сложно, можете ссылку на метод? Это к какой поляризации относится? У меня подозрение, что вырубка, при определенных условиях ничем не отличается от невырубки на радаре. Отражение что у вырубки, что у окружающего леса одинаковое.
Извините, но вы широту с долготой перепутали, в Ашхабаде наверное все хорошо с облачностью :-) Вы же сами попросили
Я ответил
А я еще подумал почему долгота с широтой в экстенте наоборот находятся :-)
Экстент (широта_мин, долгота_мин, широта_макс, долгота_макс) 58.5407855054331 37.2814375455109 59.5382353517154 39.1725811832316. За июль, без облаков, без резких теней от "барашков", пожалуйста :-)
Ну с радарами отдельная пестня, там погода влияет, но не как в случае с облаками. Если вам надо найти вырубку, и вы даже знаете квартал, то далеко не всегда она будет видна на радаре. Может быть видна сегодня, а через 3 дня не видна. И вырубка быстроизменяющийся объект, для них подходят или одна сцена или ближайшие друг к другу сцены.
:-) собственно мы обсуждаем метод, но не определили цель, что немного наоборот :-). Конечно, ваш метод применим, особенно для получения визуальных мозаик, собственно я с этим никогда не спорил. Да, метод применим даже для более глубокого анализа когда есть серия близкорасположенных по времени снимков. Но:
Собственно весь вопрос: какую цель мы хотим достичь? Ну а от цели можно и метод выбрать и да, ваш метод важен и нужен и вполне может быть применен. Но есть области, где он работать просто не будет и тогда нужны другие методы. Собственно к радарам обратился именно из-за нехватки оптических данных. За всю осень может не быть ничего кроме "молока"!
Да, но май не интересен:
Возьмите, например, северную часть Рыбинского водохранилища и Череповец, тайл 37VDF, и возьмите июль. Скорее всего ничего не получится, а даже если получится, то будут четкие тени от маскированных облаков — барашков. Это в том случае если облака замаскируются хорошо. Перистые регулярно пролетают через все фильтры и маски.
Извините, но никак в толк не возьму, что маскировать если облачность 100%? Наверное на экваторе нет смены времен года и такой подход оправдан. Но если у вас один приемлемый снимок в начале мая, потом облачность непролазная, потом один в июле, следующий, может быть осенью, а потом зимой в морозы и больше ничего. Правильно ли я понял, что надо майские пиксели смешивать с июльскими? Что даст маскирование? Ну уберется 75% снимка, как это поможет при условии, что больше на эту территорию снимков нет за интересующий период нет? Бывает необходимость анализа внутри определенного периода, например только во время цветения определенного растения, так запросто в цветение может не быть никаких снимков вообще, только 100% облачность.
Ну и облака бывают мелкими барашками и солнце низко, но яркое, тогда будут четкие тени от облаков на земле, которые пока непонятно как автоматически находить и маскировать. В СЗФО не получается даже подобрать ближайший Landsat 8 под "гребенку" Landsat 7.
Могли бы вы привести пример того о чем вы говорите, но не за 3 года, а внутри сезона, желательно лета, например, для средней полосы европейской части РФ?
Ну средняя за 3 года конечно получится, даже по СЗФО, внутри одного года с высокой вероятностью не получится, точнее зависит от региона. В Даурии получится, там под 300 солнечных дней в году, в других регионах по 60 солнечных дней в году.
А Google Earth Engine потом в как WMTS у себя в проекте можно использовать?
Спектральные диапазоны каналов в значительной степени пересекаются у разных КА, поэтому можно попытаться найти общий знаменатель. Вопрос в том, насколько это применимо. Думаю для задач анализа тренда, например NDVI, — более чем. Тут попытались Harmonized Landsat Sentinel-2, признаюсь, однако, что результат не проверял.
Вы про композитный результат на основе серии снимков (я так понял revisit time вы для этого привели)? Нет, я так не делаю. Причин несколько:
Но да, про фильтрацию я согласен, если есть набор данных, то делать можно.
Все же, гармонизация Landsat и Sentinel важный вопрос в районах с частой облачностью. Ситуация когда полполя в Landsat, а полполя в Sentinel — просто рядовая.
А не в курсе ли вы на счет подвижек по гармонизации данных Landsat и Sentinel? Проблема в том, что в СЗФО всегда очень облачно и приходится использовать часть данных Landsat, а часть Sentinel-2. Из-за отсутствия гармонизации, что TOA, что BOA будут разными. А если у вас поле, у которого часть на S2, а часть на L8, то получается полная жесть, про анализ NDVI можно забыть.
Помню, что где-то мелькал проект по гармонизации этих данных, но как-то перестал следить и где-то потерялось все.
Честно говоря не знаю. Можно посмотреть или OrfeoToolbox или, кажется, видел это в ScanEx Image Processor. Orfeo хорош тем, что там есть API, в т.ч. для python.
Но общая проблема в том, что из-за облачности очень тяжело найти тайлы примерно совпадающие по периоду съемки. Это приведет к тому, что с одного края у вас будут тайлы июльские, а с другого майские, а такие, сильно не совпадающие по времени тайлы, практически невозможно отбалансировать, ну только если это не пустыня. Так что для моих задач тональная балансировка не актуальна.
Хотя, сам долго жил в Даурии, солнца там очень много, может для Даурии и актуально делать бесшовные тонально сбалансированные мозаики.
Мне кажется вы путаете тональную балансировку снимков и атмосферную коррекцию — Atmospheric Correction. Для первой задачи подходит растровый редактор, вторая — очень сложная научная задача.
По ссылке в моем комментарии есть информация о проекте MAJA от ФранцКосмоса, похоже, что там более соответствующие друг-другу результаты получаются. MAJA бесплатна для некоммерческого использования, но сразу скажу, что сам не пробовал. Ну и задачи атмосферной коррекции могут быть разными, если нужно прямо вот суперточный BOA, то это одно, а если нужно, например, отслеживать динамику NDVI, то главное, чтобы результаты отражали реальный тренд.