Автоматизированное определение зон покрытий

[gisof]

Предлагаю ввести в САС следущий функционал:

1 Функция "Проход" - определение зоны покрытия высокодетальными снимками

Описание: Переходим на меньший уровень масштаба, на котором присутствуют высокодетальные снимки и нет базового слоя (обычно Landsat),
т.е. тот слой на котором сервак посылает ответ "нет снимка" либо отдаёт соответствующую картинку (для яху и мелкософта 15 уровень)

Исходные данные: указываем тайл или точку близкую к восточной границе снимка

Алгоритм: Начинаем закачку тайлов пока не упрёмся в "нет снимка"
когда получаем такой ответ сворачиваем в направлении юга (глобальное напрвление обхода - по часовой стрелке)
идём далее, прокачивая тайлы и проверяя отсутствие соседнего тайла
если соседний тайл появляется или упираемся в "нет снимка", то меняем направление прохода
таким образом идём "по границе" и проходим всю локализированную зону покрытия
все точки поворотов фиксируем и строим по ним область выделения

Результат : загруженные пограничные тайлы и построенная зона выделения, аналогичная тем, что можно построить вручную,
т.е. над ней можно проводить различные операции.

2 База данных о зонах покрытия

Все области выделения храним в базе MySQL, в которой также храним информацию о скаченных тайлах
(предложенная rokki тема MySQL viewtopic.php?f=2&t=110&st=0&sk=t&sd=a)
К каждой зоне добавляем описание (Пр.; даты снимков, разрешение, спутник и д.р.).

3 Сбор и обмен данными

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

4 Добавляем в САС функции:

- Показать зоны покрытия текущего источника
- Показать покрытия всех источников

[vdemidov]

Заманчиво конечно, но как представлю сколько мороки и проблем в реализации может быть становится страшно

[gisof]

Заманчиво конечно, но как представлю сколько мороки и проблем в реализации может быть становится страшно

ввести сразу весь функционал конечно сложно
поэтому всё разбито по шагам

первый и очень важный шаг - "Проход" можно сделать уже сейчас

[svp]

Да ничего страшного здесь нет, действительно.

1 Функция "Проход" - определение зоны покрытия высокодетальными снимками

Метод левой (или правой) руки. Только можно сделать его чуть более универсальным.
Например, на входе алгоритму давать любую координату внутри детальной области.
Алгоритм идёт в любую сторону пока не упрётся в отсутствие тайла, затем двигается методом левой (или правой, не важно) руки вдоль границы. Цепочку граничных точек (Xi,Yi) и следует сохранять.
Ещё можно оптимизировать кол-во данных для хранения этой граничной цепочки. Прямые участки цепи имеет смысл задавать двумя точками начала и конца. Таким образом мы получим полигон. Это полигон можно показывать прямо в KML с надписями, пометками и ссылками на дополнительную информацию. XML-можно хранить в базе и на веб-сервисе.
Всё сразу, конечно, реализовывать смысла нет. Как справедливо было замечено, надо двигаться по шагам, разбив задачу на тривиальные подзадачи.

Кстати, для быстрой отрисовки в KML можно сохранять ещё более упрощённые (уже с незначительной потерей данных) полигоны. Для этого обходим все тройки соседних точек в цепи полигона и считаем площади образуемых ими треугольников. Если площадь меньше некоторой пороговой, то среднюю точку из этих трёх удаляем из полигона. Последний при этом будет выглядеть чуть грубее, но глазом это будет мало заметно.

2 База данных о зонах покрытия

Полностью автоматизировать сборку информации для этой БД так просто не удастся.
Дело в том, что сплошная детальная область может состоять из мозаики нескольких снимков, сделанных в разное время и с разной цветокоррекцией. Ничего с этим "зоопарком"(с) мы, конечно, не поделаем, но иметь в базе информацию о датах съёмки этих лоскутков и очертания оных по отдельности хотелось бы.
Ещё одна проблема: из-за нагромождения мозаики из разных снимков в некоторых местах сплошной детальной области могут образовываться дыры низкой детализации. Их нужно искать либо вручную, либо с помощью прокачки территории с некоторым достаточно большим шагом.
Гле-тона форуме шла речь о сервисах, предоставляющих несколько вариантов снимков одной и той же местности. В свете всего этого, ИМХО, стоит подумать на перспективу о создании единой базы кеширования спутниковых снимков из разных источников. собирая и выделяя лоскутки мозаики по времени съёмки.
Например, снимки DG и гугла часто практически не различаются, а местами могут дополнять друг друга.

[gisof]

Гле-тона форуме шла речь о сервисах, предоставляющих несколько вариантов снимков одной и той же местности. В свете всего этого, ИМХО, стоит подумать на перспективу о создании единой базы кеширования спутниковых снимков из разных источников. собирая и выделяя лоскутки мозаики по времени съёмки.

DG обсуждается - viewtopic.php?f=2&t=102
Вспомнил, что в google earth есть векторный слой Digital Globe (там инфа об архивных снимках, снятых Quick Bird), также у компании Digital Globe есть свой геосервис с подбором снимков. Эту инфу можно будет тоже задействовать.

[svp]

Всю задачу надо разбивать на куски и делать по отдельности.
К примеру, обход детальных областей -- это совершенно отдельная задача. На входе тайловый кеш и координаты стартового файла (zxy). На выходе полигон из точек.
Оптимизатор этого полигона -- тоже отдельная задача. Конвертер полигона в kml -- ещё одна отдельная задача. Интерфейс отправки/получения в базу/из базы набора полигонов, попадающих в указанный (видимый) ректангл для данного масштаба -- отдельная и тоже несложная задача.

Я сейчас делаю закачку обходом. Как побочный эффект будет обходить ещё и контур по левой/правой руке.

[gisof]

Жаль, что тема затухла..

[workdao]

ну ... не факт, что это настолько жизненоважно