Гибрид наличия покрытия virtualearth

[vasketsov]

Сразу же в начале поста предупреждение большими синими буквами:
ВЫ ДОЛЖНЫ ЧЁТКО ПОНИМАТЬ, ГДЕ ИМЕННО, ЗАЧЕМ И КАК ИСПОЛЬЗУЕТЕ ДАННЫЙ СЛОЙ, ИНАЧЕ ОТ ЭТОГО НЕ БУДЕТ НИКАКОЙ ПОЛЬЗЫ!
ЕСЛИ ВООБЩЕ ЧТО-НИБУДЬ ПОЛУЧИТСЯ!
ЕСЛИ ВАМ ХОТЬ ЧТО-НИБУДЬ НЕ ПОНЯТНО - НЕ ИСПОЛЬЗУЙТЕ ДАННЫЙ СЛОЙ!
МНОГАБУКАФ ЧИТАТЬ ПОЛНОСТЬЮ!

Итак, сие творение по сути является гибридным слоем над данными с сервиса virtualearth.net (данный пример построен над данными Aerial, для Birdseye будет похоже, но необходимы изменения, просто если заменить сервис в скрипте, работать не будет). Ничего недокументированного не используется, только официальные интерфейсы от Microsoft.

Цель создания данного гибрида - относительно информативно и относительно быстро иметь возможность понять, есть ли под данным тайлом подробное покрытие (далее - просто покрытие, но имеется в виду 15-й зум).
Понятно, что выделенное - взаимоисключающие вещи. Для точного определения границы покрытия необходимо фактически пройтись по 15-му зуму, чего очень не хотелось бы по причине затрат ресурсов (от чего собственно и хотелось уйти, грузить всю Россию на 15-м зуме - не самое быстрое решение). Для быстрого построения гибрида на более низких зумах (скажем, на 10-м зуме; тут речь не идёт о генерации гибрида из более высокого зума) неизбежно придётся пожертвовать точностью определения границ покрытия. Ну и очевидно, что если строить гибрид скажем так зума для 8-го, то практически везде будет информация, что под тайлом есть хотя бы один подробный тайл на 15-м зуме. То есть весь цимус как раз лежит между 8 и 15 зумами. В реальности, погоняв по европейской части России свой скрипт, я пришёл к выводу, что начинать имеет смысл строить гибрид с 10 зума, потом сгенерить слои вверх, а потом уже визуально смотреть и ручками выделять и уточнять по отдельным участкам для 12 зума. Если же начинать осваивать незагруженную область, в которой предположительно снимки расположены менее плотно, можно начинать и с 9 зума. На зумах меньших 9 скрипт фактически не работает ввиду бессмысленности такой работы: долго и наверняка хоть один тайл покрытия найдётся. Чтобы было понятнее и для предотвращения вопросов - скрипт не строит точную границу покрытия (если покрытие как-то хитро или очень мало попало под тайл - тайл может быть определён как тайл без покрытия), задача - не пропустить наличие покрытия вообще, то есть, на протяжении нескольких соседних тайлов (только при этом послаблении возможен выигрыш в скорости).

Для запуска скрипта нужен установленный интерпретатор Perl. Для Windows лучше всего взять ActiveState ActivePerl последней версии. Скрипт запускается из командрой строки и висит на экране в виде консоли, прикидывается веб-сервером и отдаёт (полу)прозрачные тайлы в формате png. Всё необходимое для запуска находится в архиве (исключая сам Perl). После того как в sas будет подложен файлик zmp, необходимо будет поменять путь до кэша на более пристойный для Вашего случая, сие сделано специально. Также при необходимости потребуется заменить номер порта в настройках zmp и скрипте, если используемый порт 8888 окажется занят. Скрипт может вернуть 2 разных png, которые отличаются прозрачностью. Если нет покрытия - вернутся полностью прозрачный png (будет вместо tne), если есть покрытие - прозрачность будет 100 (исключая небольшую и неприятную багу в программе, под такими прозрачными тайлами будет всё видно).

