SASGIS

Веб-картография и навигация

Библиотека модулей для работы с гео-тайлами [Python]

Форум для обсуждения деталей разработки программы SAS.Планета

Модераторы: vdemidov, Tolik

Библиотека модулей для работы с гео-тайлами [Python]

Сообщение svp » 02 дек 2010, 15:18

В связи с постоянной необходимостью автоматизации и унификации работы с различными тайловыми структурами (карты, снимки, панорамы) было принято решение писать специализированную библиотеку модулей. И вот настало время выложить репозиторий проекта в открытый доступ.
Следует отметить, что сейчас разработка библиотеки лишь на начальной стадии.
Следующий функционал уже реализован:
  • Класс tileid для хранения и основных операций с индексом тайла (координаты+зумм).
    Компактный бинарный формат пригоден для использования в качестве индекса БД. Технически индекс представляет собой неизменяемый объект (в терминологии Питона) потомок от типа long.
    Реализует итератор по цепочке предков от корня. Инициализируется из различных видов записи: координатной (x, y, z), пирамидальной ("qrts" или [0, 1, 2, 3]), пирамидально-бинарной.
  • Класс tileset для хранения маски заполнения тайлового поля.
    Изначально предназначался для быстрой проверки наличия тайла в хранилище, но на данный момент функционал класса позволяет делать очень интересные вещи.
    Экземпляр класса предназначен для хранения информации о заполнении одного тайлового слоя в одном масштабе, например, sat\z19. Информация о тайлах эффективно хранится в дереве так, что, например, полностью заполненный или полностью пустой слой занимает в дереве всего один узел. Кроме того, в дереве можно хранить не только двоичные состояния тайлов (есть/нет), но и более широкий набор информации, например, неизвестно/есть/нет/загрузился_с_ошибкой и т.д.
    На данный момент можно задавать 255 различных состояний тайла, сохраняя, скажем, информацию о версии тайлов. Например у нас есть недокачанный тайловый кеш окрестностей Парижа. В какой-то момент источник сменил версию тайлов и сервис начал гнать более свежие картинки. Такую ситуацию можно отслеживать и отмечать версию в тайлсете, что позволит не перепутать старые и новые тайлы между собой.
    tileset умеет эффективно сохраняться в бинарный файл и загружаться из него. Состояния тайлов могут задаваться не только целыми числами, но вообще любыми неизменяемыми объектами (в терминологии Питона), например, строками или кортежами. При этом строки занимают место в структуре тайлсета в памяти и на диске только один раз, а в узлах дерева они упоминаются по индексу.
    Кроме всего прочего тайлсет предоставляет итераторы по узлам и по тайлам, статистику о заполнении, методы для одиночной и массовой установки статуса тайлам.
Конечно же, не сделано. как всегда, больше. В ближайших планах:
    Для тайлсета
  • Итератор по узлам или тайлам определённого статуса.
  • Пересечение, вычитание, сложение тайлсетов.
  • Фильтры и пастеризация по статусам/набору статусов.
    Из прочего
  • Формирование векторных и растровых прозрачных тайлов с текстурой заполнения на основе тайлсета (технически решается обходом фрагмента дерева в глубину, что очень эффективно).
  • Создание класса абстрактного тайлохранилища.
  • Создание реальных классов тайлохранилищ на основе базы Беркли, sqlite, файловой системы, web-источников и т.д..
  • Поддержка в тайлохранилищах многоверсионности тайлов.
  • Веб-сервер источник тайлов на основе CGI Python. Планируется реализовать интерфейс тайлохранилища на отдельном веб-сервере с http-доступом посредством обычных get и post запросов. Таким образом можно будет уйти от работы с тайловыми хранилищами и кэшами внутри SAS-планеты и вынести всё это на выделенный или локальный веб-сервер. Это даст возможность использовать один кеш в локальной сети и через интернет, а клиентское приложение (SAS-Планета, например) может сосредоточиться лишь на текущем оперативном кэшировании ближайших тайлов.
  • Возможность поставки тайлохранилищем тайлов с маской заполнения.
