Вопросы отраслевому партнёру («Геоскан»)¶

Список для Q&A-сессии, консультации или письма организаторам. Принцип отбора: не спрашиваем то, что уже есть в буклетах и в нашей базе знаний — это тратит время эксперта и выглядит как неподготовленность. Спрашиваем то, чего в документах нет в принципе: эксплуатационную практику, онлайн-контур, безопасность полётов и то, что сам заказчик считает «хорошим планом».

Формат каждого пункта: вопрос → что меняется у нас в продукте от ответа. Если ответ ничего не меняет, вопрос из списка выкидывается.

Если времени мало — семь вопросов¶

Ровно эти дают максимум изменений в коде и в презентации:

#	Вопрос	Что решает
Q-24	Как сегодня выглядит планирование работ на парк и что больнее всего автоматизировать	Формулировка ценности на питче — из уст заказчика
Q-15	Можно ли делить один полигон между разнотипными бортами, или материалы должны быть однородны	Либо VRP по галсам, либо VRP по участкам — разная постановка
Q-10	Нужна ли деконфликтация бортов между собой (эшелоны, интервалы)	Новое ограничение решателя, которого нет в ТЗ
Q-06	Какой KML корректно импортирует Geoscan Planner, есть ли пример файла	Наш главный выход перестаёт быть «файлом для карты»
Q-31	Есть ли эталонный пример «вход → хороший план»	Прямая сверка валидатора с реальностью
Q-25	Типичный и максимальный масштаб работ (км², борта, площадки, дни)	Цифры для графика масштабируемости
Q-02	Жёсткое ли ограничение «борт в зоне радиосвязи»	Либо появляется ограничение по удалению от НСУ, либо нет

A. Связь, онлайн-контур, взаимодействие «борт ↔ сервер»¶

Из буклетов известно: у 201 радиомодем на 40 км при маршруте 210 км, у Gemini — 5 км, у 801 — свой канал. То есть борт штатно уходит за пределы связи. Что из этого следует для планирования — неизвестно.

Q-01. Планирование у вас офлайновое (файл → Planner → борт) или есть живой контур «сервер ↔ НСУ ↔ борт»? Имеет ли смысл нам предусматривать API выдачи и обновления задания в полёте? → Определяет, нужен ли нам вообще слой «исполнение» рядом со слоем «планирование», и что показывать в демо.

Q-02. Уход борта за пределы радиосвязи — норма или ограничение? Должен ли план гарантировать нахождение борта в зоне связи с НСУ (и если да — какой радиус закладывать, есть ли ретрансляторы)? → Если жёстко — в решатель добавляется ограничение «все точки маршрута в круге R вокруг НСУ», и задача заметно меняется: далёкие участки требуют переезда НСУ, а не просто дальнего борта.

Q-03. Какие данные приходят с борта в реальном времени (позиция, остаток заряда, измеренный ветер, статус фотоаппарата, отработанные галсы)? Есть ли документированный протокол или SDK, куда можно отдавать задание напрямую, помимо файла? → Даёт возможность делать перепланирование по факту, а не по модели; и это самый сильный сценарий демо.

Q-04. Что борт делает при потере связи — продолжает задание автономно, идёт в точку ожидания, возвращается? Через какое время? → Влияет на то, сколько энергии план обязан резервировать на возврат, и на цену «дальних» галсов.

Q-05. Сколько бортов реально ведёт одновременно один расчёт/оператор и одна НСУ? Есть ли ограничение «с одной площадки одновременно в воздухе не более N бортов»? → Ресурсное ограничение, которого нет в ТЗ: оно напрямую режет makespan и легко ломает красивый план «все три борта стартуют в 9:00».

Q-06. Какую структуру KML корректно импортирует Geoscan Planner как полётное задание — что именно он читает (только контур области? маршрут с высотами? скорости?) и можно ли получить пример файла? → Мы позиционируемся как надстройка над Planner. Без этого ответа наш KML — «формат для карты», с ним — рабочая интеграция и самое убедительное, что можно показать эксперту.

