zed писал(а):Alexander,Интересно, каков же принцип вашего "!MaPro extra indexed pack ver. 1.0"? В каждом *.xpk файле вначале идёт индекс (для zoom 1-7 примерно 85kB), затем идут данные с заголовком по 47 байт, т.е. вы изобрели "велосипед" чисто под нужды вашей программы. Интересно, почему вы решили не использовать БД? Для SAS предлагают использовать БД Беркли - типа всё готово, разберись и юзай. Единственное, продумать индексирование, но в такой БД наверняка должны быть и встроенные механизмы. Лично для меня, пока что действительно легче изобрести что-то своё (только я бы изобретал на основе и подобии кэша GoogleEarth, с некоторыми доработками по индексу), чем освоить Беркли... Останавливает только мысль, что с Беркли успешно работал EarthSlicer и что, возможно, и SAS будет работать с этой БД (хотя опять же, по сути изобретается свой формат кэша - заголовки, принцип индексации и проч.) И ещё, почему-то я уверен, что по быстродействию мой кэш проиграет кэшу на основе БД...
Вы правильно поколупались в моём кэше, именно так там, только зря вы наивно полагаете что индекс обязан быть в начала, он свободно может начинаться 100000000 байта, как и с любого другово. Я не изобратал вилосипед, я просто взял за основу первую мысль которая пришла в голову по индексации кэша, это и стало форматом apk, потом чуть усовершенствовал и получился xpk. Меня всё в кэше устраивает теперь, я даже отказался от усовершенствования до 3 версии, которую недавно разработал, ибо не надо никому такую универсальность и информативность. Раз уж вы смотрели индекс, то полагаю могли бы и понять его примитивную структуру, это очень просто. БД я не стал использовать из соображений скорости, ибо почти все базы данных разрабатывались как универсальный контейнер для информации, мы же имеем дело с вполне вменяемой пирамидальной конструкцией, вполне понятного вида. Тогда почему бы не написать свою быструю и узконаправленную БД - далее кэш. Мой кэш был сделан как индивидуальный накопитель информации, т.е. мне нафиг не надо чтобы какая-нибудь программа поддерживала его, суть в том чтобы сохранить скаченные тайлы и показать их пользователю когда ему надо.
Едиственный недостаток кэша сейчас это скорость проверки наличия тайлов (всреднем всего 100000 тайлов / сек.)
Предположим у меня монитор 1400х1050 пикселов, я хочу посмотреть карту заполнения которая покажет в каждом пикселе наличие тайла, тогда мне надо за раз просмотреть почти 1,5 млн. тайлов, а значит мне придётся ждать 15 секунд. (
Мне бы хотелось чтобы операция занимала менее секунды, чтобы не вызывать неприятного ожидания.
1. Лучший способ ускорить надо запихать всё в оперативку, но ведь индексная структура сейчас у меня занимает 9Гб, хотелось бы поменьше.
2. Мне нет надобности хранить ссылки, мне надо наличие/отсутствие/отсутствие на сервере, значит всего 2 бита на тайл.
3. Нужен быстрый доступ к битам (за малое, очень огранниченное количество операций).
Родилась идея, идея даже была высказана в настолько подробном виде что если какой нибудь заинтересованный программист прочитал, подумал чуть чуть и написал бы уже код имея время на написание. Перед этим идея оформилась на бумаге, теперь реализуется на практике.
Замечу что предпологаемая скорость доступа (4млн.тайлов/сек.) даст желаемый результат (ненавязывать ожидание) и сможет полностью помещаться в памяти (ибо всего 20Мб, может 30Мб для моего текущего состояния кэша).