Приложен пример того, как выглядит сгенерённый из более высоких зумов участок на 10-м зуме (гибрид - с 12-го, vesat - с 15-го). Легко понять, где есть ещё незагруженный (пропущенный) участок покрытия. На примере виден косяк в программе (в генерации полупрозрачных png вверх по слоям) - разрыв в надписи "Республика Башкортостан", при отключении гибрида надпись становится полноценной.

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

Название: vesat_imagery_data.rar
Размер: 5.87 кб
Доступен до: 2011-08-23 14:10:23
Ссылка для скачивания файла: http://ifolder.ru/24849967

Вопросы тут или в личку.

[vasketsov]

Сделал сохранение данных о покрытии в БД под Sybase ASE прямо из скрипта.
Сейчас можно будет при появлении обновления по-новой прогнав скрипт по области получить хранимой процой все номера тайлов изменения покрытия.
Тестировал на области, примерно соответствующей европейской части РФ, если точнее - полностью "полуподробное" покрытие яндекснимков + немного в сибирь залез.
Для vesat отрабатывает за полчаса.
Для dgsat в несколько раз дольше, но там и принцип проверки немного другой (потайлово до 14 зума - в БД попадают не только например синтетические данные 12-го зума, но и реальные данные нижележащих тайлов 14-го), более точно получается. Вроде часа 4 наверное работает, может 5, точнее не засекал. Почему-то 48-й стек ОЩУТИМО медленнее 49-го, даже там где снимков столько же.
В общем подождём реальных обновлений.

[Parasite]

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

(архив не качал, в сорц не смотрел)
Скрипт данные берет с инета, либо из уже скачанного (на диск)?
И если с инета - то нельзя ли подробнее за сам процесс (на словах)? Если просто перебором проверяет наличие тайлов на более глубоких зумах чем тот что на экране, и строит карту наличия - то это банально и неинтересно, а если что-то хитрее - то это уже стОит того чтобы заинтересоваться всем вопросом...

[vasketsov]

Скрипт данные берет с инета, либо из уже скачанного (на диск)?

Скрипт из архива не обучен лазить в БД или на диск (да и вообще я уже много чего там поправил, рабочая версия уже несколько другая).
Более новая версия ходит в инет и пишет в БД, потом из БД уже не берёт данные ввиду отсутствия необходимости этого.
Да и строго говоря сейчас же нельзя передать в zmp признак "переписывать уже существующие тайлы", а по идее было бы весьма приятно в зависимости от этого признака либо только брать инфу из БД, либо честно полностью обновлять всё.

И если с инета - то нельзя ли подробнее за сам процесс (на словах)?

Если на словах - то используется тот факт, что не бывает снимка (точнее, связного участка подробного покрытия) меньше одного тайла на 12-м зуме.
Поэтому нюхается 15-й зум не подряд, а через определённый шаг.
Например, если тайл гибрида запрашивается на 10-м зуме, то проверяем 16 точек с шагом 1/4 и смещением 1/8 - центры квадратов 12 зума под обрабатываемым 10-м. Возможная ошибка в определении границы покрытия такова, что пропустить наличие снимка нельзя, но визуально граница получается грубая.
Если тайл гибрида запрашивается на 12-м зуме, то всё же ради красоты сделал запрос разрешения по центру тайла и 4 точки по диагонали на удалении 1/8 от краев (то есть я намеренно в этом случае пошёл на увеличение точек анализа в 5 раз от достаточного, иначе слишком грубо и некрасиво получается - но это сказывается на скорости работы - впрочем всё равно быстрее чем качать тайлы).

если что-то хитрее

В принципе если есть идеи сделать ещё более хитро - велкам.
Если интересно что получается в смысле тайлов гибрида - могу по выложенной hlg прогнать формирование гибрида для vesat и выложить 10-й (и/или 12-й зум по желанию) для этой области, засеку время, выложу.
В плане данных - в БД падают значения g (версия снимков), xyz (тайловые координаты) и две даты (мин и макс).
На основе этих данных уже можно будет в будущем строить список, чего обновилось (новая версия + координаты новых тайлов), ещё б на основе этого сразу kmz как-то сгенерить.

