» SatMap (2)

relictus

Цитата:

satmap.xml

Так я ведь на нулевой папке распаковываю 2.2.0 и сразу меня exe на 2.2.2е Там никакого satmap.xml еще не создано. Зато вылетают все эти ошибки. А вот уже, когда повторно запускаешь, предварительно удавлив satmap.xml и проделав все эти трабные действия -- на кнопке "сохранить" прога виснет намертво и поддается закрытию только через диспетчер задач.

relictus

Цитата:

прога виснет намертво и поддается закрытию только через диспетчер задач.

запускал с отключённым Инетом
виснет намертво

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

Kusain

Цитата:

При попытке скачать слой

Какой слой?
Какой уровень?
какая версия SatMap?
какие координаты? или выложите файл с выделением?

Слой 14,15,16 ,гибрид , версия 2,20 которая последняя , N53°45'42.13"    E79°33'46.76"

Kusain

Цитата:

Слой 14,15,16 ,гибрид , версия 2,20 которая последняя , N53°45'42.13" E79°33'46.76"

вот проверил только гибрид, кэш был пустой, гибрид отображается:


Цитата:

но после скачавания ничего нет

возможно там ничего нет, нет дорог\надписей и т.п., то ничего и не увидите.

и не забывайте заходить в настройки и проверять версии снимком (Настрйоки-Интернет-Проверить версии снимков)

У меня есть предложение по улучшению работы программы. Точнее по хранению информации в кеше.
1) Разрешить программе в режиме использования только кеша брать при отсутствии тайтла в кеше тайтл с более верхнего уровня. Я читал в теме ранее что автор не хочет это делать, но мне кажется, что с учетом нижеследующего это можно всетаки сделать.
2) В тайтлах SAT я нашел большое количество мест, где сам гугол берет вместо более подробного тайтла увеличенный тайтл с предидущео уровня. Обычно это происходит на местах, где не расположенны населенные пункты. С уровня 12-13 и дальше, пока проверял до 16-17 уровней. Если добавить в программу или сделать отдельным приложением (может даже консольным ) опцию по отлову таких мест. Тогда можно будет выделить из массива тайтлов дубликаты и удалить их. Это позволит сильно облегчить кеш (я думаю что даже в несколько раз когда выкаченны большие районы а не только города) а вместе с первым пунктом моего предложения позволит использовать карты так же как и ранее не получая на месте удаленных тайтлов черные пятна. Я смотрел в некоторых местах, там последний тайтл с информацией был на 13 уровне, а потом на 14, 15 и 16 было 84 тайтла просто увеличенные с предидущего. Если их убрать кеш станет легче а если таких тайтлов много то легче значительно.
3) Тайтлы гибрида BOTH содержат очень мало информации когда речь идет о большой площади и большом уровне просмотра. Незначительная часть тайтлов с информацией перемешена с кучей тайтлов пустых и без информации. Но эти нулевые тайтлы весят тоже, хоть и по несколько байт. И они тоже содержаться в кеше. Так не проще заменить в кеше эти тайтлы нулевого размера на указание о существовании этого диапазона? Тоесть просто прописать что тут должны быть тайтлы с N до N+1024 чем занимать это место 219955 байтами информации (я взвесил папку с тайтлами нулевого размера в SASPlanet).

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

egor23

Цитата:

запускал с отключённым Инетом
виснет намертво

Убил кучу времени, но так и не смог воспроизвести ошибку
Можешь записать последовательность своих действий на видео-ролик С НУЛЯ, т.е. с момента запуска проги, предполагая, что версия exe = 2.2.2+ распакована в папку с чистой (ни разу не запущенной!) полной версией 2.2.0?
Или netrebos?

errmac
Почему "тайтлы"? Надо "тайл", от англ tile, а не title

Цитата:

Разрешить программе в режиме использования только кеша брать при отсутствии тайтла в кеше тайтл с более верхнего уровня.

Подобные запросы появляются периодически. Когда-нибудь это реализую...

Цитата:

(я взвесил папку с тайтлами нулевого размера в SASPlanet)

Не понял, какое отношение файловый кэш САС имеет к кэшу SatMap, в котором все тайлы хранятся в одном файле?

relictus

Цитата:

Убил кучу времени, но так и не смог воспроизвести ошибку

