Можно вроде такого. Все зависит конечно от того насколько детальный векторный слой использовать. Если брать со всеми каналами сеть выглядеть будет и правда монструозно. Но всегда можно картинку упростить и оставить например линейные обьекты с длиной более n км в сети и уже потом назначать ранги.
Про ГЭС и водохранлища - тоже можно преодолеть: переводим полигоны в линии и обьединяем с линейными обьектами. Да, такой подход в лоб породит некоторые "лишние" притоки, но картина в целом изменится не сильно (см. картинку ниже)
Участок речной сети Оби. Цветом и аннотациями показан порядок водотока по Шриву
Вы говорите верно, однако я хотел бы подсветить следующий момент:
Если замерить ширину реки (буквально каждой реки в системе) нет возможности или сбор и визуализация такой информации будет избыточным из-за масштаба карты (неважно что ширина реки 5 м или 50 м, когда в рамке карты показана вся Евразия, все равно обе такие реки попадут в условную категорию "до 100 метров"), то назначать ширину реки обычно принято не по полевым измерениям а по эвристике "ширина реки на карте пропорциональна совокупному количеству притоков в неё втекающих". А это будет как раз порядок реки обсуждаемый в статье. Можно конечно как при составлении топокарт исходить из фактических измерений ширины, но иногда это избыточно.
Плюс еще имеет смысль рассуждать какими материалами картограф оперирует при составлении карт. Если у него / неё есть хорошая растровая подложка (можно даже сьемку с летательного аппарата, не затрагивая тему топокарт) и пару недель в запасе, то можно и в ручную оцифровать с высокой детальностью. Другое дело, если гидрология не является ключевым элементом на картографическом изображении, карту нужно скомпановать за пару часов, а из доступных данных только данные OSM. В таком случае детализация не требуется. В общем, везде есть свои нюансы
Да, вы верно заметили граничный случай, однако в контексте задачи анализа структуры речной сети могу рассудить следующим образом:
Если на данный момент участок речной сети не связан с главной системой (пересох), то следовательно из морфологического анализа речной сети его можно исключить. И потому при назначении рангов даже корректно, как мне кажется, будет такой участок не рассматривать. А когда наполнится водой и мы, например, по спутниковым снимкам отрисуем новую речную сеть, то в анализ можно и включить будет, но это уже потом
С другой стороны, это все конечно очень специфичные примеры. Все таки порядки рек в основном рассчитываются для крупных речных систем, в которых ключевые притоки (для Оби это скажем, будет Иртыш) из системы не выпадают. А если и выпадают, то всегда можно применить подход выше - в зависимости от сезона по разному анализировать, в межень включать только основную систему в анализ, а в половодье - всё до чего руки доятнутся
Вообще конечно чувства после получения завершения поиска работы (и получения оффера) двоякие: с одной стороны результат есть, а с другой - ни в чем во время процесса поиска работы уверенности не было: неважно на какую позицию собеседовался и неважно на каком этапе находился, после первого скрининга, или после финального собеседования - не мог оценить насколько вероятно, что пройду дальше. В тех треках, где был уверен на все 100 получал отказы, а там где сомневался - наоборот.
Хотел бы я дать какие-нибудь практические полезные советы, которые мне помогли, но дело в том, что я не уверен, что КПД моего подхода высокий достаточно, чтобы вам хотеть его повторять. Но могу озвучить пару своих мыслей:
Старался подавать заявки регулярно независимо от текущих результатов - пытался подаваться хотя бы на две вакансии в день, такой режим мне кажется оптимальным, значительно лучше с психологической точки зрения (для меня), чем "в выходные податься второпях на 25, а потом в течение недели не подаваться а просто получать отказы". Отказы к слову игнорировал как мог - забывал про компании также быстро как они про меня - обратную связь не просил, концентрировался только на текущих треках либо на новых открывшихся
Писал сопроводительное письмо честно от себя без использования Chat GPT, старался писать максимально доходчиво и простыми словами обьяснять почему я считаю, что хорошо подхожу на роль. Сопроводительное письмо прикреплял к каждой заявке даже где об этом явно не просили (иногда просят)
По ощущениям, в большинстве компаний мало обращали внимания на профессиональные навыки, как hard skills так и soft, больше на то "понравился ли кандидат или нет". Остюда кстати и невозможность получить обратную связь: если критерий для отбора всегда один, и он субьективный, логично, что ничего кроме "вы супер, но мы просто с другим кандидатом решили продолжить" никто не скажет. Я не знаю как оптимизировать метрику "понравиться рекрутеру и нанимающему менеджеру", поэтому это свое наблюдение игнорировал и пытался сконцентрироваться на том, что я в итоге могу улучшить в процессе поиска работы
Все что выше, к слову, IMHO, но может будет полезно. Желаю Вам удачи в работе (и её поисках, если понадобится)!
Коллеги, всем кто решил заглянуть в комментарии после 16 июня 2024 года небольшой апдейт от меня. Весной 2024 года работу мне пришлось искать еще раз, и вот такие получились результаты:
Количество заявок на которые не было получено ответа: 16 (24 %)
Количество отказов без приглашения на интервью: 35 (53 %)
Количество приглашений на первое собеседование: 15 (23 %)
Среднее время ожидания обратной связи (в случае приглашения на интервью): 9 дней
Среднее время ожидания обратной связи (в случае отказа): 11 дней
Картинка с результатами
Свой подход изложенный в статье я не менял, действовал ровно так же как и зимой: с кастомизацией сопроводительного письма под вакансии. Из опыта общения с рекрутерами могу сказать, что HR'ы сопроводительные письма читают очень редко. Тем не менее в компании, из которой я получил оффер, мое сопроводителььное письмо все таки читали и оно им понравилось (так что в данном случае свою роль это сыграло).
Как видно из результатов выше, весной рынок IT Финляндии для меня оказался значительно оживленней зимы.
И тебе, дорогой читатель, я тоже желаю найти хорошую работу (если ищется) и оставаться на ней (если уже работается) :D
С одной стороны Вы абсолютно правы: и правда никто кроме нас самих за повышение наших собственно навыков до достаточного (для выполнения рабочих обязанностей) уровня не отвечает. Однако здесь речь все таки про решение задачи наиболее эффективного закрытия открытой позиции в компании. Это не только про "нанять человека в штат", но и успешно его интегрировать в рабочие процессы. А в этой связке от хорошего онбординга выигрывают обе стороны: компания получает быстро въехавшего в основные технические и не только особенности проекта специалиста. И что ещё немаловажно, лояльного сотрудника. А новоиспеченный работник получает не сильно стрессовый переход на новую позицию. От такого гладкого перехода все в выигрыше.
То что вам (как компании) нужно на первое время выделить старшего разработчика в помощь новичку и на некоторое время не утюжить его срочными тасками кратно окупится в дальнейшем. Когда новый разработчик будет приносить пользу проекту начиная с первых недель своей работы (спасибо онбордингу), а не с первых месяцев (в случае если его не было).
Согласен, что мое просихождение может накладывать специфику (и скорее всего так и есть) при поиске работы. Косвенно так или иначе это учитывается, ведь под своим бекграундом который был упомянут в посте можно понимать в том числе и мое гражданство \ место где родился \ текущую ситуацию и т.д. И тем не менее не хотелось придавать такую окраску своим выводам иначе легко можно скатиться в выкрики "это потому что я черный!?" даже в том случае когда совсем не это являлось причиной. Поэтом просто сухие факты: "вот я такой-то с такими навыками - такая-то стратегия поиска - вот такие результаты"
А те случаи, которые Вы привели, это конечно чет жоско. Про госструктуры и возразить нечего, в целом распространенная практика не только в Финляндии
Мне кажется чувства которые Вы испытывали во время поиска работы довольно точно пересекаются с моими XD С одной стороны можно сделать вывод, что просто рынок такой "тяжелый" и это для всех нормально так долго искать работу в Финляндии и с приведенной в посте конверсией в пять процентов. Но тут же могу сам себе возразить, что у меня перед глазами есть несколько примеров ребят которые довольно лихо в том же Хельсинки меняли работу за работой.
И в таком случае продолжая мысль вопросом почему они так могут, а у меня так "бодро" не получается? - Тут может быть, либо 1) не прокачанный навык составления резюме и сопроводительных документов (про прохождение интервью я не говорю, ведь до него еще добраться нужно); 2) стратегия неэффективная (может имеет смысл сначала добавляться к людям из потенциальной компании работодателя в LinkedIn, потом выжидать пару месяцев, затем просить предоставить референс на вас, писать рекрутерам в личку и т.д.) либо 3) уровень навыков не дотягивает, либо перетягивает (overqualified). В жизни, как и всегда, скорее всего смесь всех трех. Тем не менее риск по третьему пункту я пытался свести к минимуму находя вакансии в которых я честно себя оценивая закрывал в среднем 80-90 процентов требований.
От себя добавлю еще личное наблюдение. Оба раза когда меня приглашали на интервью в рамках этого периода поиска работы, приглашения эти получались как будто "в обход" стандартной системы. Например, собеседование 1: скрининг мне проводил тех. лид потому что у них не было штатного специалиста для найма сотрудников. На мой вопрос почему он решил меня позвать ведь мой стек несколько отличается от желаемого (в этой вакансии я закрывал хорошо если 70 процентов требований своими текущими навыками и опытом), мне ответили, что "твой опыт все равно нам кажется интересным и собеседование точно имеет смысл провести, а дальше обсудим".
С Вашим комментарием про летние месяцы полностью согласен. Разве что по поводу ВНЖ: если брать формулировку с мигри, то говорить следует не про "внж типа А - до истечения срока действия", а то что в случае нетрудоустроенности в течение трех месяцев с ВНЖ типа А миграционная служба может запустить процесс аннулирования, а вот в случае со счастливым обладателем Blue Card точно это сделает
У них и правда есть формулировка, что "However, we will not cancel your permit if your residence permit expires in less than 6 months or if you have been put on furlough, that is, laid off temporarily.", однако как по мне это все детали. Срок в три месяца указан и в этом разделе тоже
Если у Вас найдется ссылка на источник в котором для ВНЖ типа А не устанавливается порога в три месяца, то буду признателен, если поделитесь
Да, такой подход тоже имеет место быть. Мне кажется, что процесс поиска работы \ найма в IT независимо от позиции примерно одинаков, так что Ваш опыт вполне сопоставим. Специфику тут вносит география. Дело в том, что Финляндия - небольшая страна. Поэтому количество вакансий здесь очень небольшое. К слову поэтому я в последние недели января прекратил подаваться на вакансии - новых просто не появлялось по моему направлению. В таких условиях стратегия веерной рассылки мне не кажется перспективной. В случае более крупного рынка не спорю, подача на десятки ваканский за день и не предполагает кастомного подхода
Да я тоже не нашел в описанном подходе чего-то концептуально неверного (хотя в конце уже начал сомневаться). Однако если представить, что время на поиск работы ограничено только тремя месяцами без второго шанса, то хотелось бы быстрее подойти к офферу чем условные 5 месяцев. А для увеличения шансов воронка уже изначально должна быть более приятной.
Я периодически поглядывал на статистику из реддита. Честно говоря для меня процентовка где примерно треть (округлим в меньшую сторону на всякий случай здесь) всех разосланных резюме приводили к интервью кажется вполне адекватной и ожидаемой. Однако в моем случае этот процент упал до 5
Честно говоря не копал в этом направлении. Возможно я отстал в части осведомленности какие продукты дистанционного зондирования могут подойти для получения NDVI полей высокого разрешения (постараюсь наверстать). С Landsat я до этого работал - потому он в статье и фигурирует
P.S. имею больший опыт работы как раз со спутниками "покрупнее", где разрешение по км или несколько, поэтому тут не моя вотчина. Так что не знаю на данный момент есть ли лучшие аналоги (в плане пространственного разрешения) за которые не нужно будет отдавать месячную зарплату :)
Добрый день, - спасибо за комментарий! Да, Вы правы, однако у меня есть соображения на тему почему редактировать OSM так в данном случае все таки не стоит:
Пространственное разрешение и артефакты с ним связанные. Все таки снимки Landsat подходят для такого грубого площадного анализа, а не для "тонких" уточнений - легко оперировать размерами пикселей в 30 метров когда речь идет про буфер для анализа в несколько тысяч метров и несколько сложнее когда мы говорим про более менее аккуратные полигоны в условиях городской застройки. Для уточнения зеленых зон я бы в таком случае использовал бы скорее подход в лоб (под номером 1), но он, очевидно, и так реализуется в рамках OSM
А для некоторой автоматизации актуализации "зеленого покрова" конечно годится - не спорю
Площади "зеленых зон" при извлечении по порогу NDVI 0.2546
Приветствую. Не делал подобного по причине того, что порог получится частным. То есть будет справедлив только для этого снимка (для того момента времени) и только для выбранной территории, что значит, что очень трудно будет экстраполировать это значение на будущие снимки или на другие тестовые территории. Но чтобы ответить на Ваш вопрос решил таки провести эксперимент и получил следующее число (см. картинку с визуализацией): 0.2546. Но нахождение такого "оптимального" порога конечно решается довольно просто - хоть полным перебором всех возможных значений NDVI. Намного сложнее будет оптимизировать метрику из сегментации Intersection Over Union (IoU) и сделать так, чтобы совпдала не только площадь, но и размеченные площади - пиксель к пикселю
Да, конечно ответим :) Если что - коллеги подскажут более подробно, а начать могу я.
Про ресурсы для обучения и прогнозирования: FEDOT версии 0.6.0 строится поверх, как правило, scikit-learn моделей машинного обучения. Поэтому ресурсов каждый узел потребляет соразмерно соответствующим реализациям sklearn'a. Учитывая, что признаков в таких крупных пайплайнах получается много, то и время обучения для разветвленных пайплайнов на больших временных рядах будет относительно большим. С другой стороны, в FEDOT, как и в большинстве современных AutoML фреймворков реализована система "пресетов". Под пресетом в FEDOT можно понимать сценарий использования. Например, пресет "best_quality" предполагает использование всех возможных в фреймворке моделей без каких-либо ограничений. "fast_train" будет использовать только те модели, которые быстрее обучаются, "gpu" - те модели, которые можно обучать на GPU и так далее. То есть при поиске равновесия между "качество" - "время обучения" в первую очередь стоит смотреть на пресеты. Подробнее можно посмотреть документацию - там описано за что каждый пресет отвечает и какие есть варианты.
Компактность моделей. На размер пайплайнов будут влиять два ключевых параметра: максимально возможная глубина пайплайна(max_depth) и арность узлов (max_arity). То есть при желании можно просить фреймворк выращивать пайплайны побольше и поразветвленней. В другом случае уместно будет задать структурные ограничения на сложность ансамблей.
С третьей стороны, ограничивать сложность пайплайнов можно варьированием параметра "max_pipeline_fit_time". То есть оптимизационное ядро будет отметать все решения, которые обучаются дольше заданного порога.
Если же речь про совсем быстрый способ. Если, как говорится, "нет времени объяснять, нужна модель пять минут назад", то в таком случае подойдёт вариант с "predefined_model", когда фреймворк строит и обучает всего одну модель по заранее определенным правилам. См. раздел "Немного о возможностях конфигурации" в текущей статье.
Говоря про сравнение по быстродействию с нейронными сетями, то конечно обучить связку "траекторная матрица - гребневая регрессия" (а это как правило ключевой составной блок в начальных приближениях FEDOT) значительно быстрее, чем нейронную сеть. При этом, как я понимаю этот ваш компьютер саенс, быстрее такая связка обучаться будет на временных рядах любого размера (хоть одномерных, хоть многомерных) :) Но бенчмарки по производительности не проводил, ровно как и не припомню статьи на эту тему - хотя, возможно, они существуют
И наконец про небольшой набор данных: да, на небольших временных рядах FEDOT в серии наших экспериментов показывал хорошие результаты. Простые модели действительно чаще "выживают" в процессе эволюции на таких данных. Однако, чтобы однозначно ответить на этот вопрос, надо конечно провести сравнение с нейросетевыми моделями, которые идентифицируются (то есть строятся и обучаются / дообучаются) примерно за такое же время, что и ансамбли при помощи FEDOT. Пока напрямую с нейронными сетями таких сравнений не проводили
Спасибо за комментарий! Однако по поводу "проигрывает" не соглашусь. Смотря что взять как критерий.
Если речь идёт про ошибку прогноза у финальной модели, полученной при помощи n-го количества часов работы m-го количества экспертов (как правило n и m здесь совсем немаленькие числа), то пожалуй да, подходы на основе нейронных сетей могут прогнозировать со значительно меньшей ошибкой (хотя и не всегда, но потенциально да, это более эффективные модели). С другой стороны, если речь идёт про интерпретируемость или обобщаемость подхода на смежные задачи (например прогнозирование временных рядов немного других процессов, чем тех для которых была подготовлена модель на основе нейронных сетей), то тут, как мне кажется, как раз GRU/LSTM и трансформеры уже уступают классическим моделям и моделям на основе AutoML описанных в данной статье.
Далее про размерность - для VAR и описанного подхода размерность и не является проблемой - подход учитывает как одномерные временные ряды, так и многомерные. В описанном обобщении, как бы сказать, не сломана обратная совместимость. Проблемой бы можно было обозначить, если бы предлагаемый подход исключал нативное обобщение с одномерного случая на многомерный. И при этом предлагалась бы какая-нибудь совсем новая концепция просто потому что изначальный подход ну никак не подходил бы для решения новых задач. Здесь же всё выглядит как закономерное масштабирование ПО (и подходов при его разработке) на более широкий класс задач. Не баг, а фича :)
И ещё стоит сказать, что AutoML не предполагает исключение нейросетевых подходов в прогнозировании. В фреймворке например LSTM спокойно сущесвует как составной блок пайплайнов, наряду с ARIMA моделями и другими. Поэтому при необходиомсти эволюционный алгоритм способен выстраивать "гибридные" пайплайны, если это будет приводить к уменьшению ошибки прогноза. И если так смотреть на технологию, то описанный AutoML и нейронные сети совсем не являются конкурентами друг другу
Тут важно понять что именно понимается под "ускорением склейки" - не встречал бенчмарки где сравнивалось бы быстродействие разных лагинов. По инструментам, в Lines Ranking плагине, например, используется связка "Исправление геометрии и v.clean GRASS" для модификации не совсем корректных слоёв. Ещё довольно быстро работает инструмент "Примыкание геометрий к слою (Snap geometries to layer eng)". Только нужно выбирать порог склейки вручную. Ниже пример того какие слои можно получать устанавливая различные пороги:
Пример применения инструмента "Примыкание геометрий к слою"
Но это, как говорится, что лежало на поверхности. Вполне возможно, что есть и более подходящие Вам инструменты в арсенале QGIS и не только, просто я о них не слышал
Теоретически да, но это не основная задача, в QGIS для этого есть специализированные инструменты. Плагин (и алгоритм в нём реализованный) предназначен для ранжирования сегментов в рамках уже единого векторного слоя без разрывов. Определенно алгоритм может автоматически исправлять неточности в топологии, такие как небольшие разрывы между рукавами рек. Но если сеть густая, а "дырки" продолжительные и частые, то "исправление геометрии" вполне может испортить исходный слой если попытаться объединять такие сегменты в единую сеть путём варьирования порога склейки. То есть плагин скорее призван справляться с такими разрывами, которые появляются при неточном импорте / экспорте файлов или после применения векторных операций с различными неточностями. Но не задумывался для исправления именно неточных по своей природе слоёв, когда например кто-то просто забыл отвекторизовать канал между двумя реками.
С другой стороны, если разрывы маленькие, то выставление порога склейки вполне может справиться с такой сетью и тогда на выходе вы получите не только корректный векторный слой, но и ещё отранжированный в соответствии с описанным в посте алгоритмом.
Большое спасибо за комментарий и за такую оценку! По поводу предобработки перед началом процесса идентефикации пайплайна - действительно, предварительную "грубую" вычистку данных следует производить перед началом процесса оптимизации (поиска структуры пайплайна). Во первых, это довольно затратный процесс - проводить его перед началом обучения каждого пайплайна расточительно. Во вторых, такая вычистка не отличается вариативностью и её оптимизировать довольно сложно, если вообще возможно.
Однако более тонкую предобработку, такую как энкодинг категориальных признаков и заполнение пропусков можно проводить уже разными способами. Такую предобработку можно и нужно настраивать. Рад, что про наш опыт и реализованный подход Вам было любопытно почитать :)
Мы пробовали алгоритм на нескольких речных сетях (данные OpenStreetMap), из крупных рек: Урал и Обь. Постараюсь ответить по пунктам:
«Проверяли ли работу алгоритма, в случае если река уходит под поверхность земли на некоторое расстояние?» — Нет, такой ситуации мы не встречали при тестировании плагина. Но если вдруг в линейном векторном слое будет присутствовать разрыв, то алгоритм дальше этого разрыва не пойдет присваивать ранги. Так что если имеется разрыв в речной сети, и Вы точно знаете, что сегменты рядом с разрывом в действительности связаны, а не изолированы друг от друга, то можно исправить векторный слой вручную — соединить их. В таком случае алгоритм отработает как требуется.
«Не возникает ли проблема в случае больших островов или редких случаях бифуркации рек?» — Острова в линейном векторном слое — вещь довольная специфическая, они могут возникнуть, если например, мы имели не только векторный линейный слой с реками, а еще и полигональный векторный слой с водохранилищами, озерами и др. В таком случае эти площадные объекты действительно являются частью речной сети и если их не использовать, то речная сеть получится с разрывами (должно было быть водохранилище на этом месте, а его мы отбросили, и водотока в слое на этом месте тоже не оказывается). Выход довольно простой — переводим векторный полигональный слой в линейный (инструмент в QGIS Полигон в линии) и объединяем с изначальным линейным слоем с реками. Вот в таком слое могут быть ситуации, когда алгоритм считает за 2 разные реки берега одного водохранилища. Но с этим ничего поделать мы не смогли, исправлять данные вещи насильно при применении алгоритма мы не пытались, потому что вполне возможен случай, когда река просто разделяется на несколько рукавов, а потом снова сходится и никакие полигональные водные объекты тут не при чем. А вот с бифуркацией да, есть загвоздка. Так как определяющим фактором является местоположение точки впадения реки в водоём, то алгоритм считает, что именно в эту указанную пользователем точку, вся речная сеть и стекает. В таком случае алгоритм будет считать, что отошедшая ранее ветвь является притоком. Как-то отсеять это алгоритм не сможет. Тогда проще будет вручную отделить рукав от речной сети, а затем запустить алгоритм для каждой из частей речной сети отдельно — потом слои можно будет вновь соединить.
«Или в случае разбиения реки на протоки (например, в дельте)» — На рисунке 8 и в анимациях как раз приведен пример такого разбиения. Проблем возникнуть не должно, так как мы в любом случае опираемся на главную реку (назовем её опорным маршрутом в графе), и уже от неё начинаем обходить граф и присваивать ранги. Введение опорного маршрута как раз помогло нам адекватно обрабатывать подобные случаи.
Можно вроде такого. Все зависит конечно от того насколько детальный векторный слой использовать. Если брать со всеми каналами сеть выглядеть будет и правда монструозно. Но всегда можно картинку упростить и оставить например линейные обьекты с длиной более n км в сети и уже потом назначать ранги.
Про ГЭС и водохранлища - тоже можно преодолеть: переводим полигоны в линии и обьединяем с линейными обьектами. Да, такой подход в лоб породит некоторые "лишние" притоки, но картина в целом изменится не сильно (см. картинку ниже)
Вы говорите верно, однако я хотел бы подсветить следующий момент:
Если замерить ширину реки (буквально каждой реки в системе) нет возможности или сбор и визуализация такой информации будет избыточным из-за масштаба карты (неважно что ширина реки 5 м или 50 м, когда в рамке карты показана вся Евразия, все равно обе такие реки попадут в условную категорию "до 100 метров"), то назначать ширину реки обычно принято не по полевым измерениям а по эвристике "ширина реки на карте пропорциональна совокупному количеству притоков в неё втекающих". А это будет как раз порядок реки обсуждаемый в статье. Можно конечно как при составлении топокарт исходить из фактических измерений ширины, но иногда это избыточно.
Плюс еще имеет смысль рассуждать какими материалами картограф оперирует при составлении карт. Если у него / неё есть хорошая растровая подложка (можно даже сьемку с летательного аппарата, не затрагивая тему топокарт) и пару недель в запасе, то можно и в ручную оцифровать с высокой детальностью. Другое дело, если гидрология не является ключевым элементом на картографическом изображении, карту нужно скомпановать за пару часов, а из доступных данных только данные OSM. В таком случае детализация не требуется. В общем, везде есть свои нюансы
Да, вы верно заметили граничный случай, однако в контексте задачи анализа структуры речной сети могу рассудить следующим образом:
Если на данный момент участок речной сети не связан с главной системой (пересох), то следовательно из морфологического анализа речной сети его можно исключить. И потому при назначении рангов даже корректно, как мне кажется, будет такой участок не рассматривать. А когда наполнится водой и мы, например, по спутниковым снимкам отрисуем новую речную сеть, то в анализ можно и включить будет, но это уже потом
С другой стороны, это все конечно очень специфичные примеры. Все таки порядки рек в основном рассчитываются для крупных речных систем, в которых ключевые притоки (для Оби это скажем, будет Иртыш) из системы не выпадают. А если и выпадают, то всегда можно применить подход выше - в зависимости от сезона по разному анализировать, в межень включать только основную систему в анализ, а в половодье - всё до чего руки доятнутся
Рад, что заходили :)
Вообще конечно чувства после получения завершения поиска работы (и получения оффера) двоякие: с одной стороны результат есть, а с другой - ни в чем во время процесса поиска работы уверенности не было: неважно на какую позицию собеседовался и неважно на каком этапе находился, после первого скрининга, или после финального собеседования - не мог оценить насколько вероятно, что пройду дальше. В тех треках, где был уверен на все 100 получал отказы, а там где сомневался - наоборот.
Хотел бы я дать какие-нибудь практические полезные советы, которые мне помогли, но дело в том, что я не уверен, что КПД моего подхода высокий достаточно, чтобы вам хотеть его повторять. Но могу озвучить пару своих мыслей:
Старался подавать заявки регулярно независимо от текущих результатов - пытался подаваться хотя бы на две вакансии в день, такой режим мне кажется оптимальным, значительно лучше с психологической точки зрения (для меня), чем "в выходные податься второпях на 25, а потом в течение недели не подаваться а просто получать отказы". Отказы к слову игнорировал как мог - забывал про компании также быстро как они про меня - обратную связь не просил, концентрировался только на текущих треках либо на новых открывшихся
Писал сопроводительное письмо честно от себя без использования Chat GPT, старался писать максимально доходчиво и простыми словами обьяснять почему я считаю, что хорошо подхожу на роль. Сопроводительное письмо прикреплял к каждой заявке даже где об этом явно не просили (иногда просят)
По ощущениям, в большинстве компаний мало обращали внимания на профессиональные навыки, как hard skills так и soft, больше на то "понравился ли кандидат или нет". Остюда кстати и невозможность получить обратную связь: если критерий для отбора всегда один, и он субьективный, логично, что ничего кроме "вы супер, но мы просто с другим кандидатом решили продолжить" никто не скажет. Я не знаю как оптимизировать метрику "понравиться рекрутеру и нанимающему менеджеру", поэтому это свое наблюдение игнорировал и пытался сконцентрироваться на том, что я в итоге могу улучшить в процессе поиска работы
Все что выше, к слову, IMHO, но может будет полезно. Желаю Вам удачи в работе (и её поисках, если понадобится)!
Коллеги, всем кто решил заглянуть в комментарии после 16 июня 2024 года небольшой апдейт от меня. Весной 2024 года работу мне пришлось искать еще раз, и вот такие получились результаты:
Количество заявок на которые не было получено ответа: 16 (24 %)
Количество отказов без приглашения на интервью: 35 (53 %)
Количество приглашений на первое собеседование: 15 (23 %)
Среднее время ожидания обратной связи (в случае приглашения на интервью): 9 дней
Среднее время ожидания обратной связи (в случае отказа): 11 дней
Свой подход изложенный в статье я не менял, действовал ровно так же как и зимой: с кастомизацией сопроводительного письма под вакансии. Из опыта общения с рекрутерами могу сказать, что HR'ы сопроводительные письма читают очень редко. Тем не менее в компании, из которой я получил оффер, мое сопроводителььное письмо все таки читали и оно им понравилось (так что в данном случае свою роль это сыграло).
Как видно из результатов выше, весной рынок IT Финляндии для меня оказался значительно оживленней зимы.
И тебе, дорогой читатель, я тоже желаю найти хорошую работу (если ищется) и оставаться на ней (если уже работается) :D
С одной стороны Вы абсолютно правы: и правда никто кроме нас самих за повышение наших собственно навыков до достаточного (для выполнения рабочих обязанностей) уровня не отвечает. Однако здесь речь все таки про решение задачи наиболее эффективного закрытия открытой позиции в компании. Это не только про "нанять человека в штат", но и успешно его интегрировать в рабочие процессы. А в этой связке от хорошего онбординга выигрывают обе стороны: компания получает быстро въехавшего в основные технические и не только особенности проекта специалиста. И что ещё немаловажно, лояльного сотрудника. А новоиспеченный работник получает не сильно стрессовый переход на новую позицию. От такого гладкого перехода все в выигрыше.
То что вам (как компании) нужно на первое время выделить старшего разработчика в помощь новичку и на некоторое время не утюжить его срочными тасками кратно окупится в дальнейшем. Когда новый разработчик будет приносить пользу проекту начиная с первых недель своей работы (спасибо онбордингу), а не с первых месяцев (в случае если его не было).
Согласен, что мое просихождение может накладывать специфику (и скорее всего так и есть) при поиске работы. Косвенно так или иначе это учитывается, ведь под своим бекграундом который был упомянут в посте можно понимать в том числе и мое гражданство \ место где родился \ текущую ситуацию и т.д. И тем не менее не хотелось придавать такую окраску своим выводам иначе легко можно скатиться в выкрики "это потому что я черный!?" даже в том случае когда совсем не это являлось причиной. Поэтом просто сухие факты: "вот я такой-то с такими навыками - такая-то стратегия поиска - вот такие результаты"
А те случаи, которые Вы привели, это конечно чет жоско. Про госструктуры и возразить нечего, в целом распространенная практика не только в Финляндии
Мне кажется чувства которые Вы испытывали во время поиска работы довольно точно пересекаются с моими XD С одной стороны можно сделать вывод, что просто рынок такой "тяжелый" и это для всех нормально так долго искать работу в Финляндии и с приведенной в посте конверсией в пять процентов. Но тут же могу сам себе возразить, что у меня перед глазами есть несколько примеров ребят которые довольно лихо в том же Хельсинки меняли работу за работой.
И в таком случае продолжая мысль вопросом почему они так могут, а у меня так "бодро" не получается? - Тут может быть, либо 1) не прокачанный навык составления резюме и сопроводительных документов (про прохождение интервью я не говорю, ведь до него еще добраться нужно); 2) стратегия неэффективная (может имеет смысл сначала добавляться к людям из потенциальной компании работодателя в LinkedIn, потом выжидать пару месяцев, затем просить предоставить референс на вас, писать рекрутерам в личку и т.д.) либо 3) уровень навыков не дотягивает, либо перетягивает (overqualified). В жизни, как и всегда, скорее всего смесь всех трех. Тем не менее риск по третьему пункту я пытался свести к минимуму находя вакансии в которых я честно себя оценивая закрывал в среднем 80-90 процентов требований.
От себя добавлю еще личное наблюдение. Оба раза когда меня приглашали на интервью в рамках этого периода поиска работы, приглашения эти получались как будто "в обход" стандартной системы. Например, собеседование 1: скрининг мне проводил тех. лид потому что у них не было штатного специалиста для найма сотрудников. На мой вопрос почему он решил меня позвать ведь мой стек несколько отличается от желаемого (в этой вакансии я закрывал хорошо если 70 процентов требований своими текущими навыками и опытом), мне ответили, что "твой опыт все равно нам кажется интересным и собеседование точно имеет смысл провести, а дальше обсудим".
С Вашим комментарием про летние месяцы полностью согласен. Разве что по поводу ВНЖ: если брать формулировку с мигри, то говорить следует не про "внж типа А - до истечения срока действия", а то что в случае нетрудоустроенности в течение трех месяцев с ВНЖ типа А миграционная служба может запустить процесс аннулирования, а вот в случае со счастливым обладателем Blue Card точно это сделает
У них и правда есть формулировка, что "However, we will not cancel your permit if your residence permit expires in less than 6 months or if you have been put on furlough, that is, laid off temporarily.", однако как по мне это все детали. Срок в три месяца указан и в этом разделе тоже
Если у Вас найдется ссылка на источник в котором для ВНЖ типа А не устанавливается порога в три месяца, то буду признателен, если поделитесь
Да, такой подход тоже имеет место быть. Мне кажется, что процесс поиска работы \ найма в IT независимо от позиции примерно одинаков, так что Ваш опыт вполне сопоставим. Специфику тут вносит география. Дело в том, что Финляндия - небольшая страна. Поэтому количество вакансий здесь очень небольшое. К слову поэтому я в последние недели января прекратил подаваться на вакансии - новых просто не появлялось по моему направлению. В таких условиях стратегия веерной рассылки мне не кажется перспективной. В случае более крупного рынка не спорю, подача на десятки ваканский за день и не предполагает кастомного подхода
Да я тоже не нашел в описанном подходе чего-то концептуально неверного (хотя в конце уже начал сомневаться). Однако если представить, что время на поиск работы ограничено только тремя месяцами без второго шанса, то хотелось бы быстрее подойти к офферу чем условные 5 месяцев. А для увеличения шансов воронка уже изначально должна быть более приятной.
Я периодически поглядывал на статистику из реддита. Честно говоря для меня процентовка где примерно треть (округлим в меньшую сторону на всякий случай здесь) всех разосланных резюме приводили к интервью кажется вполне адекватной и ожидаемой. Однако в моем случае этот процент упал до 5
Честно говоря не копал в этом направлении. Возможно я отстал в части осведомленности какие продукты дистанционного зондирования могут подойти для получения NDVI полей высокого разрешения (постараюсь наверстать). С Landsat я до этого работал - потому он в статье и фигурирует
P.S. имею больший опыт работы как раз со спутниками "покрупнее", где разрешение по км или несколько, поэтому тут не моя вотчина. Так что не знаю на данный момент есть ли лучшие аналоги (в плане пространственного разрешения) за которые не нужно будет отдавать месячную зарплату :)
Добрый день, - спасибо за комментарий! Да, Вы правы, однако у меня есть соображения на тему почему редактировать OSM так в данном случае все таки не стоит:
Пространственное разрешение и артефакты с ним связанные. Все таки снимки Landsat подходят для такого грубого площадного анализа, а не для "тонких" уточнений - легко оперировать размерами пикселей в 30 метров когда речь идет про буфер для анализа в несколько тысяч метров и несколько сложнее когда мы говорим про более менее аккуратные полигоны в условиях городской застройки. Для уточнения зеленых зон я бы в таком случае использовал бы скорее подход в лоб (под номером 1), но он, очевидно, и так реализуется в рамках OSM
А для некоторой автоматизации актуализации "зеленого покрова" конечно годится - не спорю
Приветствую. Не делал подобного по причине того, что порог получится частным. То есть будет справедлив только для этого снимка (для того момента времени) и только для выбранной территории, что значит, что очень трудно будет экстраполировать это значение на будущие снимки или на другие тестовые территории.
Но чтобы ответить на Ваш вопрос решил таки провести эксперимент и получил следующее число (см. картинку с визуализацией): 0.2546. Но нахождение такого "оптимального" порога конечно решается довольно просто - хоть полным перебором всех возможных значений NDVI. Намного сложнее будет оптимизировать метрику из сегментации Intersection Over Union (IoU) и сделать так, чтобы совпдала не только площадь, но и размеченные площади - пиксель к пикселю
Да, конечно ответим :) Если что - коллеги подскажут более подробно, а начать могу я.
Про ресурсы для обучения и прогнозирования: FEDOT версии 0.6.0 строится поверх, как правило, scikit-learn моделей машинного обучения. Поэтому ресурсов каждый узел потребляет соразмерно соответствующим реализациям sklearn'a. Учитывая, что признаков в таких крупных пайплайнах получается много, то и время обучения для разветвленных пайплайнов на больших временных рядах будет относительно большим. С другой стороны, в FEDOT, как и в большинстве современных AutoML фреймворков реализована система "пресетов". Под пресетом в FEDOT можно понимать сценарий использования. Например, пресет "best_quality" предполагает использование всех возможных в фреймворке моделей без каких-либо ограничений. "fast_train" будет использовать только те модели, которые быстрее обучаются, "gpu" - те модели, которые можно обучать на GPU и так далее. То есть при поиске равновесия между "качество" - "время обучения" в первую очередь стоит смотреть на пресеты. Подробнее можно посмотреть документацию - там описано за что каждый пресет отвечает и какие есть варианты.
Компактность моделей. На размер пайплайнов будут влиять два ключевых параметра: максимально возможная глубина пайплайна(max_depth) и арность узлов (max_arity). То есть при желании можно просить фреймворк выращивать пайплайны побольше и поразветвленней. В другом случае уместно будет задать структурные ограничения на сложность ансамблей.
С третьей стороны, ограничивать сложность пайплайнов можно варьированием параметра "max_pipeline_fit_time". То есть оптимизационное ядро будет отметать все решения, которые обучаются дольше заданного порога.
Если же речь про совсем быстрый способ. Если, как говорится, "нет времени объяснять, нужна модель пять минут назад", то в таком случае подойдёт вариант с "predefined_model", когда фреймворк строит и обучает всего одну модель по заранее определенным правилам. См. раздел "Немного о возможностях конфигурации" в текущей статье.
Говоря про сравнение по быстродействию с нейронными сетями, то конечно обучить связку "траекторная матрица - гребневая регрессия" (а это как правило ключевой составной блок в начальных приближениях FEDOT) значительно быстрее, чем нейронную сеть. При этом, как я понимаю этот ваш компьютер саенс, быстрее такая связка обучаться будет на временных рядах любого размера (хоть одномерных, хоть многомерных) :) Но бенчмарки по производительности не проводил, ровно как и не припомню статьи на эту тему - хотя, возможно, они существуют
И наконец про небольшой набор данных: да, на небольших временных рядах FEDOT в серии наших экспериментов показывал хорошие результаты. Простые модели действительно чаще "выживают" в процессе эволюции на таких данных. Однако, чтобы однозначно ответить на этот вопрос, надо конечно провести сравнение с нейросетевыми моделями, которые идентифицируются (то есть строятся и обучаются / дообучаются) примерно за такое же время, что и ансамбли при помощи FEDOT. Пока напрямую с нейронными сетями таких сравнений не проводили
Спасибо за комментарий! Однако по поводу "проигрывает" не соглашусь. Смотря что взять как критерий.
Если речь идёт про ошибку прогноза у финальной модели, полученной при помощи n-го количества часов работы m-го количества экспертов (как правило n и m здесь совсем немаленькие числа), то пожалуй да, подходы на основе нейронных сетей могут прогнозировать со значительно меньшей ошибкой (хотя и не всегда, но потенциально да, это более эффективные модели). С другой стороны, если речь идёт про интерпретируемость или обобщаемость подхода на смежные задачи (например прогнозирование временных рядов немного других процессов, чем тех для которых была подготовлена модель на основе нейронных сетей), то тут, как мне кажется, как раз GRU/LSTM и трансформеры уже уступают классическим моделям и моделям на основе AutoML описанных в данной статье.
Далее про размерность - для VAR и описанного подхода размерность и не является проблемой - подход учитывает как одномерные временные ряды, так и многомерные. В описанном обобщении, как бы сказать, не сломана обратная совместимость. Проблемой бы можно было обозначить, если бы предлагаемый подход исключал нативное обобщение с одномерного случая на многомерный. И при этом предлагалась бы какая-нибудь совсем новая концепция просто потому что изначальный подход ну никак не подходил бы для решения новых задач. Здесь же всё выглядит как закономерное масштабирование ПО (и подходов при его разработке) на более широкий класс задач. Не баг, а фича :)
И ещё стоит сказать, что AutoML не предполагает исключение нейросетевых подходов в прогнозировании. В фреймворке например LSTM спокойно сущесвует как составной блок пайплайнов, наряду с ARIMA моделями и другими. Поэтому при необходиомсти эволюционный алгоритм способен выстраивать "гибридные" пайплайны, если это будет приводить к уменьшению ошибки прогноза. И если так смотреть на технологию, то описанный AutoML и нейронные сети совсем не являются конкурентами друг другу
Тут важно понять что именно понимается под "ускорением склейки" - не встречал бенчмарки где сравнивалось бы быстродействие разных лагинов. По инструментам, в Lines Ranking плагине, например, используется связка "Исправление геометрии и v.clean GRASS" для модификации не совсем корректных слоёв. Ещё довольно быстро работает инструмент "Примыкание геометрий к слою (Snap geometries to layer eng)". Только нужно выбирать порог склейки вручную. Ниже пример того какие слои можно получать устанавливая различные пороги:
Но это, как говорится, что лежало на поверхности. Вполне возможно, что есть и более подходящие Вам инструменты в арсенале QGIS и не только, просто я о них не слышал
Теоретически да, но это не основная задача, в QGIS для этого есть специализированные инструменты. Плагин (и алгоритм в нём реализованный) предназначен для ранжирования сегментов в рамках уже единого векторного слоя без разрывов. Определенно алгоритм может автоматически исправлять неточности в топологии, такие как небольшие разрывы между рукавами рек. Но если сеть густая, а "дырки" продолжительные и частые, то "исправление геометрии" вполне может испортить исходный слой если попытаться объединять такие сегменты в единую сеть путём варьирования порога склейки. То есть плагин скорее призван справляться с такими разрывами, которые появляются при неточном импорте / экспорте файлов или после применения векторных операций с различными неточностями. Но не задумывался для исправления именно неточных по своей природе слоёв, когда например кто-то просто забыл отвекторизовать канал между двумя реками.
С другой стороны, если разрывы маленькие, то выставление порога склейки вполне может справиться с такой сетью и тогда на выходе вы получите не только корректный векторный слой, но и ещё отранжированный в соответствии с описанным в посте алгоритмом.
Большое спасибо за комментарий и за такую оценку!
По поводу предобработки перед началом процесса идентефикации пайплайна - действительно, предварительную "грубую" вычистку данных следует производить перед началом процесса оптимизации (поиска структуры пайплайна). Во первых, это довольно затратный процесс - проводить его перед началом обучения каждого пайплайна расточительно. Во вторых, такая вычистка не отличается вариативностью и её оптимизировать довольно сложно, если вообще возможно.
Однако более тонкую предобработку, такую как энкодинг категориальных признаков и заполнение пропусков можно проводить уже разными способами. Такую предобработку можно и нужно настраивать. Рад, что про наш опыт и реализованный подход Вам было любопытно почитать :)
«Проверяли ли работу алгоритма, в случае если река уходит под поверхность земли на некоторое расстояние?» — Нет, такой ситуации мы не встречали при тестировании плагина. Но если вдруг в линейном векторном слое будет присутствовать разрыв, то алгоритм дальше этого разрыва не пойдет присваивать ранги. Так что если имеется разрыв в речной сети, и Вы точно знаете, что сегменты рядом с разрывом в действительности связаны, а не изолированы друг от друга, то можно исправить векторный слой вручную — соединить их. В таком случае алгоритм отработает как требуется.
«Не возникает ли проблема в случае больших островов или редких случаях бифуркации рек?» — Острова в линейном векторном слое — вещь довольная специфическая, они могут возникнуть, если например, мы имели не только векторный линейный слой с реками, а еще и полигональный векторный слой с водохранилищами, озерами и др. В таком случае эти площадные объекты действительно являются частью речной сети и если их не использовать, то речная сеть получится с разрывами (должно было быть водохранилище на этом месте, а его мы отбросили, и водотока в слое на этом месте тоже не оказывается). Выход довольно простой — переводим векторный полигональный слой в линейный (инструмент в QGIS Полигон в линии) и объединяем с изначальным линейным слоем с реками. Вот в таком слое могут быть ситуации, когда алгоритм считает за 2 разные реки берега одного водохранилища. Но с этим ничего поделать мы не смогли, исправлять данные вещи насильно при применении алгоритма мы не пытались, потому что вполне возможен случай, когда река просто разделяется на несколько рукавов, а потом снова сходится и никакие полигональные водные объекты тут не при чем. А вот с бифуркацией да, есть загвоздка. Так как определяющим фактором является местоположение точки впадения реки в водоём, то алгоритм считает, что именно в эту указанную пользователем точку, вся речная сеть и стекает. В таком случае алгоритм будет считать, что отошедшая ранее ветвь является притоком. Как-то отсеять это алгоритм не сможет. Тогда проще будет вручную отделить рукав от речной сети, а затем запустить алгоритм для каждой из частей речной сети отдельно — потом слои можно будет вновь соединить.
«Или в случае разбиения реки на протоки (например, в дельте)» — На рисунке 8 и в анимациях как раз приведен пример такого разбиения. Проблем возникнуть не должно, так как мы в любом случае опираемся на главную реку (назовем её опорным маршрутом в графе), и уже от неё начинаем обходить граф и присваивать ранги. Введение опорного маршрута как раз помогло нам адекватно обрабатывать подобные случаи.