Желающие поучаствовать в разработке приветствуются. Даже если тяжело, пока что, придумывать эффективный и лаконичный API, можно попробовать себя на поприще написания юнит-тестов.
Юнит-тестирование в таком проекте необходимо как воздух, и связано это, в основном, с непрерывным изменением в ходе разработки реализаций тех или иных механизмов работы библиотеки. Постоянно что-то ломается и следить за всем этим желательно непрерывно, чтобы потом не погрязнуть в рутинной отладке.
Сейчас нужно довести до ума модуль с тестами тайлсета. Модуль Tileid уже более менее покрыт ими.
Прошу к обсуждению с пожеланиями и предложениями.
Аватара пользователя
svp
Советчик
 
Сообщения: 447
ICQ: 204094886
Зарегистрирован: 26 авг 2008, 11:14
Откуда: Белгород
Благодарил (а): 2 раз.
Поблагодарили: 4 раз.

Re: Библиотека модулей для работы с гео-тайлами [Python]

Сообщение Parasite » 02 дек 2010, 19:25

svp писал(а):На данный момент можно задавать 255 различных состояний тайла, сохраняя, скажем, информацию о версии тайлов.

Версии тайлов (на ГЕ как минимум) уже уехали весьма за 255.
Текущая версия, если не ошибаюсь - 352, and counting.

svp писал(а):Создание реальных классов тайлохранилищ на основе sqlite

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

На Mysql из вышесказанного остается только крайне низкая надежность на больших базах даже при выборе журналируемого хранилища INNODB вместо штатного MYISAM. Базы стабильно валятся при числе записей от 400млн и выше (размер базы ок.100Гб), при этом штатными средствами уже не восстанавливаются - необходимо пересоздание с нуля. По совокупности грешков - забросил оба варианта, остановился на нижеследующем.

svp писал(а):файловой системы,

Как показывает опыт и долговременное пользование, ЭТО удовлетворяет по всем пунктам.
Из начальных вкусностей - индексирование, журналирование, возможность сохранения более 1 файла в 1 кластер, возможность хранить журнал отдельно от собственно файлокучи (вплоть до удаленного хранения), либо вообще без оного.

Весь вопрос - в обучении винды работе с этой ФС (текущие попавшиеся мне готовые варианты дают РО доступ без учета журнала, но возможно кому-то удастся найти что-то вменяемее - я искал весьма недолго, ибо мне неактуально). В качестве временной меры - песочница+сабж, расшаренный по "внутренней" песочной сетке в локалхост или наружу.
The only difference between me and a mad man is that I am not mad. /Salvador Dali/
Изображение
Аватара пользователя
Parasite
Администратор
 
Сообщения: 5646
Зарегистрирован: 23 окт 2008, 17:38
Благодарил (а): 124 раз.
Поблагодарили: 459 раз.

Re: Библиотека модулей для работы с гео-тайлами [Python]

Сообщение svp » 02 дек 2010, 20:44

Parasite писал(а):
svp писал(а):На данный момент можно задавать 255 различных состояний тайла, сохраняя, скажем, информацию о версии тайлов.

Версии тайлов (на ГЕ как минимум) уже уехали весьма за 255.
Текущая версия, если не ошибаюсь - 352, and counting.

Ты, видимо, не понял. 255 различных состояний не ограничивают числом 255 эти самые состояния. Состояние может иметь любое значение, хоть 350, хоть "тристапятьдесят", хоть "2010-12-25". То есть состояния тайлов можно кодировать даже строкой и это не повлияет на производительность тайлсета. Речь шла о том, что в тайлсете (пока что) можно хранить не более 255 РАЗЛИЧНЫХ состояний тайлов. Какими числами, или строками, или кортежами их кодировать -- это не важно. К тому же гугловское понятие этой самой версии -- это плохой пример. На сколько я знаю, версия в гугле опосредованно влияет на выдаваемые тайлы. То есть, когда меняется версия -- это не значит, что обязательно будут заменены все тайлы.
А следовательно этот параметр в тайлсете хранить не имеет смысла вообще.

Parasite писал(а):
svp писал(а):sqlite

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

Ок. sqlite вычеркиваем.

Parasite писал(а):На Mysql из вышесказанного остается только крайне низкая надежность на больших базах даже при выборе журналируемого хранилища INNODB вместо штатного MYISAM. Базы стабильно валятся при числе записей от 400млн и выше (размер базы ок.100Гб)

