» SatMap

zporuchik

Цитата:

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

Я о сомнительности этой затеи автору уже месяц назад писал. Сейчас после нескольких экспериментов с весьма средними по масштабам файлами кэша прога зависла напрочь. Дальнейшие эксперименты проводить желания нет, но думаю, что проблема не только в том, что новый кэш организован по принципу свалки, но и в самом внутреннем формате кэша. На старом при 25 GB и нескольких файлах 2,5 GB программа вообще не тормозила, теперь же полный аут.

Дело точно не в формате нового кэша.

Сам SQLite http://sqlite.org/features.html
Supports terabyte-sized databases and gigabyte-sized strings and blobs.

А эти зависания скорее всего баги либо самого SatMap либо бинлинга sqlite для delphi.
Так что почитайте внимательно что такое SQLite - там нет никакой свалки, все проиндексировано.

zporuchik

Цитата:

еще недостаток: при убитии настроек - игнорируется наличие созданных кэшей. их надо опять вручную подключать?

Естественно! Ты же, можно сказать, убил проге память.

Цитата:

а откуда берутся эти:

Берутся откуда надо, об этом не надо беспокоиться
rex

Цитата:

До 1 GB работает неплохо, с 2- х GB после попытки перемещения зависает на 10-15 секунд

Мой кэш 1.67 гига - все летает. Почему у тебя тормоза?
Скинь свой файл конфиги и опиши подробно систему, какое разрешение экрана?

To All:
У кого еще большой кэш - тоже тормоза???

Цитата:

Мой кэш 1.67 гига - все летает. Почему у тебя тормоза?
Скинь свой файл конфиги и опиши подробно систему, какое разрешение экрана?

И у меня на кэше 1-10 уровней все летает. Проблемы начинаются когда совокупный кэш растет до 3-5 гигиабайт. Проц P1.8M. Память 2 GB. Разрешение экрана 1400х1050.

Добавлено:
messer20878

Цитата:

Так что почитайте внимательно что такое SQLite - там нет никакой свалки, все проиндексировано.

Свалку тоже можно проиндексировать и прохешировать.
Речь шла о структуре файлов кэша, а не о том что внутри. Там по определению файлы будут писаться по мере поступления, но сейчас программа автоматически разбивает кэш по уровням и слоям, а в новой полностью ручное управление, что при одновременной закачке нескольких уровней и слоев сразу создаст в дефолтном слое кашу из слоев и уровней. Синхронизировать такой кэш с другим компом крайне неудобно. Поэтому кэш желательно автоматически разбивать как в старой версии, независимо от внутреннего формата. Но и возможность ручного формирования оставить. Для выделения кэша отдельной страны например.

Рассматривал возможность размещения кеша в Berkeley DB?


http://www.oracle.com/technology/software/products/berkeley-db/index.html

relictus

Для теста попробуй просто сделать sqlite базу нужного размера просто заполнив ее одинаковыми картинками до нужного объема. Тогда с вопросами "у меня глючит странным образом на базе N Gb размера" можно будет разобраться.

rex

Интересно, а как ты синхронизируешь с другим компом? Бинарно сравнивая файлы?

SQLite предназначен для того чтобы быстро дать нужные данные по запросу.
Т.е. картинку тайла по заданным X,Y,Zoom, что там внутри файла базы не должно программу волновать.

А так как SQLite открытый формат, и посмотреть что у него внутри можно мноджеством утилит и библиоткек, написать программу которая синхронизирует дву базы тайлов не состовляет большого труда.

По параллельной закачке, выше уже писали что можно насоздавать нужных тебе файлов кэшей с разделением по уровням или слоям назвав их sat_0_12_moscow, sat_13_16_moscow и т.п. и качать параллельно. Никакой каши не будет.

messer20878

Цитата:

Интересно, а как ты синхронизируешь с другим компом? Бинарно сравнивая файлы?