1. распаковываем 2.2.0
2. накатывает 2.2.2e
3. отключаемся от Инета (если есть Firewall можно не отключаться)
(проверял с отключённым Инетом + отключён Firewall (на всякий случай))
4. запустили, выставили режим Инет+кэш (речь шла исключительно про эти режимы)
5. или делаем выход, или двигаем "карту" - результат висим.

egor23
Попробуй v2.2.2f на предмет задержек, есть разница с v2.2.2e?

проверил 2.2.2e на Win7 - тоже висит

egor23
Так ты про другую проблему, не ту что у netrebos, писал
Цитата:

запускал с отключённым Инетом
виснет намертво

?

relictus

Цитата:

Попробуй v2.2.2f на предмет задержек, есть разница с v2.2.2e?

задержек вроде нет

Цитата:

виснет намертво

2.2.2f - тоже виснет, но потихому, не грузит CPU

Цитата:

Так ты про другую проблему

проблема с зависанием, скорее всего у нас общая.

Добавлено:

Цитата:

проблема с зависанием, скорее всего у нас общая.

но может проблемы разные

Добавлено:

Цитата:

2.2.2f - тоже виснет, но потихому, не грузит CPU

если Инет отключть во время работы, т.е. тайлы уже загружаются, то SatMap не виснет.
но после перезапуска SatMap (с отключённым Инетом), зависает.

egor23
Вроде пофиксил возможную причину зависа (в твоем случае), попробуй:
v2.2.2g

relictus

Цитата:

Вроде пофиксил возможную причину зависа (в твоем случае), попробуй:
v2.2.2g

вроде не виснит

Цитата:

Попробуй v2.2.2f на предмет задержек

бывают только задержки с началом загрузки тайлов, если поскролить и остановится, то идёт обработка "поставленных в очередь" тайлов, что не очень критично.
Главное что появилась стабильность работы.

egor23

Цитата:

Главное что появилась стабильность работы.

Надеюсь
Теперь бы еще проблему netrebos воспроизвести и пофиксить (если причина точно в проге), и можно релизить... Не поможешь?

relictus

Цитата:

Теперь бы еще проблему netrebos воспроизвести и пофиксить (если причина точно в проге), и можно релизить... Не поможешь?

смотрел, у меня не падает

egor23

Цитата:

смотрел, у меня не падает

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

relictus,

Цитата:

Почему "тайтлы"? Надо "тайл", от англ tile, а не title

Упс. Ошибка вышла. Немного невнимательно написал термин.

Цитата:

Не понял, какое отношение файловый кэш САС имеет к кэшу SatMap, в котором все тайлы хранятся в одном файле?

Файлы кеша существуют в виде набора файлов: гибрид в .png и спутник в .jpg. Программа SASPlanet хранит это в виде раздельных файлов, SATMap в виде контейнера SQLite но смысл в том, что и тот и другой хранит их полностью, даже если они нулевого размера. По этому для примера в своем посте я написал сколько весит 1024 файла (1 папка в пустом районе) с нулевым BOTH кешем из планеты. Это только пример. Я учел, что реальный размер файлов кеша планеты не совпадает с размером занимаемым на диске из за размера сектора в ntfs, так вот это именно реальный размер, на диске там 4мб почти это занимает. Когда кеш храниться в контейнере SQLite то насколько я понял там храняться те-же самые тайлы но в базе а не в файлах и по этому проблемы с разницей в размере на диске и реальном у файлов нет. Но всеравно есть проблема того, что файл .png весит не 0 байт а примерно 150-200 байт и кроме того нужно хранить саму информацию о существовании его. Это не много когда файл один, но если взять например у меня кеш 17 уровня на 11.4 миллиона тайлов и там бОльшая часть их имеет нулевой размер то получается много записей о информации которая в принцепе и не нужна. Вот я и предлагаю заменить в кеше SAPMap записи о этих нулевых тайлах на запись о существовании диапазонов их. Этим можно сократить общий размер кеша файлов.
Так же хотелось услышать ваше мнение по второму пункту моего предложения. Возможно я что то непонятно написал, тогда скажите что именно и я попробую переформулировать это описание. Мне кажется что это предложение тоже сможет сильно уменьшить размеры файла кеша без потери содержательной части.

errmac