Никто не мешает кеш хранить кусками в отдельных базах, скажем, по гигабайту. При наличии механизма (tileset), который может быстро ответить в какой именно базе (т.е. в каком фрагменте хранилища) лежит тот или иной тайл, хранение тайлов во фрагментированном хранилище не представляет проблемы.
Это, кстати, ещё один юзкейс tileset'а. Время обращения к нему, по идее, не зависит от заполненности базы, а в самом тайлсете можно хранить как раз алиасы баз (или в общем случае хранилищ), где хранятся конкретные тайлы.
По-моему, кучка аккуратненьких гигабайтных файлов с тайловыми БД -- это поудобнее, чем миллионы сырых тайлов в файловой системе. В случае же краха отдельной базы мы её стараемся восстановить штатными средствами или перекачиваем невосстановленное.
Тайлсет в таком случае используется следующим образом:
Рассмотрим кеш 19 уровня. Изначально в тайлсете только одна запись, например "http://<чего-то там>maps.google.com/<короче это алиас, намекающий где искать тайлы>". Это означает, что какой бы мы тайл ни запросили у такого тайлсета, он вернёт нам ту самую строку. То есть, пошлёт в гугол.
Дальше мы пытаемся скачать тайл, и есть варианты:
1 - такого тайла не бывает. => В тайлсет по адресу этого тайла кладём статус "отсутствует".
Код: Выделить всё
my_tileset[tile_ident] = ABSENT

2 - гугл отдаёт тайл ==> Тайл кладём в незаполненное ещё хранилище, а в тайлсет улетает строка с алиаом на хранилище.
Код: Выделить всё
storage = get_current_storage()
storage.add(tile_ident, tile_data)
my_tileset[tile_ident] = storage.alias

При этом storage само ведёт свой тайлсет с указанием имеющихся у него тайлов, и если у нас по какой-то причине теряет актуальность my_tileset, то мы его восстанавливаем слив в один тайлсеты всех хранилищ. Алгоритмически это по сути слияние деревьев с максимальной глубиной равной зуму.

Обратившись впоследствии за тайлом снова, мы уже можем получить не ссылку на гугл, а алиас на наше хранилище:
Код: Выделить всё
storage=sorage_meta_factory(my_tileset[tile_ident])
// в результате получаем либо хранилище-заглушку,
// выдающую всегда один и тот же тайл с надписью об ошибке,
// либо интерфейс к веб-хранилищу а-ля гугол,
// либо наше базадатое хранилище, которое найдено в пуле
// или создано фабрикой sorage_meta_factory по алиасу, извлеченному
// из my_tileset. Не важно что это за хранилище.
tile_data = storage[tile_ident] // уаля: картинка лежит в tile_data


Parasite писал(а):По совокупности грешков - забросил оба варианта, остановился на нижеследующем.
svp писал(а):файловой системы,

Никаких проблем. У меня все хранилища будут поддерживать методы базового класса, и не важно где реально лежат тайлы.
Также планируется сделать http сервер для расшаривания тайлов в хранилище.
Да, и хранилища можно будет собирать и вкладывать как матрёшки.
Например на веб-сервере мета-хранилище по запросу тайла клиентом смотрит нет ли такого тайла локально (обращается к локальному подчинённому пулу тех самым гигабайтных хранилищ), затем может полезть за этим тайлом через виртуальное_хранилище_враппер, обёрнутый вокруг гугла. Получив тайл, мета-хранилище нашего веб-сервера кладёт его себе в закрома и, если работа идёт синхронно, отдаёт его запросившему клиенту, либо ждёт повторного обращения от него. И уж тогда-то отдаст тайл или информацию о том, что его не существует.
Аватара пользователя
svp
Советчик
 
Сообщения: 447
ICQ: 204094886
Зарегистрирован: 26 авг 2008, 11:14
Откуда: Белгород
Благодарил (а): 2 раз.
Поблагодарили: 4 раз.

Re: Библиотека модулей для работы с гео-тайлами [Python]

Сообщение Parasite » 02 дек 2010, 22:21

svp писал(а):
Parasite писал(а):
svp писал(а):На данный момент можно задавать 255 различных состояний тайла, сохраняя, скажем, информацию о версии тайлов.