Сейчас банально копируя файлы с датой изменения более новой чем на ноуте.


Цитата:

По параллельной закачке, выше уже писали что можно насоздавать нужных тебе файлов кэшей с разделением по уровням или слоям назвав их sat_0_12_moscow, sat_13_16_moscow и т.п. и качать параллельно. Никакой каши не будет.

Супер идея, настоящая многозадачность. В армии это называется пешим по машинному! В медицине геморрой.
Интересно через сколько секунд этого маразма гугль забанит IP?
Реликтус специально добавил возможность ставить задачу сразу по нескольким слоям и уровням, чтобы лишнего геморроя не было, а то что ты предлагаешь это вообще ...

sinmaks

Цитата:

Рассматривал возможность размещения кеша в Berkeley DB?

это пройденный материал, эту базу даж МайСкюл перестал поддерживать. Слишком она зажата. Вней можно только хранить, т.е. реалтайма не получится чтение/запись (т.е. запись, а чтение нормально), нет поддержки сетевого и мульти доступа.

rex
+1

rex


Цитата:

Сейчас банально копируя файлы с датой изменения более новой чем на ноуте.

А кто мешает делать то же самое и в новой версии? Файлов только будет не несколько а один. В чем проблема то?


Цитата:

Супер идея, настоящая многозадачность. В армии это называется пешим по машинному! В медицине геморрой.
Интересно через сколько секунд этого маразма гугль забанит IP?
Реликтус специально добавил возможность ставить задачу сразу по нескольким слоям и уровням, чтобы лишнего геморроя не было, а то что ты предлагаешь это вообще ...

Вопрос то был про организацию файлов. Я лишь предложил решение.
Предалагаемое вами "лекарство от гемороя" это что бы самостоятельно плодились
sat_moscow_1
sat_moscow_2
sat_moscow_3
... и т.д.

и это только ради того что бы удобно было копировать в другое место файлы с кэшем нужных уровней?

На сколько я помню в старом формате кэша хранение файлов по уровням - вынужденная мера - что бы отсрочить переполнение кэша. В новом формате "лекарство" в виде разбивки по уровням уже потеряло свою актуальность.

А копирование нужного уровня/слоя и синхронизация это теперь отдельная задача.

messer20878
а как же старая народная мудрость: Не храни все яйца в одной корзине!

messer20878
То что может быть однозначно структурировано, должно быть структурировано. Уровни и слои резделены и не пересекаются однозначно. Если надо вырезать кэш территории, то и он должен иметь ту же структуру, что и нормальная реляционная БД.

zporuchik

Делай бакапы

rex


Цитата:

То что может быть однозначно структурировано, должно быть структурировано. Уровни и слои резделены и не пересекаются однозначно.

Если вы привыкли работать с кэшем с помощью файлового менеджера тогда да.


Цитата:

Если надо вырезать кэш территории, то и он должен иметь ту же структуру, что и нормальная реляционная БД.

Конечно, он и имеет, в sqlite чтобы выбрать группу тайлов нужно ввести чтото такое -
select * from tiles where layer="stattelite" and zoom>0 and zoom<13

Программе только останется вставить эти выбранные SQLite-ом тайлы в другой кэш (еще одну базу SQLite).

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

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

Качать прозапас пока не закрыли? Так весь все равно не скачаешь, дисков не хватит, да и снимки на крупные города они обновляют раз в год примерно.

В общем для задачи "скачать нужный кусок и сохранить склеенный с привязками" все равно в одном или кучке файлов хранится кэш.

Для статистики - у меня сейчас кэш 6 Гб. Однозначно версия 1.4 летает НАМНОГО быстрее чем 1.3.х.

Добавлено:
Также я считаю что новая система гораздо более гибкая и логичная. Хочешь - сохраняй себе кэши по уровням и типам контента, хочешь по территории, хочешь вообще по версии снимков. А если кэша и вправду 25 Гб, то можно и по гигабайтам нарезать Я не думаю что все 25 Гб нужны одномоментно.