Цитата:

и тот и другой хранит их полностью, даже если они нулевого размера.

SatMap не хранит тайлы нулевого (?!) размера - хранится только инфа об отсутствии такого тайла на сервере.

Цитата:

Это не много когда файл один, но если взять например у меня кеш 17 уровня на 11.4 миллиона тайлов и там бОльшая часть их имеет нулевой размер то получается много записей о информации которая в принцепе и не нужна.

Как это не нужна? Это сейчас там нет тайлов, а если в следующее обновление гугл покроет и эту область?

Цитата:

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

Но потребуется вводить новую таблицу с записями о таких диапазонах + перед выборкой тайла, проверять этот дипазон + как-то еще и определять эти самые диапазоны! ИМХО, овчинка выделки не стоит...


Цитата:

хотелось услышать ваше мнение по второму пункту моего предложения.

Цитата:

Если добавить в программу или сделать отдельным приложением (может даже консольным ) опцию по отлову таких мест.

Не представляю, как это возможно сделать.

Цитата:

Это позволит сильно облегчить кеш

Но одновременно увеличит время для генерации таких тайлов в real-time, что приведет к снижению производительности программы...
И опять же... хранение инфы в БД о таких областях, проверка ее и пр.

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

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

Цитата:

SatMap не хранит тайлы нулевого (?!) размера - хранится только инфа об отсутствии такого тайла на сервере.

Цитата:

Как это не нужна? Это сейчас там нет тайлов, а если в следующее обновление гугл покроет и эту область?

Видимо я не до конца понят. Вот есть поле 10*10км, и дорога 10 км через него. Дорога это лента тайлов с информацией. А все поле покрыто тайлами содержащими информацию только о том что там ничего нет. И ждать пока там застройка какая то будет можно лет 100 если не меньше
Я возможно не понимаю до конца как хранит SATMap кеш у себя, но когда я делаю экспорт из кеша планеты обьемом например 100 мб (файлов а не на диске) то в SATMap я получаю файл размером примерно 110-120мб. Исходя из этого я делаю вывод что в скуль переносяться все атйлы + добавляется какое то количество дополнителньой информации. При этом, если опять таки имеем город окруженный кучей полей то там реальной информации процентов 10, не более. И реально если упорядочить эту информацию не по-тайлово а с использованием указания о существовании диапазона тайлов без информации (нулевого размера) то это уменьшит вес кеша. Такая замена набора одинакового диапазона информации на указание о таком диапазоне по моему является одной из основ архивации и сжатия. Я просто предлагаю применить его в контексте работы программы. Просто конкретный пример:
\BOTH\z17\40\x40960\20\ 462 подряд с номера y21042.png до номера y21503.png идут без информации, нулевые, и весят 103758 байт. +в кеше SATMap я так понимаю будет еще 10-20% служебной информации, итого 120кб места.
Если заменить их на запись о том что эти 462 тайла в этотй папке
если заменить на указание что все тайлы в этой папке из диапазона номеров указанных ничего являются нулевыми. Это уместиться ну максимум в 1кб. Получим экономию в 99% на примере конкретно этой папки и ее аналога в стуктуре SATMap. А если взять миллион таких файлов?
Опять таки, дя городской черты, дорог и населенных пунктов такое будет неприменимо, но осальные площади можно будет зарезать по размеру очень значительно.
В такой ситуации по вашему овчинка стоит выделки или нет? N54E42-N48E51 11-17 уровня содежит 3.8 миллиона тайлов гибрида, 895мб в виде кеша SAS.Планета и около 1гб в виде кеша SATMap (у меня просто конкретно эти 2 примера есть сейчас и могу конкретно их сравнить). При этом на всю территорию приходиться 3 крупных города, 2 средних и кучка небольших. А остальное поля. И реальной информации без нулевых тайлов там 80-100мб всего, осатльное мусор. на 90% сократиться кеш с этой областью по размеру и не потеряется информативность.

Цитата:

Не представляю, как это возможно сделать.