Версии тайлов (на ГЕ как минимум) уже уехали весьма за 255.
Текущая версия, если не ошибаюсь - 352, and counting.

Ты, видимо, не понял.

Возможно, ибо фразу "задавать 255 различных состояний тайла, сохраняя, скажем, информацию о версии тайлов" я понял как возможность сохранения значения 0...255 выделенном например под версию.
Версии между тем безусловно нужны, и их уже больше 255. :)
Разобрались. Скип.

svp писал(а):На сколько я знаю, версия в гугле опосредованно влияет на выдаваемые тайлы. То есть, когда меняется версия -- это не значит, что обязательно будут заменены все тайлы.

Это с другой стороны не значит, что при смене версии дерева (глобальном апдейте ГЕ) - версия меняется вообще у ВСЕХ связанных с этим новым деревом тайлов. Она меняется только у нужных, действительно измененных в данном апдейте - хоть в шахматном порядке на слое они расположены, хоть в каком угодно еще. Все же остальные тайлы так и остаются лежать в неизменном виде и по старым УРЛам. В финале же каждый слой представляет из себя мозаику тайлов различных версий (безусловно версия ВСЕХ тайлов меняется только у Q-дерева. Прошел апдейт - ВСЁ Q-дерево поменяло версию по ВСЕМ своим тайлам, а предыдущее - кануло в Лету. Для тайлов контента же - это правило необязательно).

PS: замечено также, что гугль иногда идет кривой и нехорошей дорожкой - иногда меняя версии у тайлов, но не меняя их содержимого. Проверяется по CRC тайлов двух смежных версий. Особенно это касается "апдейтов" ландшафта.

svp писал(а):А следовательно этот параметр в тайлсете хранить не имеет смысла вообще.

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

svp писал(а):Никто не мешает кеш хранить кусками в отдельных базах, скажем, по гигабайту.

Используя например песочницу с вирт.диском (который для хост-системы выглядит как один файл) - мы и получаем искомое. То есть, ФС в песочнице = псевдо-база, один файл этого диска в хост-системе = "база по гигабайту". Оный файл можно невозбранно переносить между машинами как угодно, это не куча тайлового кэша а 1 большой файл. При этом при подключении оного к себе - мы имеем все прелести тайловой кучи прямым образом (удобство и простоту доступа, надежность хранилища итд.). Ну и не самое последнее в том, что песочницы делают профессионалы - а сас делают любители (вопросы надежностей, стабильностей и собствено поддержки).

svp писал(а):По-моему, кучка аккуратненьких гигабайтных файлов с тайловыми БД -- это поудобнее, чем миллионы сырых тайлов в файловой системе.

Вышеупомянутый Рейсер, например - это сама по себе БД, и с ней можно работать как с единым файлом. Просто ее фича в том, что ее можно подцепить и как ФС. :)
Нечто подобное есть и в NTFS (как совокупности обычных файлов $MFT+$Bitmap+$Journal итд - просто винда не дает их видеть как файлы).
То есть, там по большому счету - миллионов сырых тайлов нет. Есть БД, подключенная как ФС. Отсюда возможность писать сколь угодно много файлов в один "кластер" (по существу - в блоб БД), отсюда отсутствие кластеризации, отсюда возможность отлинковки журнала от хранилища, и отсюда же отсутствие дефрагментаторов для рейзера вообще - и все это прозрачно для системы, для нее это "просто винт с файлами". :)

svp писал(а):В случае же краха отдельной базы мы её стараемся восстановить штатными средствами или перекачиваем невосстановленное.

В случае краха мускула мне несколько раз приходилось перекачивать по 100++Гб, ибо любые попытки восстановления наталкивались на "FATAL ERROR: Database is corrupt" и крах собственно базовода. Альтернативные же продукты не понимали INNODB хранилище в оном (по умолчанию там всегда MYISAM, а INNO надо прикручивать ручками если очень хочется).
MYISAM валилось же еще на размерах до гигабайта (неск.млн.записей), так как инсерты при заполнении идут довольно плотно - а журнала в ней нет. ДДОСят.

svp писал(а):Также планируется сделать http сервер для расшаривания тайлов в хранилище.
Да, и хранилища можно будет собирать и вкладывать как матрёшки.