[Parasite]

Более новая версия ходит в инет и пишет в БД, потом из БД уже не берёт данные ввиду отсутствия необходимости этого.Да и строго говоря сейчас же нельзя передать в zmp признак "переписывать уже существующие тайлы", а по идее было бы весьма приятно в зависимости от этого признака либо только брать инфу из БД, либо честно полностью обновлять всё.

А что мешает писать тайлы со скрипта в папочки кэша напрямую (помимо САСа)?
Не самый удобный вариант конечно (требуется постоянно дергать САСа на предмет рефреша) - зато работоспособный прямо на наст.момент.

если что-то хитрее

В принципе если есть идеи сделать ещё более хитро - велкам.

Так я кагбэ не предлагал - я кагбэ спрашивал.
В общем и целом, я предпочитаю не связываться с GM и прочими ему подобными - предпочитаю GE. Там наличие конкретного обновления на каком угодно зуме - вполне себе однозначное, без переборов всего и вся (по Q-дереву).
Вот тут можешь поглядеть за мою графику. Тоже скрипт+БД, обращения к диску минимальны, да и сам кэш качать не надо - нужен только индекс оного (то самое Q-дерево).

Если же когда и приспичивает прокачать именно GM\VE и иже с ними - то (мне) намного проще тупо накалякать форкованный скриптик и сесть на весь свой канал тредами так сотней\другой параллельно, чем изобретать хитрости. 15й уровень укачивается примерно за неделю - вот и вся "хитрость".

PS: но ты продолжай, да. Дело-то полезное...

[vasketsov]

А что мешает писать тайлы со скрипта в папочки кэша напрямую (помимо САСа)?

Ну например в общем случае недоступность кэша саса из скрипта.
У меня конечно всё на одном компе крутится, но не факт, что так будет всегда. Да пока что и смысла большого нет чтобы извращаться.

прокачать именно GM\VE и иже с ними

Тут как бы пока что решение только для vesat и dgsat (конкретно 48 и 49). Для gm это бесмысленно по определению ввиду наличия ge.
Да и в общем-то целесообразность моих телодвижений тоже будет непонятна до тех пор пока не постигнет нас очередное обновление.
А обновления - они разные бывают. Например, периодически vesat меняет g - но вот с осени 10-го года я обнаружил в Коми "новый" снимок, который подлез под старый. Так что не факт, что две даты (максимальная и минимальная) адекватно опишут ситуацию. А там глядишь может и до аналогичной темы доживём с картинками и обновлениями.

15й уровень укачивается примерно за неделю

Я не сомневаюсь, что реальные тайлы отлично скачаются примерно за время, большее примерно на порядок моего, если не учитывать возможный бан.
Но у меня несколько другая задача. Определить наличие обновления же можно и быстрее, не скачивая тайлы.
Кроме того в качестве бонуса получается разрешение снимка и его дата (правда для 48-го нет даты, но это уже тонкости).
И если тайлы vesat у меня отстреливаются как из пулемёта, то про dgsat этого отнюдь не скажешь, даже не тайл в секунду (безо всяких таймаутов в сасе). Между тем на 10-м зуме 49-й стек обошёлся в 1.5 часа работы, 48-й - в 2.5 часа (супротив получаса vesat для всё той же тестовой области без малого в 4 тыщи тайлов на 10-м зуме).

[Parasite]

А что мешает писать тайлы со скрипта в папочки кэша напрямую (помимо САСа)?

Ну например в общем случае недоступность кэша саса из скрипта.

Он может быть недоступен по какой причине?
1. Так сказал root (и тогда это уже не к скрипту), либо
2. Кэш внезапно стал недоступен физически (еррор железа например, или флешку выдрали) - и тогда это опять же не к скрипту.
Имхо.