B. Препятствия, птицы, безопасность полёта¶

Q-07. Есть ли на бортах средства обнаружения и уклонения в полёте (оптика, радар, ADS-B/FLARM), или всё уклонение — это исключительно планирование до вылета? → Если ничего нет, то вся ответственность на плане, и наши геозоны и запасы по высоте — не перестраховка, а единственный механизм безопасности. Это надо проговорить на защите.

Q-08. Птицы — практическая проблема или теоретическая? Есть ли рабочие правила: высоты, время суток, сезоны, районы (гнездовья, свалки, водоёмы)? Были ли столкновения? → Если правила есть, они ложатся в модель как зоны риска с временны́ми окнами — ровно тот же механизм, что бесполётные зоны, но с расписанием. Дёшево реализовать и никто из команд этого не сделает.

Q-09. Как учитываются высотные препятствия — ЛЭП, вышки, трубы, тросы канатных дорог? Откуда берутся данные (рельеф + каталог объектов, съёмка на месте, местные жители)? Есть ли формат, который нам стоит поддержать на входе? → Определяет, нужен ли третий тип входных ограничений («точечные/линейные препятствия с высотой») помимо inclusion/exclusion-геозон.

Q-10. Нужна ли деконфликтация бортов между собой, если три борта работают в одной области с разных площадок? Какие минимальные интервалы считаются безопасными — по горизонтали, по высоте, по времени? Практикуете ли разведение по эшелонам? → Это ограничение из мира групповых работ, которого в ТЗ нет вообще. Реализуемо как разные высоты галсов на пересекающихся участках или временны́е окна. Один из сильнейших вопросов эксперту: он показывает, что мы думаем про группу, а не про три независимых борта.

Q-11. Как на практике выбирается резервная площадка посадки — по удалению, по подстилающей поверхности, по подъезду? Должен ли план гарантировать, что из любой точки маршрута борт дотянет до ближайшей площадки на остатке заряда? → Второе — это ограничение «достижимость альтернативы в каждой точке», заметно более строгое, чем «дотянуть до финиша». Хотим знать, требуется ли оно на самом деле.

Q-12. Снос при парашютировании у 201 — есть ли эмпирика (сколько метров сноса на метр высоты при каком ветре)? Проверяете ли вы, что эллипс приземления не накрывает дорогу, воду, застройку? → Мы хотим рисовать эллипс сноса и проверять его на пересечение с бесполётными зонами. Нужен коэффициент.

Q-13. Какие ещё метеофакторы отсекают вылет так же жёстко, как ветер (осадки, температура, видимость, обледенение, порывы)? Какие пороги? → Сейчас у нас единственный жёсткий отсекатель — wind_max. Если порогов больше, это строка в UI «доступно N бортов из M» и честный список ограничений.

C. Что заказчик считает хорошим планом¶

Q-14. Что на практике означает «оптимально» — время работ, суммарный налёт, деньги, износ ресурса, число вылетов, число задействованных бригад? Есть ли внутренняя стоимость лётного часа по типам бортов? → ТЗ требует два критерия. Если реальный критерий — деньги, третьим критерием делаем стоимость, и это попадание в заказчика, а не в букву ТЗ.

Q-15. Допустимо ли делить один полигон между разнотипными бортами — часть снимает самолёт, часть мультиротор? Или заказчик требует однородности материалов по всей области (единый GSD, одна камера)? → Ключевая развилка постановки. Если однородность обязательна, «клиент» в VRP — не галс, а участок с привязкой к классу борта, и вся математика другая.

Q-16. Есть ли требование снять всю область в одном временно́м окне (освещение, тени, один день)? Насколько допустим разрыв в часах и днях между соседними участками? → Превращается в ограничение на разброс времени выполнения соседних галсов — фактически ещё одна целевая функция, конкурирующая с makespan.

Q-17. На сколько «плывёт» реальное время работ относительно плана? Есть ли коэффициент, который вы закладываете (10 %, 30 %)? → Наша модель времени намеренно пессимистична. Хотим сверить её с практикой и показать на защите «наша оценка отличается от факта на X %», а не «мы посчитали».

