Уважаемые участники конкурса «Экспедиция DS. Обнаружение»!

Завершилась онлайн-консультация №2 по Техническому регламенту конкурса. Благодарим всех, кто присоединился!

Запись консультации размещена по ссылке.

Презентация с консультации прикреплена во вложении.

О рейтингах и их влиянии на результаты конкурса

1. Публичный рейтинг команд — формируется по итогам проведения квалификационного этапа, который проходит в настоящий момент:

- учитывает скор команд только по основной метрике конкурса (см. пункт 1 в Приложении 4 к ТР)
- в квалификационном этапе метрика рассчитывается на публичной валидационной выборке
- доступен участникам в ходе проведения квалификационного этапа (ожидайте уведомления о публикации в канале)
- не учитывается при определении призёров

2. Финальный рейтинг команд — формируется по итогам проведения испытаний финального этапа, которые пройдут после 10 ноября:

- аналогично учитывает скор команд только по основной метрике конкурса
- в финальном этапе метрика рассчитывается на закрытой валидационной выборке
- закрытая выборка не пересекается с публичной и обучающей
- не доступен участникам в ходе проведения финального этапа
- каждой команде будет доступен собственный скор до официального оглашения результатов конкурса (на правах конфиденциальной информации)
- будет опубликован после экспертизы исходного кода претендентов на премию и заседания жюри
- нахождение команды на 1 месте в финальном рейтинге не гарантирует автоматической победы (необходимо пройти экспертизу кода в соответствии с п. 8.5.2 ТР)
- скор команд по основной метрике на закрытой выборке определяет финальный рейтинг, только он имеет ненулевой вес в оценке

3. Пользовательский интерфейс в соответствии с п.3.12 ТР необходимо предоставить только командам, занявшим 1 и 2 место, после завершения финального этапа конкурса (Приложение 6 к ТР будет скорректировано в ближайшее время).

Итого:
- публичный рейтинг команд откроется всем участникам со следующей недели, но он имеет только демонстрационный характер
- финальный рейтинг команд будет опубликован после завершения конкурса и утверждения его результатов
- интерфейс предоставляют только команды, занявшие 1 и 2 места

По результатам дополнительных проверок разметки обучающей выборки были внесены следующие корректировки:
- исправлена разметка полигонов, имеющих самопересечения.
- удалены полигоны с пустыми координатами.
- проверена система координат в разметке (EPSG:3857 — WGS 84 Pseudo-Mercator) для корректного отображения полигонов.

Настоятельно рекомендуем заново скачать всю разметку и провести синхронизацию данных.

Обращаем внимание, что файлы изображений не изменялись, но были замечены ошибки в работе Яндекс Диска, в настоящий момент полностью перепроверена целостность файлов через контрольные суммы. Также обновлён скрипт для загрузки датасета с S3-хранилища.

Для скачивания датасета рекомендуется использовать файловые клиенты с контролем загрузки (rclone, cyberduck и другие).

Уважаемые участники конкурса «Экспедиция DS. Обнаружение»!

Записана видеоинструкция по работе с QGIS, для ознакомления перейдите по ссылке.

Уважаемые участники конкурса «Экспедиция DS. Обнаружение»!

Мы начинаем сессию вопросов и ответов с археологами, подключайтесь по ссылке: https://expds.ktalk.ru/sx722ntymxgs

Обновление требований к интерфейсу для работы с исходным кодом

Уважаемые участники, публикуем проект обновлённого Приложения 6 к Техническому регламенту. Данный проект будет утверждён на ближайшем заседании Оргкомитета конкурса, просим внимательно ознакомиться с документом и задать ваши вопросы, если они у вас возникнут.

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

Напоминаем, что в соответствии с пунктом 3.12 Технического регламента интерфейс для работы с алгоритмом обнаружения предоставляют команды, которые уже заняли 1 или 2 место в финальном рейтинге команд и претендуют на получение премии по итогам конкурса.

Уважаемые участники, по итогам проведения сессии вопросов и ответов хотим обратить ваше внимание:

1. Рекомендуем провести синхронизацию обучающей выборки:

- в названиях файлов лидарных изображений исключены кириллические символы при указании типа хилшейда;

- в папке 006_МАКЕЕВО_FINAL исключены противоречия UTM-зон, корректная UTM-зона — 36N;

- в описание задачи на платформе добавлена инструкция по синхронизации датасета.

2. Как учет разных типов разметки (markup_type) влияет на расчёт метрики:

Все полигоны из разных типов разметки (LiDAR, аэрофотосъемка, спутниковая съемка) объединяются в рамках одной географической области и класса объектов, после чего расчет метрики ведется по объединенному набору. Тип разметки (markup_type) математически не влияет на итоговую метрику, так как IoU, precision, recall и взвешивание остаются неизменными независимо от дополнительной группировки.

3. Что будет с метрикой, если полигоны дублируются с небольшим смещением:

Когда несколько полигонов пересекаются с одним объектом из ground truth, только один становится True Positive, остальные - False Positive. Это снижает Precision и итоговый F2-score пропорционально количеству дублей. Каждый дополнительный дубль увеличивает FP и ухудшает метрику.

Участники могут использовать собственный алгоритм объединения пересекающихся полигонов с некоторым порогом IoU, либо применять алгоритм Non-Maximum Suppression (NMS) с учётом confidence scores.

Крайне важно учитывать различные источники данных для улучшения качества сегментации модели. Разные источники данных (LiDAR, аэрофото, параметр markup_type) в метрике не учитываются, все объекты региона и подрегиона обрабатываются вместе. Группировка идет по ключам "region_name", "sub_region_name" и "class_name".

Обязательно объединяйте полигоны из разных источников на вашей стороне перед отправкой, чтобы не получать штрафы за дубликаты распознанных с различных источников данных объектов.

Уважаемые участники конкурса «Экспедиция DS. Обнаружение»

Информируем вас о следующих обновлениях материалов конкурса:

1. Опубликован обновлённый Технический регламент, изменения коснулись Приложений 4 и 6:

- Приложение 4: в рамках квалификационного этапа при расчёте метрики теперь отсутствуют штрафы за false positive по разметке классов «пашни» и «дороги».
- Приложение 6: обновлены требования к интерфейсу управления исходным кодом команд, занявших 1 или 2 место и претендующих на выплату премии (предоставляется в соответствии с п. 3.12).

2. На платформе опубликовано бейзлайн-решение, которое даёт ненулевой скор на публичной валидационной выборке, обязательно ознакомьтесь с ним.

Решение основано на ultralitycs yolo-segmentation и обучалось на датасете, конвертированном из обучающей выборки «как есть», без дополнительной разметки и фильтрации, с аугментациями по умолчанию в течении 50 эпох на Nvidia GeForce 3060 12Gb.

Оно призвано показать участникам минимальный базовый подход для работы с реальными геопривязанными данными на примере набора хилшейдов. Показаны основные типовые шаги решения задачи: дайнскейлинг и выравнивание изображений, менеджмент CRS и UTM зон, нарезка на тайлы с перекрытием, пересчет контуров растровых масок в векторные полигоны, дедупликация и объединение полигонов, обратная конвертация в географические координаты, формирование итогового файла, который корректно считается метрикой.

Обращаем внимание, что у выбранного подхода множество недостатков, и нет обязательства его использовать.

3. Обновление датасета: в папке обучающей выборки 038_ЕЛИЗАВЕТИНСКОЕ_FINAL заменён tif-файл современного ортофотоплана на оригинал без разметки в высоком разрешении.

Уважаемые участники, обращаем ваше внимание:

1. Для корректной работы алгоритма расчёта метрики в рамках одного markup_type (например, 3 объекта немецкой аэрофотосьемки) нужно объединять полигоны в точках пересечения между разными снимками, то есть вы должны получить маску объектов, которая лежит на всех трёх изображениях.

Для разных markup_type полигоны объединять НЕ нужно, даже если эти полигоны где-то пересекаются, их объединение приведет к ошибкам в расчёте метрики.

2. Некоторые участники сталкиваются с ошибкой, по которой файл объединенной разметки .geojson обрывается посередине Feature из‑за принудительной остановки контейнера при использовании в скрипте solution.py json.dump() с инкрементальной записью. При прерывании контейнера файл result.geojson остаётся незакрытым и сохраняется, но является невалидным.

Мы рекомендуем в таком случае использовать подход атомарной записи, предварительно сформировав result.geojson в памяти целиком, а затем сохранив его за один раз через with open(...): f.write(). И напоминаем, что для сохранения любых файлов, в том числе и файлов логов, необходимо использовать специально отведенную для этого папку tmp.

На платформе опубликован модуль для безопасного сохранения GeoJSON файлов save_geojson.py, который реализует корректную функцию атомарного сохранения файла, его можно использовать в решении.