Ну и опять же - лично у себя я делаю банальную проверочку на возврат из операции записи - если возврат с ошибкой (два первых варианта) - то повтор операции с промежутком N, goto "проверочка".
Там же (до кучи) проверочка записи на контент нулевой длины и на контент содержащий в себе хотя бы один тег HTML (404 например). Если что - они поднимают флаг еррора записи, и sleep+goto на второй очередной круг с выводом отладочной инфы в STDOUT.

прокачать именно GM\VE и иже с ними

Тут как бы пока что решение только для vesat и dgsat (конкретно 48 и 49). Для gm это бесмысленно по определению ввиду наличия ge.

Я выше не за конкретные отдельно взятые сервисы - а за философию их работы, что ли.
GE от GM отличаются ж не только названием - а и полностью по всем параметрам.
Имея ввиду выше "GM" - я вещал за все веб-сервисы оптом, которые юзаются в "GM-стиле" (браузер, немножко явы, дохрена графики). Сюда относятся VE, DG (web-based) итд. Как-то так.

15й уровень укачивается примерно за неделю

Я не сомневаюсь, что реальные тайлы отлично скачаются примерно за время, большее примерно на порядок моего, если не учитывать возможный бан.
Но у меня несколько другая задача. Определить наличие обновления же можно и быстрее, не скачивая тайлы.
Кроме того в качестве бонуса получается разрешение снимка и его дата (правда для 48-го нет даты, но это уже тонкости).
И если тайлы vesat у меня отстреливаются как из пулемёта, то про dgsat этого отнюдь не скажешь, даже не тайл в секунду (безо всяких таймаутов в сасе). Между тем на 10-м зуме 49-й стек обошёлся в 1.5 часа работы, 48-й - в 2.5 часа (супротив получаса vesat для всё той же тестовой области без малого в 4 тыщи тайлов на 10-м зуме).

Кстати, DG можно отбивать (и невозбранно выкачивать на полной скорости, без банов и ватермарков) из того же GE. GE имеет отдельный специально обученный слой "Покрытие DigitalGlobe" или как-то так - вот его и можно мониторить.
Правда, обновления будут не по типу "49й стек DG" - а по типу "ХЗ какой стек, но DG - из числа выбранных и выложенных гуглом".
Но это будет таки все еще кошерный DG...
Уж больно гиморно выкачивать "родной" DG щас.....

[vasketsov]

Он может быть недоступен по какой причине?
1. Так сказал root (и тогда это уже не к скрипту), либо
2. Кэш внезапно стал недоступен физически (еррор железа например, или флешку выдрали) - и тогда это опять же не к скрипту.

Я имел в виду
3. Скрипт как прокси-сервер размещён фиг знает где в интернете, а сас знает о нём исключительно через упоминание его адреса и номера порта в GetURLScript. Доступа к сасу из скрипта нет равно как нету доступа с любого публичного открытого прокси к локальным файлам у любого юзера на компе.

[Parasite]

Он может быть недоступен по какой причине?
1. Так сказал root (и тогда это уже не к скрипту), либо
2. Кэш внезапно стал недоступен физически (еррор железа например, или флешку выдрали) - и тогда это опять же не к скрипту.

Я имел в виду
3. Скрипт как прокси-сервер размещён фиг знает где в интернете, а сас знает о нём исключительно через упоминание его адреса и номера порта в GetURLScript.

На сие есть встречный скрипт - берущий данные у удаленного проксика и кладущий в кэш локального САСа (откуда локальный САС их выгребает в режиме "cache-only").
Удаленный проксик при этом ничем не отличается от канонiчного картосервиса - для локального скрипта разницы нет, откуда тянуть контент: с удаленного картосервиса или с удаленного проксика к оному.

[Obscured]

Вопрос немного не в тему: а покрытие на VirtualEarth в последний год хоть сколько-нибудь заметно обновляется? В том числе по России? Раньше у них был сайт http://bingmapsupdates.cloudapp.net/ где публиковались обзоры, а сейчас никакой информации.