Q-18. Сколько времени и чьего труда занимает планирование сегодня на типовой заказ? Что в этом процессе самое раздражающее? → Прямая цифра для слайда «было / стало». Такие цифры на питче работают лучше процентов оптимальности.

D. Матчасть: подтвердить наши допущения¶

Все пункты ниже — это места, где мы уже посчитали, но опирались на допущение. В fleet.yaml и payloads.yaml они помечены source: assumed. Вопрос формулируем как «подтвердите или поправьте», показывая своё число — так эксперт видит, что мы читали первоисточник.

Q-19. Геоскан 801: энергоёмкость АКБ в буклете не указана. Мы считаем ресурс по времени (40 мин). Есть ли паспортные Вт·ч и средняя потребляемая мощность?

Q-20. Sony RX1R M2 на 201: фокусное в РЭ не указано, мы взяли 35 мм по несъёмному объективу. Верно? И шаг пикселя тепловизора на 801 — мы приняли 12 мкм. → Обе величины входят в расчёт высоты прямо пропорционально: ошибка в фокусном = ошибка в высоте.

Q-21. Реальные крейсерская и съёмочная скорости, а не максимальные из буклета. Радиус разворота 201 на съёмочной скорости (у нас в модели ~137 м) и тип разворота по умолчанию — «с выходом на ЛЗП» или обычный? → При шаге галсов 70–120 м разворот с петлёй съедает заметную долю времени; хотим считать её правильно.

Q-22. Оборот на площадке: сколько реально занимает замена АКБ и предстартовая подготовка, сколько запасных АКБ берут в поле, сколько времени на перезарядку катапульты 201? → Из спецификации Gemini: полёт 40 мин, заряд 105 мин. Если запасных АКБ нет, makespan на длинных сценариях меняется в разы. Хотим реальные числа, а не соотношение из буклета.

Q-23. Ветер: берёте прогноз (какой источник?) или меряете на месте? Учитываете ли профиль ветра по высоте и порывы? → У нас пока однородный ветер на всю область. Если на практике важен профиль по высоте — это дешёвое расширение с заметным эффектом на выбор высоты.

E. Процесс и эксплуатация¶

Q-24. Как выглядит полный цикл работ: заявка → планирование → выезд → съёмка → обработка? Где в этой цепочке место нашего сервиса и с чем он должен стыковаться на входе и на выходе? → Главный вопрос списка. Ответ даёт и формулировку ценности, и границы продукта.

Q-25. Типичный и максимальный масштаб: сколько км² за смену, сколько бортов, сколько площадок, сколько дней? Какой самый крупный реальный заказ был? → Критерий оценки прямо называет масштабируемость. Нужен график «время расчёта от числа галсов» с реальным диапазоном на оси X, а не с выдуманным.

Q-26. Многодневные работы: планируете ли на несколько смен с учётом светового дня, переездов между площадками, ночёвок? Нужно ли это в сервисе? → Либо горизонт планирования — одна смена, либо появляется календарь. Разница в объёме большая, хотим знать до того, как начнём.

Q-27. Кто пользователь сервиса — оператор в поле, диспетчер в офисе, менеджер со сметой? На чём работает: ноутбук в поле без интернета или рабочее место? → Прямо влияет на интерфейс и на вопрос офлайн-режима (Planner, например, кеширует подложку заранее именно потому, что в поле связи нет).

Q-28. Подача плана полёта и разрешения на ИВП — отдельный процесс или его стоит учитывать в сервисе? Нужны ли нам данные для заявки на выходе? → Если нужно, это дешёвая и очень заметная фича: сервис уже знает границы, высоты и время работ.

Q-29. Что делаете сегодня, если борт выпал посреди работ (отказ, погода, разряд)? Перепланируете вручную? Как часто это случается? → У нас в бэклоге есть пересчёт плана на остатке невыполненных галсов. Хотим понять, это эффектная демка или реально востребованная функция.