Года 3 как пользую такое (и много больше - например калькуляция и отдача авторизации ГЕ, то есть полновесный ГЕ-сервер) в масштабах организации, причем с вариантами: можно голый Перл с форками (если народу мало), можно расово верный и вылизанный Апач с PHP\Перлом (если народу уже неск.тысяч), итд... Все же промежуточные действия с контентом - уже на усмотрение скрипта, а там можно развернуться как угодно (собственно, все вышеупомянутые пляски с базами как раз и были именно на этом этапе).

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

На перле это примерно полстраницы. :)

Код: Выделить всё
use IO::Socket;
sub get_tile {
$tile=shift;
$tile =~ /(q2|qp|f1|f1c)-(\d+)(-(q.|d.|i.|t.)(\d+)((.|-)(\w+))?)?/;
#Вычисляем путь тайла в кэше
my $path=coord_to_path($2); $tile_path_in_cache=$global_cache.$tiletype."/".$version_in_cache.$path.$tile;

if (-e $tile_path_in_cache) {                             #если файл существует в кэше
        print "Тайла нет в БД, но есть в кэше.\n";
}
else {
        print "Тайла нет ни в БД ни в кэше. Скачиваем тайл с сервера...";
RETRY:
   $status=get_tile();                                    #сходим на сервер и получим тайл в кэш
       if (-e $tile_path_in_cache) {            #обработка результатов получения файла
           print "Ok!\n";
   }
       else {
      print "Получен пустой файл - ждем ".$socket_retry_interval."с и повторяем...\n";
      sleep $socket_retry_interval;
      goto RETRY;
   }
}
return $tile_path_in_cache;
}

sub get_tile {
RETRY_SOCKET:
   $geauth_session=GEsession();$file="/flatfile?".$tile;
   eval {$socket=IO::Socket::INET->new(
         PeerAddr => $http_server,
         PeerPort => $http_port,
         Proto => "tcp",
         Timeout => $socket_timeout)};
      if ($! =~ /timeout/){
         print "|-".$file."\n";
         print "|-обнаружена ошибка сокета TIMEOUT, повтор попытки через ".$socket_retry_interval."с.\n";
         sleep $socket_retry_interval;
         goto RETRY_SOCKET;
      }
      elsif ($! =~ /Unknown/){
         print "|-".$file."\n";
         print "|-обнаружена ошибка сокета UNKNOWN, повтор попытки через ".$socket_retry_interval."с.\n";
         sleep $socket_retry_interval;         
         goto RETRY_SOCKET;         
      }
   if ($socket && $socket->connected()) {
      print $socket "GET $file HTTP/1.0\n";
      print $socket $http_agent;
      print $socket $http_host;
      print $socket $http_connection;
      print $socket "\r\n";
   }
   else {
      sleep $socket_retry_interval;         
      goto RETRY_SOCKET;         
   }
   $store=$tile_path_in_cache;$status=file_store($tile_path_in_cache);         #сохраняем в файл
}
The only difference between me and a mad man is that I am not mad. /Salvador Dali/
Изображение
Аватара пользователя
Parasite
Администратор
 
Сообщения: 5646
Зарегистрирован: 23 окт 2008, 17:38
Благодарил (а): 124 раз.
Поблагодарили: 459 раз.

Re: Библиотека модулей для работы с гео-тайлами [Python]

Сообщение svp » 03 дек 2010, 14:08

Parasite писал(а):Это с другой стороны не значит, что при смене версии дерева (глобальном апдейте ГЕ) - версия меняется вообще у ВСЕХ связанных с этим новым деревом тайлов. Она меняется только у нужных, действительно измененных в данном апдейте - хоть в шахматном порядке на слое они расположены, хоть в каком угодно еще. Все же остальные тайлы так и остаются лежать в неизменном виде и по старым УРЛам. В финале же каждый слой представляет из себя мозаику тайлов различных версий (безусловно версия ВСЕХ тайлов меняется только у Q-дерева. Прошел апдейт - ВСЁ Q-дерево поменяло версию по ВСЕМ своим тайлам, а предыдущее - кануло в Лету. Для тайлов контента же - это правило необязательно).

Таак. Похоже я малость отстал от предметной области. Где почитать обо всех этих Q-деревьях, версиях тайлов и глобальных апдейтах?

