ratty_sib писал(а):я - редактор GPS карт и мне нужны самые свежие и актуальные снимки для редактирования карт.
В целом, концептуально поддержу, но тут требуется понимание, что именно необходимо, по шагам, чтобы было понятнее.
Так как GPSMapEdit большей частью снимки может загружать только в виде привязанного растра, необходимо изначально уметь находить границы обновлений, после чего уметь выкачивать по сохраненным границам, и в конце концов уметь собирать всё в рамках границ в jpg. Поэтому основной сложностью в реализации представляется именно автоматизированное нахождение границ обновлений (всё остальное вроде бы есть, кроме склейки jpg по сохраненной сессии, но это сущая ерунда). Непосредственно метод заливки от некоторой точки будет не совсем удобным, так как придется в конце заливки сохранять область выделения для склейки в jpg.
Представляется принципиально возможным придумать алгоритм нахождения обновлений, который бы работал с разными сервисами, так как основным отличием будет только функция определения наличия более детальных снимков по конкретной координате. Для одних сервисов это просто отсутствие файла на сервере, для других - какое-то другое сообщение об ошибке, для третьих - еще что-то (например, отсутствие новой информации при увеличении уровня зума, визуально леко проверяется, пока это не обсуждаем). Это отдельная функция, которая вполне может быть модифицирована при появлении новых сервисов, изменении их протокола и т.п. Даже если покрыть только 1-й тип (ошибка 404), уже хорошо будет.
Кроме данной функции, проверяющей (условно для Google SAT) наличие тайлов 18-го уровня под конкретным тайлом 14-го уровня, необходимо еще уметь реализовывать алгоритм расстановки реперных точек в заданной области. Например, грубо оценим достаточное расстояние между такими точками в 10 км (чтобы не проморгать небольшие по площади обновления, а по идее, это может быть и некоторая доля от размеров области, и настраиваемый параметр, как угодно). После расстановки точек в выделенной области в виде сетки проверяем для этих точек, есть ли под ними 18-й зум. Если между соседними точками в сетке есть разница в плане наличия или отсутствия 18-го зума, делим отрезок между ними пополам, добавляя в сетку еще одну точку (не во всей сетке шаг уменьшается, а только в этом месте добавляется точка). Здесь можно под соседними точками понимать только соседние по вертикали и горизонтали, а можно еще и по диагонали брать, так будет быстрее на границе. И так далее, уточняя сетку, приходим к нахождению границ. Отрезок в 10 км методом половинного деления за 4 шага уже делится настолько, что граница локализуется на километровом отрезке, что для практических применений (в смысле нахождения грубой границы для понимания необходимости заливки, пусть даже и с последующими ошибками 404 в небольшом количестве) более чем достаточно. Также понятно, что можно игнорировать небольшие дырки в областях высокого разрешения, просто несколько раз получим потом ошибку 404, и всё. То есть, это уже не критичные вещи. Здесь необходимо отметить, что от реперных точек можно было бы запустить закачку тайлов методом заливки от точки (как тут называют, метод "короеда", или модификация FloodFill), и это даже решит вопрос именно выкачивания, но не решит вопрос определения границ (см. выше).
Можно было бы грузить (опять же цифры для Google SAT) только 15-й зум, потом анализировать каким-то хитрым способом изображение, находить его границу, и т.п., то есть, делать так, как делается визуально, но это куда более сложный и потенциально опасный способ. Хотя и он не лишен смысла, например, при изменении уже существующих снимков для разных времен года.
Безусловно, будут сложности и тонкости, например, необходимость перекачивания граничных тайлов для того же гугла, так как на 18-м зуме на граничных тайлах в старой версии часть тайла закрывает сильно размытое изображение 14-го зума. Но технически это всё вполне реализуемо. В частности, закачка тайлов по некоторому маршруту здесь замечательно сработает, если её запустить с принудительным обновлением вдоль собственно границы.
Как-то примерно так.
По идее, различных методов выкачивания высоких разрешений может быть много. Например, можно вручную для выбранного тайла на 12-м зуме пытаться грузить все 15-е под ним (опять же для Google SAT) в некотором порядке (например, грузим в шахматном порядке через N тайлов, где N в данном случае равно 2 ^ (15-12-1) = 4, или грузим диагонали, потом делим их пополам, из этих точек опять по диагонали, и т.п., или еще какой-нибудь быстрый метод идентфикации наличия хотя бы одного тайла 15-го зума). Важно только понимать, с какого уровня для конкретного сервиса начинается существование снимка высого разрешения.
Bigbambr » 08 фев 2010, 20:38 Хотелось бы наоборот!
Извините, но для реальной работы всё это не нужно. Найти границы снимка и скачать его занятие получаса (нескольких часов для DG) =)
