MaPro

[Alexander]

нифигасебе exeшник вырос до 8 метров посравнению со старой (0.4)..........

Вирусов добавил, чтобы скучно небыло

Кстати в не сжатом виде он 32Мб..

[Alexander]

Alexander, т.е. в индексе закодировано только наличие/отсутствия тайла и всё, больше никакой инфы?

Да, только информация о наличии (есть/нет/нет ни у кого). Следовательно, 2 бита на тайл. (в битовом массиве).

[zed]

svp,
По-крайней мере нужна ещё инфа о смещении, по которому находится тот или иной файл в кэше (ведь кэш одним файлом, хоть и для разных зумов)
Alexander,
Интересно, каков же принцип вашего "!MaPro extra indexed pack ver. 1.0"?
В каждом *.xpk файле вначале идёт индекс (для zoom 1-7 примерно 85kB), затем идут данные с заголовком по 47 байт, т.е. вы изобрели "велосипед" чисто под нужды вашей программы. Интересно, почему вы решили не использовать БД? Для SAS предлагают использовать БД Беркли - типа всё готово, разберись и юзай. Единственное, продумать индексирование, но в такой БД наверняка должны быть и встроенные механизмы. Лично для меня, пока что действительно легче изобрести что-то своё (только я бы изобретал на основе и подобии кэша GoogleEarth, с некоторыми доработками по индексу), чем освоить Беркли... Останавливает только мысль, что с Беркли успешно работал EarthSlicer и что, возможно, и SAS будет работать с этой БД (хотя опять же, по сути изобретается свой формат кэша - заголовки, принцип индексации и проч.) И ещё, почему-то я уверен, что по быстродействию мой кэш проиграет кэшу на основе БД...

[zed]

Alexander, т.е. в индексе закодировано только наличие/отсутствия тайла и всё, больше никакой инфы?

Да, только информация о наличии (есть/нет/нет ни у кого). Следовательно, 2 бита на тайл. (в битовом массиве).

Т.е. поиск тайла в кэше идёт путём "перебора" всего кэша? Это же ведь медленно...

[Alexander]

Т.е. поиск тайла в кэше идёт путём "перебора" всего кэша? Это же ведь медленно...

Нет, используется абсолютная адресация, нет никакого перебора абсолютно. Каждая операция записи/чтения производится за нормированное время.

[svp]

Для SAS предлагают использовать БД Беркли - типа всё готово, разберись и юзай. Единственное, продумать индексирование, но в такой БД наверняка должны быть и встроенные механизмы.

Беркли -- нереляционная БД. По сути хранит пару [индекс, значение]. Значение -- это сами данные. Индекс лбычно набирается из побайтовой конкатенации значений:
<тип кеша><zoom><x><y>.

Лично для меня, пока что действительно легче изобрести что-то своё (только я бы изобретал на основе и подобии кэша GoogleEarth, с некоторыми доработками по индексу), чем освоить Беркли...

Поверьте, это чисто психологическая проблема. В совокупности трудоёмкость изобретения, отладки, внедрения и хотябы минимального документирования будет много превышать трудоёмкость внедрения стандартного решения, придуманного именно для таких целей.

Останавливает только мысль, что с Беркли успешно работал EarthSlicer и что, возможно, и SAS будет работать с этой БД

Очень правильно, что останавливает. Ибо САС будет работать с этой БД. Не внутренними средствами. так через плагины, которые тоже, уверен, появятся.
А нечто самопальное нужно ещё задокументировать. чтобы не только Вы могли под это писать софт.

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

Заголовки не изобретаются. Принцип индексации тоже можно взять слайсеровский. Он там ничуть не плох. Да и смысла нет поступать иначе. Думается даже кеши будут совместимы.

И ещё, почему-то я уверен, что по быстродействию мой кэш проиграет кэшу на основе БД...

Угу. Беркли точили годами.

Это я всё к чему. Не оффтопика для, а высказывания мнения ради. Самопальный контейнер для кеша -- это плохо для развития проекта.
Индекс наличия тайлов -- это не то же что индекс тайлов в базе. Это совершенно разные вещи: первый для быстрого построения карты заполнения и определения необходимости закачки тайла, а второй для изъятия тайла из базы. Для определения необходимости качать/показывать тайл большого быстродействия не надо. Ибо на экране тайлов помещается немного, а при закачке из интернета накладные временные расходы несоизмеримы с мизерным временем выборки поиска по б-дереву в базе.
Насчёт индекса наличия тайлов, выходит, ситуация неоднозначна. Посути нужен он только для карты заполнения. А при её построении надо избегать перебора всех тайлов интересущего зума, помещающихся на экран. Даже при мгновенном определении наличия тайлов заполнение пикселями экрана очень медленное. Надо просто грамотно кешировать уже построенные области заполнения, не перестраивать области без необходимости, строить и отрисовывать их в фоновом режиме, не мешая пользователю.

[zed]

Абсолютная? т.е прочитав индекс о наличии/отсутствии тайла, вы сразу можете отпределить по какому смещению он лежит? Как вы это определяете?

[zed]

Индекс наличия тайлов -- это не то же что индекс тайлов в базе. Это совершенно разные вещи: первый для быстрого построения карты заполнения и определения необходимости закачки тайла, а второй для изъятия тайла из базы.

Верно, у MaPro я вижу только один индекс, и он выполняет обе функции... если с индексом наличия всё ясно - 2 бита на тайл (второй бит - я так понимаю, для определения наличия тайла в сети)- то как происходит поиск тайла в кэше для его изъятия. Вот что интересно.

[Alexander]

Верно, у MaPro я вижу только один индекс, и он выполняет обе функции... если с индексом наличия всё ясно - 2 бита на тайл (второй бит - я так понимаю, для определения наличия тайла в сети)- то как происходит поиск тайла в кэше для его изъятия. Вот что интересно.

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

[zed]

Так бы и спрашивали, а то ведём речь про общий внешний индекс, а тут вставляют вопрос об организации индексной структуры файлов моего кэша, без пояснения, забавные вы

не понял... а где тогда хранится внешний индекс?
Как без пояснения:

Интересно, каков же принцип вашего "!MaPro extra indexed pack ver. 1.0"?
В каждом *.xpk файле вначале идёт индекс (для zoom 1-7 примерно 85kB), затем идут данные с заголовком по 47 байт...