Всё это имхо, конечно...

messer20878

Цитата:

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

Для удобства работы в он-лайн. Не везде есть доступ к интернету. Например, в недавнем путешествии кэш гугля очень помог. GPS трэки накладывались на кэш, а не на примитивную карту, на которой двух третей горных дорог не было, иногда даже асфальтированных. Но часто не хватало разрешения. У SatMap , даже старого кэш на порядок больше, а поддержку треков автор рано или поздно добавит. А что касается размера, то 32GB это сечас обычная флэшка, а харды ноутбучные сейчас 500GB. Инет же безлимитный, качает себе и качает. Естественно не все подряд, но для уровней 17-19 даже одну среднюю европейскую страну за месяц не скачать. А предусмотреть в какой глухой угол тебя занесет заранее невозможно.
А вот как раз клейка мне не интересна. Сплошной кэш намного удобней. Если что и клеить так генштаб, хотя и здесь удобнее набор с возможностью перемещения.


Цитата:

А если кэша и вправду 25 Гб, то можно и по гигабайтам нарезать

Пробовал. Виснет при переходе на уровни 12-13. Проблема не в размере файла, а в общем размере кэша.

Цитата:

Для удобства работы в он-лайн

я так понял, что имелось в виду ОФФ-лайн

messer20878

Цитата:

Делай бакапы

а еще, что делать с кэшем в 25 гиг?

Цитата:

я так понял, что имелось в виду ОФФ-лайн

Вообще то да, но учитывая скорость отдачи гуглом тайлов, в он-лайн тоже намного удобнее с кэшем работать.

rex

Понятно, для путешествий в дикие места пожалуй да. Если страну выкачивать 19 уровнем то гигабайты и будут.


Цитата:

Например, в недавнем путешествии кэш гугля очень помог. GPS трэки накладывались на кэш, а не на примитивную карту,

Цитата:

У SatMap , даже старого кэш на порядок больше, а поддержку треков автор рано или поздно добавит

Цитата:

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

Не понял, в чем же вы накладывали треки без склейки "на кэш" если SatMap еще не умеет?

zporuchik

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

rex
А какой у тебя был выставлен размер внутреннего кэша?

Цитата:

Не понял, в чем же вы накладывали треки без склейки "на кэш" если SatMap еще не умеет?

Google Earth. И кэш был его. Случайно остался в ноуте от просмотра мест во время подготовки к поездке. Но кэш 2 GB это смех.

relictus
42. по умолчанию. Не до него было. Кстати все кэши, кроме 1-9 разбиты по отдельным файлам. До 12 (1-12 в сумме 5 GB) проблем нет. С 13 и выше виснет.

Но проблема не только в зависании, но и в структуре. В старой версии одному адресу соответствовал один тайл, теперь может быть несколько, причем какой возьмет программа зависит от порядка расположения кэша. И я должен постоянно помнить, что и когда качал и таскать эти кэши вверх-вниз. Как опция, вариант создания "вручную" может быть полезен. Недавно например с удивлением обнаружил что островок как который я собирался весной, исчез с карт Гугля. На старых скриншотах есть, а на новых картах нет, только темная воронка в море. Да и отдельный квадрат экспортировать иногда полезно. Но как основная опция жутко неудобно.

rex
Попробуй все же выставить внутренний кэш на 200-300 тайлов. Но видимо, проблема в большом количестве одновременно подключенных кэшей. Когда я продумывал работу с ними, то предполагал, что одновременно будут использоваться (чекнуты) только несколько кэшей, остальные же просто как коллекция, подключаемая в нужный момент.
Но ты пробовал работать со всеми своими тайлами, лежащими в одном файле кэша? Пусть это будет даже 50 гиг, но в одном файле! А насчет свалки не беспокойся, SQLite с этим прекрасно справляется.....