Parasite писал(а):PS: замечено также, что гугль иногда идет кривой и нехорошей дорожкой - иногда меняя версии у тайлов, но не меняя их содержимого. Проверяется по CRC тайлов двух смежных версий. Особенно это касается "апдейтов" ландшафта.
Да. Именно так я и планировал расслаивать зоопарки тайлов, только в автоматическом режиме.

Parasite писал(а):У гугля версия тайла хранится в имени этого тайла. Каждого отдельно взятого тайла. И дерево ссылается на оные файлы в том числе и по версиям оных.

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

Parasite писал(а):Года 3 как пользую такое (и много больше - например калькуляция и отдача авторизации ГЕ, то есть полновесный ГЕ-сервер) в масштабах организации, причем с вариантами: можно голый Перл с форками (если народу мало), можно расово верный и вылизанный Апач с PHP\Перлом (если народу уже неск.тысяч), итд... Все же промежуточные действия с контентом - уже на усмотрение скрипта, а там можно развернуться как угодно (собственно, все вышеупомянутые пляски с базами как раз и были именно на этом этапе).
Да, видимо все эти твои шишки придётся мне собирать с нуля. Перл, ИМХО, негуманный язык. А питоновские скрипты можно будет юзать и на клиенте и на сервере.
Аватара пользователя
svp
Советчик
 
Сообщения: 447
ICQ: 204094886
Зарегистрирован: 26 авг 2008, 11:14
Откуда: Белгород
Благодарил (а): 2 раз.
Поблагодарили: 4 раз.

Re: Библиотека модулей для работы с гео-тайлами [Python]

Сообщение DJ VK » 03 дек 2010, 15:10

В программе уже есть четкая структура - папки, в них файлы по 1024 штуки. Новое решение должно предполагать формирование из определенной группы папок одного или нескольких контейнеров, например квадраты 128х128,256х256,512х512 тайлов упакованные в 1 контейнер.
Контейнер должен быть платформонезависимым, и не привязанным к конкретному компьютеру, обмениваться ими должно быть так же легко, как и zip архивами тайлов.
Можно просто разбить по сетке какого нибудь масштаба. 10,11,12 например. (Я использую у себя 11й, 1 квадрат редко превышает 300мб тайлов 18x)
Если сейчас отказаться от квадратичного разбиения начнутся сложности. Я считаю, что предельный размер файла базы данных (1ГБ) - не главный для разбиения на отдельные файлы критерий. Пусть лучше 4 базы по 250мб, но более удобных в плане переноса. файл в 1гб выложить можно не на любой файлообменник.
То, что мобильные яндекс карты также используют мега контейнеры, сформированные именно по квадратам тоже показатель.
Каждую версию также можно класть в отдельный контейнер, собственно манипуляции с каждой новой версией более похожи на манипуляции с новой картой вообще, нужно ли их объединять?
Голоса поделились между базами данных и виртуальными файловыми системами. А какие еще есть варианты контейнеров для хранения групп файлов?
Аватара пользователя
DJ VK
Гуру
 
Сообщения: 1468
Зарегистрирован: 16 апр 2009, 13:57
Откуда: 8 км. от МКАД
Благодарил (а): 82 раз.
Поблагодарили: 300 раз.

Re: Библиотека модулей для работы с гео-тайлами [Python]

Сообщение svp » 03 дек 2010, 16:14

DJ VK писал(а):В программе уже есть четкая структура - папки, в них файлы по 1024 штуки. Новое решение должно предполагать формирование из определенной группы папок одного или нескольких контейнеров, например квадраты 128х128,256х256,512х512 тайлов упакованные в 1 контейнер.

Новое решение пока что представляет собой набор библиотек, которые в перспеутиве позволят вам в нескольких строчках воплотить все самые извр... изощренные свои пожелания в плане хранения тайлов.
DJ VK писал(а):Контейнер должен быть платформонезависимым, и не привязанным к конкретному компьютеру
Библиотека даст возможность унаследоваться от абстрактного хранилища и минимальным количеством кода сделать поддержку хранения тайлов хоть на перфокартах. Основным же моим хранилищем, которое я и буду продвигать, будет BerkeleyDB. Ничего более распространённого для хранения произвольных пар ключ-значение ещё не придумали. Читаем об этом движке в википедии.