Q-30. Сколько человек в наземном расчёте и может ли одна бригада обслуживать несколько бортов и несколько площадок? → Ещё одно ресурсное ограничение помимо самих бортов. Если бригада одна, план «три площадки одновременно» нереализуем.

F. Данные и форматы¶

Q-31. Есть ли обезличенный эталонный пример «вход → план, который вы считаете хорошим»? Даже один. → Самое ценное, что можно получить. Наш метод построен на валидаторе метрик; реальный эталон превращает его из самопроверки в сверку с реальностью.

Q-32. В каком виде реально приходят область съёмки и бесполётные зоны от заказчиков: SHP, KML, GeoJSON, MIF/MID, таблица координат? В какой системе координат — WGS-84, СК-42, местные МСК? → Если МСК и СК-42 встречаются регулярно, поддержка пересчёта становится обязательной, а не опцией: тихая ошибка проекции — самый вероятный способ выдать правдоподобный неверный план.

Q-33. Высоты в задании — относительно точки старта, эллипсоида или геоида? Какой моделью рельефа пользуетесь (SRTM, своя съёмка, открытые данные)? → Влияет на altitudeMode в KML и на корректность «превышения». Тихая ошибка того же класса, что и с проекциями.

Q-34. Как на практике решается конфликт «порог 150 м из ФП-138 против требуемого GSD»? Например, GSD 3 см камерой PF1B требует 153 м. Снижаете требования к GSD, берёте разрешение, летите выше? → Сейчас мы планируем просто предупреждать. Если у отрасли есть штатное решение, реализуем его.

G. Про оценку решений¶

Q-35. По каким числам вы будете сравнивать решения команд? Есть ли у вас эталонный сценарий или бейзлайн, с которым сравниваете? → Если сценарий можно получить заранее — он становится сценарием s11 в нашем наборе тестов.

Q-36. Что для вас признак, что решение применимо в работе, а не демонстрация? Чего обычно не хватает студенческим решениям этой задачи? → Ответ на этот вопрос — это, по сути, чеклист приёмки, продиктованный самим заказчиком.

Что мы НЕ спрашиваем и почему¶

Чтобы не тратить время эксперта и не выглядеть непрочитавшими первоисточник:

Не спрашиваем	Потому что уже знаем	Где у нас
ТТХ бортов: запас хода, скорость, ветер, потолки	Есть в PDF по ссылкам из ТЗ	10-hardware/ (`../10-hardware/`)
Какие камеры на каком борту	Матрица совместимости собрана	10-hardware/05 (`../10-hardware/05-payloads.md`)
Что такое ПАФС/ЛАФС, галс, ЛЗП, превышение	Разобрано по руководству Planner	00-brief/03
Как считается высота из GSD и шаг галсов	Формулы выведены, есть контрольные числа	30-domain/01
Что умеют Planner / Mission Planner / QGC	Gap-анализ построен	20-analogs/04 (`../20-analogs/04-gap-analysis.md`)
Классы воздушного пространства и порог 150 м	Разобрано по ФП-138	30-domain/06 (`../30-domain/06-airspace-ru.md`)
Какие форматы выгрузки нужны	Прямо названы в ТЗ: KML и GeoJSON	40-formats/

Исключение — блок D: там мы спрашиваем подтверждение своих чисел, а не сами числа. Это принципиально другой разговор: мы показываем расчёт и просим поправить, если ошиблись.

Как задавать¶

Сначала Q-24 и Q-25 — они открытые, эксперт говорит сам, и из ответа обычно выпадает половина остальных ответов бесплатно.
Вопросы блока D формулировать с числом: «мы приняли фокусное 35 мм, потому что у RX1R несъёмный Sonnar — верно?». Так проверяется допущение и одновременно показывается глубина проработки.
Q-10 и Q-15 приберечь на Q&A после питча — они демонстрируют, что мы думаем про групповые работы и про фотограмметрическую однородность, а не только про математику маршрутов.
Всё, что осталось без ответа, идёт в «перечень известных ограничений» (R-DOC-6) с формулировкой «принято допущение X, требует подтверждения заказчиком» — это не слабость, это зрелость.