relictus

Цитата:

Но ты пробовал работать со всеми своими тайлами, лежащими в одном файле кэша? Пусть это будет даже 50 гиг, но в одном файле!

Конечно. С него и начал. 25 GB. Картинку при загрузке показывал. При попытке перехода на другой слой или уровень зависал.


Цитата:

А насчет свалки не беспокойся, SQLite с этим прекрасно справляется....

А что, с сотней файлов по 1-5 GB она не справляется? Впрочем базу на отдельные таблицы делят не потому, что она объем не потянет.

rex

Цитата:

А что, с сотней файлов по 1-5 GB она не справляется?

Справляется, но тут уже дело во времени подключения к каждой из баз...

relictus

Цитата:

Справляется, но тут уже дело во времени подключения к каждой из баз...

Старая версия сразу знает в каком индексе какой слой искать и ищет только в нем, никакого перебора. Возможно сделай вы в SQLite такую же структуру как была, она бы файлы по 5-6 GB переваривала бы также легко, как нынешняя по 2. Ну а остальные варианты опционально.

rex
Цитата:

Google Earth. И кэш был его. Случайно остался в ноуте от просмотра мест во время подготовки к поездке. Но кэш 2 GB это смех.

[оффтоп]
зайди в тему GoogleEarth. там в шапке целых 2 метода как обойти это ограничение
[/оффтоп]

Спасибо за новую версию SatMap
Новый кэш значительный шаг вперёд с идеалу - специализированной СУБД для Google maps и им подобных картографических ресурсов.
Что бы там не утверждал rex, а новый кеш гораздо лучше чем старый. Если окажется, что для многих важно разделение по уровням, то для них, может быть, стоит реализовать систему настроек какие уровни в какие файлы кэшей писать, а можно ещё и шире не только уровни, но и выбор какой тип (карта, гибрид, спутник или ландшафт) в какой файл кеша писать. Но лично моё мнение - самый правильный тип разделения кэша - это по регионам (областям, городам, странам), которыми можно обмениваться и/или брать в дорогу только те регионы в которых побываешь. И это полностью реализовано в данном варианте. Ещё раз слава новому кэшу!!!
Смею высказать предположение если relictus реализовал подключение нескольких файлов кешей через связывание баз данных SQLite, то там по умолчанию ограничение не более 10 баз данных, которое можно устранить только перекомпиляцией СУБД. Возможно, с этим ограничение и столкнулся rex.

Новая хотелка:
К такой же универсальности как и современный кэш, желательно привести типы карт, т.е. в настройках программы необходим выбор "слоёв-пирога" какие я хочу видеть на экране и необходимо, чтобы допускалось наложение нескольких слоёв, например: вибираю самый нижний слой (основная подложка) спутниковые снимки, на него накладываю карту с 50% прозрачностью, или накладываю как обычно гибрид с 0% прозрачности (т.к. он и так прозрачный) или накладываю ландшафт с 70% прозрачности. Для примера можно наложить на "карту" слой "спутника" с 90% прозрачности (и мы увидим не только контуры дорог и домов, но и полупрозрачные крыши домов и автомобили на дорогах) Зачатки такой универсальности уже есть в SAS, но не доведены до полной: там только два слоя пирога и для каждого слоя свой список, что высвечивать и полностью отсутствует категория прозрачность. Конечно такая универсальность пока не первоочередная, но в будущем желательна.

rex
Специально для теста сбацал один кэш-файл размеров 21.6 Гб, 1398100 тайлов. Выставил его активным и подключил еще 4 кэша размером от 100 Мб до 1.6 Гб. Koмпьютep: AMD Athlon(tm) 64 Processor 3000+ 1.98 ГГц, 1,00 ГБ OЗУ, winxp sp3. Летает!!! Даже под отладчиком время перерисовки экрана от 70 до 180 миллисекунд (это без использования внутреннего кэша), т.е. практически неразличимо для глаза.
Вывод сам напрашивается - что-то не в порядке с твоей системой или

