SAS.NEXT - FMX version of SAS.Planet

[DJ VK]

4 байта - длина

А она точно нужна? Может раз уж формат только для чтения, то можно потребовать что тайлы лежат последовательно? Или планируется где-то сделать и записываемый вариант?

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

[vdemidov]

Об

4 байта - длина

А она точно нужна? Может раз уж формат только для чтения, то можно потребовать что тайлы лежат последовательно? Или планируется где-то сделать и записываемый вариант?

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

Обычно, признаком отсутствия информации делают не нулевое смещение

4 байта - смещение тайла x=0 y=0 (0 если тайла нет)

, а смещение равное смещению следующего участка с данными. Плюс добавляем в самый конец индекса смещение конца данных для последнего участка. Итого что бы прочитать тайл нужно считать 3 инта (смещение начала, дата, смещение конца) и проверить на ненулевую длину (смещение конца > смещение начала).

А еще в упаковке нужно предусмотреть ситуацию, что суммарный размер хедера и всех тайлов будет больше 2-х гигов. 32 килобайта на тайл это не так уж и много.

[DJ VK]

Итого что бы прочитать тайл нужно считать 3 инта (смещение начала, дата, смещение конца) и проверить на ненулевую длину (смещение конца > смещение начала).

А еще в упаковке нужно предусмотреть ситуацию, что суммарный размер хедера и всех тайлов будет больше 2-х гигов. 32 килобайта на тайл это не так уж и много.

экономия 33%. Неплохая оптимизация размера хедера... у меня для беркли размер тома в среднем 1 гб. Больше 1,5 гб не получалось не разу. Вот с png могут быть проблемы... С другой стороны png гибрид яндекса дает тома 20мб, 200 томов z18 - всего 5 гигов ))). 65К BMP дают размер 17гб...
А как себя ведет та же беркли в случае больше 2гб?
Несколько связанных файлов предполагают либо хранение еще и номера файла, что вновь увеличит размер заголовка, либо размазывание заголовка по частям, и понадобится открытие нескольких файлов подряд для поиска. Идеально решение - вынести размер тома в тайлах в параметр. 256x256, 128x128, 64x64. (а для гибрида c сильно прореженными тайлами можно в большую сторону 512x512, 1024x1024). Для всех масштабов единый размер томов. в корень директории кеша файл поместить со степенью двойки. Не совсем как в беркли, зато какое пространство для оптимизации размера(!). 2 именно в восьмой степени же не обязательное правило.
максимальное 1024x1024 как раз соответствует нумерации папок кеша беркли(!), там видать с запасом сделано. просто в подпапке будет 1,4,16, 64 или 256 файлов кэша.

[vdemidov]

экономия 33%. Неплохая оптимизация размера хедера...

Ну, способ как бы не мной придуман. Если не ошибаюсь в ttf формате так информация об отдельных глифах задается. То есть есть диапазон глифов, но некоторых может не быть и вот для них смещение просто равно смещению на следующий глиф.

А как себя ведет та же беркли в случае больше 2гб?

Понятия не имею. Подозреваю что просто растут без ограничения, а может доп файлы появляются. Тут же два разных ограничения: 1. Файловая система может ограничивать 2 Гб, но это уже не часто встречается, только на флешках с FAT. 2. Ограничения на величину смещению у тебя инт, соответственно максимум 4 Гб.

Идеально решение - вынести размер тома в тайлах в параметр.

Ну, такой вариант всегда есть. Проблема в том, что если этот параметр задан один на все тайлохранилище, то если при экспорте на бог знает каком томе столкнулись с проблемой - то все нужно переделывать.

Идеально было бы придумать адаптивный режим, который бы не сильно усложнял потом чтение, но при этом позволял некоторые тома разбить на 4. Но для такого режима лучше именование файлов взять qrts (типа как в GMV, но еще с разбивкой по папкам) или 0123, а не то которое используется в Беркли.
Например так:
Зум задает сколько символов(qrts) должно быть в полном имени тайла. Для упрощения обычно делают Z+1 и всегда начинается с t. 1 символ на нулевом зуме и 24 максимум на 23-м.
Под имя тома и нумерацию внутри тома откусываем 10 символов справа, а остальное используем под имя папки. Если под имя папки осталось больше 8 символов, то разделяем на два уровня иерархи.
Имя тома по-умолчанию +2 символа, то есть в томе выходит 256*256 тайлов, но если где-то слишком много, то разбиваем конкретный том на 4, с добавлением к имени каждого файла 1-го символа. Если все равно не влазим, то можно каждый разбивать на 4 и тд на пару уровней.
При чтении получается, что если нет файла с дефолтной длинной имени, то нужно проверять с добавлением 1-го, 2-х, 3-х символов (может больше, но вряд ли имеет смысл)

