zed писал(а):А теперь, собственно, чтоб получить тайл нужно:
- Из исходного URL выделить: ServerType, TileType, TVersion, THistory, TLayer, TZoom, X, Y. (Если какого-то параметра нет, то его нужно приравнять нулю)
- Выполнить SQL запрос к основной таблице и получить недостающие параметры: CacheID, OffSet, TSize, CRC;
- Выполнить SQL запрос к дополнительной таблице и получить TypeID и FileName;
- Если TypeID=2 или 3, то открыть файл FileName, сместиться на OffSet от начала файла и считать TSize байт - считанные байты и будут искомым тайлом.
При желании, можно подсчитать CRC считанного тайла и сравнить с CRC из индекса, но я обычно такой проверки не выполняю, чтоб не замедлять процесс.
При желании можно подсмотреть в исходниках GC как реализована та или иная функция.
Вы не находите, что задача несколько перерастает рамки утверждения "нескольких строк кода (сторонней программе) будет вполне достаточно"?
К вышесказанному могу добавить шаги (ненулевые) по прикручиванию модулей работы с SQLite к голому перлу\пхп....а в результате я получу тот же самый тайл, который я получаю прямо сейчас из тайлового кэша и ДЕЙСТВИТЕЛЬНО парой строчек кода.
Я понимаю, что база эффективней, удобнее при переносе итд.....но лично у меня - ReiserFS имеет встроенные функции индексации контента усилиями самой оси, журналирование\защита\откат ошибок\ тоже в наличии средствами все той же оси, RAID и прочие мирроринги тоже (по желанию), а вопрос переноса решается либо тупым dd /dev/sda1 /dev/sdb1 (раскатывающем за десяток минут ИМИДЖ винта с первого на второй без каких-либо задержек с обращениями в TOC), либо еще более тупо - переносом самого USB-винта (у меня весь кэш на выделенном винте).
PS: ключевые слова выше - "лично у меня". Читающим просьба не открывать флейм на пустом месте, спасибо.