DJ VK писал(а):Можно просто разбить по сетке какого нибудь масштаба. 10,11,12 например. (Я использую у себя 11й, 1 квадрат редко превышает 300мб тайлов 18x)
Если сейчас отказаться от квадратичного разбиения начнутся сложности. Я считаю, что предельный размер файла базы данных (1ГБ) - не главный для разбиения на отдельные файлы критерий. Пусть лучше 4 базы по 250мб, но более удобных в плане переноса. файл в 1гб выложить можно не на любой файлообменник.

Думаю тут найдётся несколько правильных противоположных мнений на счет правил разбиения кеша на куски. У всех юзкейсы планеты и тайловых кешей разные. Parasite например, захочет иметь огромное хранилище в файловой системе (хотя, думаю, соблазнится когда-нибудь и на беркли), но будет монтировать его ручками или скриптами в баше. При всём уважении я не считаю это удобным вариантом, пригодным для повсеместного использования обычными пользователями=).
Кому-то (мне-например) удобно было бы иметь основное хранилище на домашнем сервере. географическое разбиение кеша по файлам мне там не принципиально, важно, лишь, обеспечить безопасность, коей противоречит хранение всех яиц в одном кармане. Следовательно мне нужны, скажем, гигабайтные файлы с произвольными тайлами внутри, а дефрагментация всего этого хозяйства по координатам будет производиться по мере необходимости. Переносить кеш мне понадобится либо целиком (гигабайтные куски рулят), либо по выбранным полигонам, тогда я просто запущу скрипт, который мне соберёт нужные тайлы в отдельное хранилище.
Хранилище будет поддерживать такой параметр, как размер куска, и ограничения эти будут соблюдаться хранилищем автоматически. Оговорюсь, ничто не мешает написать (или взять готовый) класс для специфического распределения тайлов по суб-хранилищам. Технически это просто потомок от абстрактного РАСПРЕДЕЛИТЕЛЯ с перекрытым методом распределения. метод этот содержит алгоритм, который решает в какое субхранилище положить тот или иной тайл.

DJ VK писал(а):То, что мобильные яндекс карты также используют мега контейнеры, сформированные именно по квадратам тоже показатель.

Не совсем. Наше дело предполагает гораздо большую свободу в манипуляциях с тайловым кешем. Яндексу это не нужно.

DJ VK писал(а):Каждую версию также можно класть в отдельный контейнер, собственно манипуляции с каждой новой версией более похожи на манипуляции с новой картой вообще, нужно ли их объединять?

Ещё раз: новая библиотека будет оперировать понятиями хранилищ, а не контейнеров. Хранилища могут быть вложенными и содержать логику работы с тайлами. На уровне контейнера будут работать специальные контейнерные хранилища, коих может быть написано сколько угодно для любых типов контейнеров.
В первую очередь будут написаны контейнерные хранилища для файловой системы и для базы беркли. На этом уровне одно хранилище -- один файл. Уровнем выше будут агрегатные хранилища, в которых будут регистрироваться хранилища более низкого уровня (например контейнерные) вместе с условиями распределения тайлов. Простейшее условие распределения -- это предельный размер хранилища, более сложные условия могут задаваться с помощью callback функций. Так можно реализовать агрегатное хранилище, которое будет собирать тайлы в отдельные контейнерные суб-хранилища (например по по вашим квадратам 256*256), по мере необходимости, даже, создавая недостающие контейнеры.
Агрегатное хранилище ещё более верхнего уровня может включать в себя ещё и веб-хранилише в режиме read only (например гугл).

DJ VK писал(а):Голоса поделились между базами данных и виртуальными файловыми системами. А какие еще есть варианты контейнеров для хранения групп файлов?
Ещё есть вариант написания какого-то самопального велосипеда.
И этот вариант не для меня. Базы данных -- это сказано слишком обобщенно. Базы бывают разными: реляционными или нереляционными, с поддержкой sql, транзакций, журналирования и без. Для нашего случая из стандартных проверенных решений идеальным образом подходит база беркли. Остальное -- это разной степени поделочные обёртки. В случае Паразита это мощная промышленная поделка инженеров, которая работает и приносит профит, а в случае всяких-там зип-контейнеров, трукриптовских разделов, свалки файлов -- это чистой воды наколенное творчество из подпорок и проволочек. Для таких целей есть база беркли. Она для этого придумана.
Аватара пользователя
svp
Советчик
 