Ну на вскидку просто: береться тайл 12 уровня x:y и 4 тайла 13 уровня находящихся под ним. Собираются в 1 тайл и уменьшаются в размере до 256*256 пикселей. И сравниваются. Если разници нет то удаляются. Потом берется 16 тайлов еще на 1 уровень ниже и так далее. Ресурсов конечно будет потребляться очень много, но я и предлагаю выделить это в отдельную программу чтоб закинул ее на достаточно свободную машину, поставил и забыл про нее хоть на неделю хоть на месяц. На выходе получится значительно меньший по размеру кеш-файл без потери реального качества.


Цитата:

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

У меня дома сейчас примерно 4-5ТБ дисксплеша. Считая что часть идет рейдом и дисков там на бОльший объем. В том числе на ноутбуке где стоит SATMap почти терробайт. Диапазон который интересует меня в том виде как сейчас есть займет ~100гб на 18 уровне или ~500 гб на 19. Большего реального приближения на этой территории нет просто. И я хочу учесть, что это например всего-навсего 200-300км вокруг моего дома территория, тоесть те места куда я реально сядя в машину доеду с этим ноутом и где мне реально может понадобиться карта. Если в такой ситуации уменьшить размер кеша оптимизировав его до 50 гигов на 18 уровне и 250 гигов на 19 то как по вашему, будет стоить овчинка выделки? Или винты у меня маленькие просто и стоит в ноут воткнуть пару терробайтников из за этого?

ZergAnaliZer
Сейчас нет такого, но когда-нибудь сделаю...

errmac
У Вас только гибридный слой имеется? или всё же вместе со спутниковым?

Цитата:

планеты обьемом например 100 мб (файлов а не на диске) то в SATMap я получаю файл размером примерно 110-120мб.

Цитата:

В такой ситуации по вашему овчинка стоит выделки или нет? N54E42-N48E51 11-17 уровня содежит 3.8 миллиона тайлов гибрида, 895мб в виде кеша SAS.Планета и около 1гб в виде кеша SATMap (у меня просто конкретно эти 2 примера есть сейчас и могу конкретно их сравнить).

0. При сравнении кэшей SAS.Планета и SATMap, нужно ещё указывать реальный размер кэша SAS.Планета занимаемый на диске, иначе сравнение будет не корректным, хотя даже указав размер на диске сравнение будет не корректным, т.к. файловая система - база данных и в ней ещё есть потери места.
1. Укажите сколько одинаковых тайлов (по содержимому) и их размер, по этим областям:
Для автоматизации подайдут программки поиска дубликатов, например:
http://www.dupkiller.net/index_ru.html
в настройках:
сравнивать размер
Сравнивать содержимое (быстрый режим отключить)

одинаковые тайлы
115 тайлов по 191байт
и время сканирования укажите

egor23

Цитата:

У Вас только гибридный слой имеется? или всё же вместе со спутниковым?

Гибрид и спутник. Просто я в первом посте разделил предложение на 3 части: про уровни, про boht и про sat и получилось что как то больше стали про boht говорить.

Цитата:

При сравнении кэшей SAS.Планета и SATMap, нужно ещё указывать реальный размер кэша SAS.Планета занимаемый на диске

Достаточно изменить размер кластера с 4кб до 512б и размер на диске станет практически равен размеру файлов. Либо юзать файловые контейнеры с таким размером класера.

Цитата:

Укажите сколько одинаковых тайлов (по содержимому) и их размер, по этим областям

В принцепе да, я прогоню дупкиллером, сейчас есть возможность на 17 уровне both проверить на 2.8 миллионах файлов. Результат выложу тут.

relictus

Цитата:

netrebos, ау...

Извини, весь день болтался в самолете...где-то в твоих краях Ошибка повторяется и на
Цитата:

v2.2.2f

. Потому снял фильм и отправил тебе в личку. Воспроизводил ошибку на домашнем компе без реального прокси. Если хочешь, завтра, ближе к вечеру, могу переснять кино на конторском компе с прокси.



Добавлено:
errmac

Цитата:

А остальное поля. И реальной информации без нулевых тайлов там 80-100мб всего, осатльное мусор. на 90% сократиться кеш с этой областью по размеру и не потеряется информативность.

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

netrebos
речь идет о файлах BOTH кеша нулевого размера. Или забивается пространство по которому нет никакой информации вообще, тоесть поля, леса, реки и так далее. Если там есть дорога, какая то информация, хоть 1 пиксель кроме прозрачного фона то этот файл станет не нулевым кешем уже. Размер нулевого кеша 191 байт. Тоесть убрав его не потеряется информации нисколько совершенно.
Кстати, я тоже использую эту программу дял тех мест где обычные навигаторы с векторными картами пасуют и у них тут "пустое место" хотя на деле замечательный пляж или полянка для шашлыка

