DCT
Advanced Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Замеченные баги (xp sp2, celeron 1.7, 256M памяти)
- когда двигается картинка, то ее периодически "заклинивает" - нельзя сдвинуть ниже/выше (влево/вправо - заклинивает реже) - лечится переходом в режим карты и обратно
- линейка не работает совсем
Добавлено:
Предложения по интерфейсу:
- hotkeys на основные функции (переключение спутник/карта итд), задействовать стрелки (например на плавное перемещение, с шифотом на более быстрое, с ctr на пролистывание полэкрана).
- (уже тут пробегало, суммирую) что то типа инструмента "zoom offset" GV с положительными и отрицательными значениями (+5 ... -4 хватит с запасом) (минуса к сожалению в GV нет): т.к. часто нету более высоких слоев и нет желания их качать/генерить, а иногда хотелось бы увеличить максимальный слой, особенно на больших разрешениях монитора для повышения читабельности
- Фулскрин-режим
- "масштабная линейка" (типа как у в правом нижнем углу у Гугла и Яндекса)
- измеритель маршрутов по точкам (типа тыкаю последовательно точки (на экране они отображаются! - внизу на панели считается путь, например ctr+z убрать последнюю точку, esc убрает все точки)
- 3 отдельных иконки (спутник/карта/гибрид) - т.к. многим актуально переключение только между 2-мя режимами
Добавлено:
Опишу, как я обычно качаю нужные мне слои на нужный район (возможно будет интересен алгоритм). Допустим, нужно скачать район деревни Гадюкино в максимальном разрешении. В GV на икс уровней выше копирую имена тайлов, в которые попадает район скачки (получается не обязательно прямоугольной формы, но по границам больших тайлов: чем больше икс, тем точнее границы). Дальше скриптом конвертирую этот файл-список в файл-список нужного мне более высокого уровня, и затем в файл очереди gadukino.ion для Reget (в этом файле строки типа "02792.jpg http://kh2.google.com/kh?n=404&v=17&t=trtqrtssrrrrss", помня об ограничениях файловой системы - разбиваю на несколько очередей - генерировать очереди для области прямоугольной формы на 16-й уровень умеет http://rock-et-al.webhost.ru/gdown/), качаю в Reget разбираясь с банами  . Проверяю на наличие БИТЫХ тайлов (алгоритм на http://rock-et-al.webhost.ru/gdown/ + альтернативный вариант где то тут видел спец. скрипт), если надо - их удаляю и перекачиваю. Далее скриптом конвертирую gadukino.ion в gadukino.bat (батник переименования 02792.jpg в Cache\.....r\s.jpg , после исполнения которого у меня появляется кэш GV района деревни Гадюкино в виде файловой системы, который я конверчу идущей в комплекте GV весьма удобной консольной утилиткой (видел выше были проблемы: GV не умеет сам конвертить кэш в bdb - только этой утилитой, ман у нее достаточный) PUtil в что-то типа cache16_gadukino_2006.05.24.bdb. Всё. Немного муторно, но надежно. Если нужно объединить перекрывающиеся кэши деревни Гадюкино и близлежащей деревни Туманово - то я с помощью PUtil распаковывал объединяемые bdb в разные каталоги, сливал все в один каталог (с возможным overwrit-ом более старых тайлов) и упаковывал все в одну базу: на 200M кэшах - процесс шел безглючно и довольно быстро...
Отсюда на основе своего опыта сделаю следующие выводы относительно кэша:
1) Berkeley DB - IMHO оптимальный формат по объему и по скорости: GV на Celeron 233 48M памяти и WinNT 4.0 летает(!), причем терпимо допускает генерацию ("zoom offset") +1 уровень (+2 уже очень торомозит, но работает - а ведь количество выводимых на экран тайлов увеличивалось в 8 раз!) при 3-х подключенных 250M bdb! Хотелось бы и от SM такой работоспособности (ведь в путешествия многие берут старые ноуты!)... (Тут писалось про проблемы программирования Berkeley DB - так вот у GV на сайте лежала часть исходников, сейчас однако сайт лежит, но может кто их успел скачать?...)
2) Удобно было бы сделать генерацию файла очереди скачки из выделенных тайлов (сначала вылеляются тайлы на маленьком уровне, затем увеличивая уровень возможность включить/исключить тайлы - в конце программа показывает объем и генерит очередь)
3) Далее каждый качает (и разбирается с банами), как и чем ему удобно, результат можно легко проверить на наличие битых тайлов и их перекачать. Далее отдельной утилитой запаковывать скачанную очередь в базу. (Отдельная утилита для объединения кэшэй без распаковки). Возможно также сделать _отдельную_ качалку либо по спискам прокси либо (можно и в ручную) распознавая картинки а-ля RSDownloader-а - алгоритм гугла и файлообменников очень похож.
4) В отличие от больших очередей, небольшое количество файлов, например отсутствующие фрагменты в режиме просмотра, напрямую догружать из нета.
5) Высокие уровни НЕОБХОДИМО держать по несколько файлов на уровень: с названиями типа cache16_Piter, cache16_MSK, cache16_Urupinsk ... - так легче ими меняться, сливать их воедино мне представляется большой ошибкой, равно как разбивать кэш "по зонам"!
6) Также представляется целесообразным (легче меняться и управлять!) держать отдельно db карты/гибрида/спутника - к тому же помниться, GMV пытался пихать все в однин db, и в итоге его db только для спутника был существенно больше db у GV из-за лишних пустых полей в базе.
7) Возможность держать "старый" и "новый" кэши - типа как в GV можно менять последовательность чтения db - т.к. старый добрый Landsat последних "невысоких" уровней (например 14-го) к сожалению часто оказывается информативнее мутных/весенних/облачных новых снимков высокого разрешения (как у GV в плагинах можно выставить порядок чтения баз - так и в SM прописать это в ini).
8) Присоединяюсь к просьбе о возможности читать разные кэши - реализовать что то типа загружаемых плагинов GV
Програмный Кэш: IMHO у GV это сделано грамотно: там можно было задавать количество тайлов в кэшэ программы (програма также указывала объем этого дела в памяти и рекомендуемое значение)
Отдельно соображения насчет карт: держать их в jpg жутко расточительно - поскольку они содержат фон и надписи, то логично предусмотреть возможность пережать их вэйвлетами (jpeg2000, типа djvu) с background и foreground слоями - они займут мизер, и появится фантстическая идея обойтись _вообще_ без гибрида, накладывая foreground слой тайла карты на взятый в качестве background-а тайл спутника (на тестовых фрагментах у меня такой "гибрид" получается неплохо, хотя програмная реализация этого трюка боюсь не из легких...) |
Если есть алгоритм деления инфы с тайла карты на foreground и background, был бы признателен за него.