Но это весьма большое усложнение чтения. И вряд ли того стоит. Просто умозрительные упражнения.

[DJ VK]

Но это весьма большое усложнение чтения. И вряд ли того стоит. Просто умозрительные упражнения.

1) На карте памяти свободно 30гб. Ну есть маняьки, у которых 60гб. И, как правило, это несколько разных карт.сервисов. При размере кеша 5-10-20 Гб не понадобится ждать двое суток чтобы его пересоздать. Тем более это разовый, редко осуществляемый процесс.
2) Как я уже заметил, эксплуатация беркли показывает, что тома больше 2гб - крайне редкое исключение. Для сервисов покрывающих рельно дофига (DG, Google, Bing, Yandex а значит и размер кэша может быть гигантский все пройдет с дефолтными параметрами) На у когда в редких случаях не повезло - надо переделать.
3) Экспортируя кэш для мобилы не получается точно угадать его размер. Выделяем область экспортируем, смотрим сколько гигабайт получилось. если мало то можно раздвинуть обводку, если много - уменьшаем где можно. Приходится делать 2-3 итерации. Еще одна у моря погоды не сделает... (Неактуально только для тех, кто сколько надо экспортировать, столько и качает сразу, и знает размер всего кеша.)

Достаточно скачать кеш или сконверировать после скачки в беркли и поглядеть его размер томов. Сразу станет ясно какой размер использовать при экспорте

Поэтому я остановился на выборе размера тома (в тайлах) при экспорте.

Создается в корне кэша файл конфигурации .conf (Содержит информацию о размере тома.) Сюда же я content type все встреченные при экспорте перечислю.
итого заголовок
Uint32 Offset
Uint32 Length (под вопросом. может чекбокс добавить во фрейм?)
Uint32 FileDate
uchar ContentTypeID
uchar ExtentionID
word - 1 bit TNE, 15 bit reserved (VersionID ???)
-------------------------------------------------------------
Я экспортирую 1)из неверсионного беркли
2)из стандартного кеша планеты
Подскажи, что именно будет при этом лежать в VTileInfo.ContentType, VTileInfo.VersionInfo и в каком виде?

[vdemidov]

Поэтому я остановился на выборе размера тома (в тайлах) при экспорте.

Так я и не сомневался.

Uint32 Offset
Uint32 Length (под вопросом. может чекбокс добавить во фрейм?)
Uint32 FileDate
uchar ContentTypeID
uchar ExtentionID
word - 1 bit TNE, 15 bit reserved (VersionID ???)

Ничего не понял.

Подскажи, что именно будет при этом лежать в VTileInfo.ContentType, VTileInfo.VersionInfo и в каком виде?

Ну, в ContentType будет объект IContentTypeInfoBasic, у которого можно попросить GetContentType в виде строки или GetDefaultExt.
В VersionInfo будет... ХЗ что будет. Наверное ссылка на объект с текущей версией. А может nil.

[DJ VK]

в строчке
if Supports(FTileStorage.GetTileInfoEx(VTile, VZoom, FVersion, gtimWithData), ITileInfoWithData, VTileInfo) then begin
будут несуществующие тайлы IsExists = false и тайлы с IsExistsTNE = true или они в экспорт не проходят?

[vdemidov]

в строчке
if Supports(FTileStorage.GetTileInfoEx(VTile, VZoom, FVersion, gtimWithData), ITileInfoWithData, VTileInfo) then begin
будут несуществующие тайлы IsExists = false и тайлы с IsExistsTNE = true или они в экспорт не проходят?

Tne будут в эту строчку приходить, но именно ей и будут отбрасываться.