Сообщения: 447
ICQ: 204094886
Зарегистрирован: 26 авг 2008, 11:14
Откуда: Белгород
Благодарил (а): 2 раз.
Поблагодарили: 4 раз.

Re: Библиотека модулей для работы с гео-тайлами [Python]

Сообщение Parasite » 03 дек 2010, 17:29

svp писал(а):
Parasite писал(а):Это с другой стороны не значит, что при смене версии дерева (глобальном апдейте ГЕ) - версия меняется вообще у ВСЕХ связанных с этим новым деревом тайлов. Она меняется только у нужных, действительно измененных в данном апдейте - хоть в шахматном порядке на слое они расположены, хоть в каком угодно еще. Все же остальные тайлы так и остаются лежать в неизменном виде и по старым УРЛам. В финале же каждый слой представляет из себя мозаику тайлов различных версий (безусловно версия ВСЕХ тайлов меняется только у Q-дерева. Прошел апдейт - ВСЁ Q-дерево поменяло версию по ВСЕМ своим тайлам, а предыдущее - кануло в Лету. Для тайлов контента же - это правило необязательно).

Таак. Похоже я малость отстал от предметной области. Где почитать обо всех этих Q-деревьях, версиях тайлов и глобальных апдейтах?

Где почитать в виде эссенции - не знаю, благодатных полных ссылок - не встречал. Можно задать вопрос например мне - что знаю, тем поделюсь. Личка доступна, аську тоже знаешь.

svp писал(а):Перл, ИМХО, негуманный язык.

Так говорят все виндузятники. :)
А на нем даже стихи писать можно (параграф ПОЭЗИЯ), и они будут работать как программы. :)

svp писал(а):А питоновские скрипты можно будет юзать и на клиенте и на сервере.

Перл это умеет с рождения.

svp писал(а):Parasite например, захочет иметь огромное хранилище в файловой системе

У Паразита уже давно размер тайлового кэша на рейзере приближается к 6Тб только по ГЕ (по контенту, так как фрагментации в рейзере нет), причем физически это разнесено на несколько физических дисков с возможностью раздельной и независимой работы каждого по отдельности (volume stripping).
Единственное, что Паразит действительно ждет от САСа в плане организации сасовского кэша - это учет версионности тайлов САСом. Все остальное Паразит давным-давно имеет собственными силами (включая собственно кэш с версионностью. Но сас работает с ним только через прокси-скрипт, увы).

svp писал(а):но будет монтировать его ручками или скриптами в баше

1 строчка в fstab

svp писал(а):тогда я просто запущу скрипт, который мне соберёт нужные тайлы в отдельное хранилище.

Что может быть проще (в реализации вопроса), чем сборка из тайлового кэша?

DJ VK писал(а):Голоса поделились между базами данных и виртуальными файловыми системами.

Вирт.файловые системы - это для пользователей винды (исключительно, и в порядке временной меры - ровно до того момента, пока камрад svp не допилит сабж). В нормальных операционных системах все запрашиваемое давным-давно часть системы (БД как ФС, журналирование транзакций, разбиение и прочая и прочая). Опять же, некто zed ранее в темах этого раздела анонсировал кэш на tar'е - и кажется даже давал какие-то сорцы... А тар тоже допускает разбиение. Ну и тд.
Лично я не голосовал за вирт.файловые системы - я их просто упомянул, как возможные альтернативы пользователям Windows, ибо оная нативно понимает весьма ограниченное число ФС. Лично мне это неактуально.

PS: лично я бы может быть и присоединился к сабжу, но увы - на питоновой мове не размовляю. Так что - тут от меня в лучшем случае будут тупо советы и мнения, и не далее. :(
The only difference between me and a mad man is that I am not mad. /Salvador Dali/
Изображение
Аватара пользователя
Parasite
Администратор
 
Сообщения: 5646
Зарегистрирован: 23 окт 2008, 17:38
Благодарил (а): 124 раз.
Поблагодарили: 459 раз.


Вернуться в Раздел для разработчиков программы SAS.Планета

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1