egor23
отчет готов. только вместо дупкиллера использовал тотал-коммандер для поиска всех файлов размером, равным 191 байту в заданной папке. Это и быстрее и не нужно ставить еще софт и разбираться с ним.
Итак:

Цитата:

Кеш BOTH 17 уровня по координатам N54E42-N48E51

Всего файлов: 2853600
Всего размер: 629480538b

Файлов нулевого кеша (191 байт/тайл): 2675005 (93%)
Размер файлов нулевого кеша: 510925955b (81%)

Файлов полезного кеша: 178595 (7%)
Размер полезного кеша: 118554583b (19%)

Размер указан самих файлов а не занимаемого ими места на диске, на диске исходная папка занимает ~10гб при размере кластера 4кб
Время обработки папки тотал-коммандером 2 часа 45 минут. Кстати распаковывалась она перед этим полтора часа из rar.

так что обсуждаемый вопрос это не экономия небольшого количества места а уменьшение места, занимаемым кешем гибрида на 70-80%.
+ так еще и не обсуждался толком вопрос с кешем снимков, что то мне подсказывает что там цифры будут подобного порядка и в итоке кеш с картами без потери информации можно ужать в 3-4 раза по сравнению с тем, что есть сейчас.

errmac

Цитата:

когда я делаю экспорт из кеша планеты обьемом например 100 мб (файлов а не на диске) то в SATMap я получаю файл размером примерно 110-120мб. Исходя из этого я делаю вывод что в скуль переносяться все атйлы + добавляется какое то количество дополнителньой информации.

Вывод не совсем верен. Для хранения информация SQLite использует виртуальную фаловую систему (в одном файле), в которой есть то же подобие размера кластера, как в обычной ФС - см. доки на тему pragma page_size=. Т.о. инфа в кэше хранится не последовательной запись тайлов один сразу за другим, а разбита по страницам. Отсюда и разница в размерах между файловым кэшем САС и БД SatMap.
Так вот, мною подобран оптимальный размер страницы БД, при которой реализуется максимальное быстродействие при взаимодействии с фалом кэша. Ничего менять в этой части я не буду.


Цитата:

Просто конкретный пример:
\BOTH\z17\40\x40960\20\ 462 подряд с номера y21042.png до номера y21503.png идут без информации, нулевые, и весят 103758 байт. +в кеше SATMap я так понимаю будет еще 10-20% служебной информации, итого 120кб места.
Если заменить их на запись о том что эти 462 тайла в этотй папке
если заменить на указание что все тайлы в этой папке из диапазона номеров указанных ничего являются нулевыми. Это уместиться ну максимум в 1кб. Получим экономию в 99% на примере конкретно этой папки и ее аналога в стуктуре SATMap. А если взять миллион таких файлов?

Вопрос: а зачем вообще хранить (и скачивать) эти "нулевые" тайлы??? Если же они уже есть в кэше, ну удалите их оттуда - вот вам и экономия будет! И ничего изобретать не надо...

netrebos

Цитата:

Если хочешь, завтра, ближе к вечеру, могу переснять кино на конторском компе с прокси.

Не надо, мне достаточно и того

errmac

Цитата:

Достаточно изменить размер кластера с 4кб до 512б и размер на диске станет практически равен размеру файлов. Либо юзать файловые контейнеры с таким размером класера.

кластер 512Б для кэша SAS.Планета - подразумевался
Потери:
1. Потери на кластерах, напрмиер 512-191=321Б (данные потери легко уивдеть в свойстве файлов)
2. Потери в NTFS: размер одной записи в MFT = 1кБ (1024Б), т.е. на любом файле теряестя 1кБ + ещё некоторые потери есть, но MFT - основная потеря.
(увидеть эти потери можно например в 7-zip зайдя на диск \\.\C:\ папка [SYSTEM])

netrebos
Мда.. ты нарвался на very rare bug, который жил еще с давних версий
Попробуй v2.2.2j - без просмотра покадрово твоего видео я бы его не пофиксил....