MiMark
Спасибо за понимание
Насчет хотелки. Систему слоев еще только предстоит реализовать в движке. Есть такое в планах, но не очень близких...

relictus

Цитата:

Специально для теста сбацал один кэш-файл размеров 21.6 Гб

а как сбацать в домашних условиях?

egor23

Цитата:

а как сбацать в домашних условиях?

Да написал прожку небольшую, которая один тайл заносит в кэш для всех слоев уровней 1-10. Можно и другие уровни взять, но там сильно уж большие объемы получаются... Надо? Завтра выложу.

Для анализа возникшей ситуации у rex
Привожу цитату с сайта SQLite (http://sqlite.org/limits.html):

10. Maximum Number Of Attached Databases

The ATTACH statement is an SQLite extension that allows two or more databases to be associated to the same database connection and to operate as if they were a single database. The number of simulataneously attached databases is limited to SQLITE_MAX_ATTACHED which is set to 10 by default. The code generator in SQLite uses bitmaps to keep track of attached databases. That means that the number of attached databases cannot be increased above 30 on a 32-bit machine or 62 on a 64-bit machine.


Из которой следует что присоедениение баз данных (в нашем случае один файл кэша равен одна база данных) ограничено цифрой десять и может быть увеличено перекомпиляцией СУБД до 30, если в исходнике СУБД SQLite присвоить SQLITE_MAX_ATTACHED = 30
Из сказанного подозреваю, что у rex более 10 файлов кэша и когда он пытается работать тайлами находящимися в файлах кэша более 10, то программа виснет.
Выхода три:
1. Оставить всё как есть и считать ограничение на 10 файлов не глюком а фичей;
2. Увеличить до количество до 30;
3. Увеличить количество до бесконечности за счёт не использования ATTACH, а открытия баз данных каждой самой по себе и все алгоритмы переделать на поиск сначала в одной, потом в другой и т.д.
Последний способ может привести к потери производительности.

У меня возникли проблемы с конвектором кеша. Пишет он мне, что SQLite error 14, а затем сообщает, что обработал 0 тайлов. Может нужно было изменить версию тайлов, но пользовался "по умолчанию" 33. конвектор клал в разные папки -- и поближе и подальше от старого кеша -- результат один. Кстати, и после установки 1.4 никаких файлов SQLite создано не было. Кеш пишется в default_cache, на мой взгляд какой-то в этом названии неправильный смысл. Блуду благодарен за подсказку с конвектором.

Пока не разобрался с конвектором судить о скорости работы 1.4 могу лишь виртуапьно -- вроде все нормально, но гугл ее банит по-страшному. За 2 дня отдал не более 20 мгб. А антибановое окошко (тут его уже обозвали CAPTCHA) за все это время появилось только один раз, но введение контрольных цифр от бана не спасло.


А пока ждал версию 1.4 (мой кеш уперся в предельные 1,7 гб на 17 уровне) поискал разные аналоги и очень мне понравился Google Navigator (GN) для КПК. Не всегда же таскать с собой ноут -- на моем FSC Loox помещается карточка в 32 гб, а заряжается он и от солнечной батарейки. GN очень близка по организации с SatMap -- существенный минус невозможность закачать выделенный фрагмент, закачивает в кеш только видимую зону экрана. Т.е надо либо заранее вручную пролистать нужный район (что на 18-20 уровнях близко к мазохизму), либо качать по GPRS в дороге. Существенный плюс -- реализована связь с GPS-приемником, ну и маленький размер КПК. Размер кеша якобы неограничен. Пишется он в два файла imagedata.da и tileinfo.da. Вот и родилась просьба расширить возможность конвертации кеша SatMap в кеш GN. OZI конечно бесспорная классика для навигационных измерений, но автоматического изменения масштаба она не дает.