Уважаемые участники конкурса «Экспедиция 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, который реализует корректную функцию атомарного сохранения файла, его можно использовать в решении.

Уважаемые участники!

1. Открыта возможность загрузки решений в рамках испытаний финального этапа. Дедлайн — 13 ноября 23:59 МСК. В ходе испытаний можно получить до 2 значений метрики на закрытой валидационной выборке для учёта в финальном рейтинге команд.

2. Просим обратить особое внимание на следующие аспекты при формировании файла result.geojson для корректного расчёта метрики:
- Файл result.geojson содержит корректные имена регионов (region_name) в формате region_XXXX
- В файле result.geojson вы указываете подрегионы (sub_region_name) там, где они присутствуют в датасете
- Используете систему координат EPSG:3857 для всех полигонов
- Координаты в result.geojson находятся в ожидаемом диапазоне согласно UTM.json

Даже если модель предсказывает небольшое количество объектов, корректность метаданных (имена регионов, подрегионы) критична для правильного расчёта метрики.

3. В финальной выборке представлены египетские караванные пути, которые могут быть размечены участниками как «dorogi» и «karavannye_puti» — оба варианта будут считаться корректными в рамках текущего соревнования и рассчитываться с весом 3.0 класса «караванные пути» согласно приложению 4 ТР.

Желаем всем удачи в финальных испытаниях!

Уважаемые участники!

Экспертной группой конкурса с учётом мониторинга текущей нагрузки на инфраструктуру платформы принято решение увеличить общий лимит любых попыток в рамках испытаний финального этапа до 20. Количество успешных попыток (запуска финальной версии исходного кода) остаётся без изменений и ограничено 2 (двумя) попытками на этап согласно пункту 7.11 Технического регламента.

Если вы ещё не использовали ни одной успешной попытки, рекомендуем осуществить загрузку решения в разделе «Data Science» в ближайшее время, так как ближе к дедлайну может возникнуть очередь.