» SatMap

netrebos
Попробуй разместить импортируемый и экспортирующий кэши на разных физических дисках.
USB не помеха, у меня оба кэша на разных USB дисках.

Цитата:

egor23
full cache SatMap level 1-10 март 2009 3ГБ

Ни один RAR не качается.

Добавлено:
Сори, все качается но не из Мозилы

Я тут сетовал на тормоза satmap, мне высказали предположение, что это результат конвертирования кэша программой convertor и предложили экспортировать кэш в формат gmv, а потом обратно. Времени не было совсем, поэтому занялся этим только сейчас. Выяснилось, экспорт идёт не изо всех подключенных кэшей, а только из первого по списку. Поочерёдно подключая кэши по-одному, экспортировал всё. Создал новый пустой кэш, подключил только его, пытаюсь импортировать в него, не происходит ничего. Это глюк, или я что-то не так делаю?
И в 1.4.1.27 и в 1.4.3.30 одинаково.
Кстати карта наложения, как я понял, тоже строится только по первому из подключенных кэшей. Ещё, если несколько раз выбирать один и тот же уровень для построения карты, он будет накладываться каждый раз до полной черноты. Хорошо бы в этот список добавить чекбоксы.

WAYSHM
Хостинг egor23 выбрал суперский. Огромные файлы отдаются через ReGet с докачкой со скоростью полтора мегабита в один поток!

rex
А в один кеш сразу несколькими мульти пытался? Или это у меня только такая чехорда получается, как вчера писал?

netrebos

Цитата:

А в один кеш сразу несколькими мульти пытался?

Нет. Для просмотра естественно все кэши из одной общей папки, а закачка в свою.
Иначе такая фрагментация базы данных будет что без экспорта-импорта на разберешься.
Да и не только во фрагментации дело. Это ведь по сути несколько не взаимосвязанных программ работают. Одно дело смотреть всем сразу в одном кэше, другое дело писать в него. Тем более как раз при просмотре конфликта не будет, так как во-первых ты не двигаешь одновременно несколько окон сразу, а во вторых relictus ввел внутренний кэш в памяти как раз для вывода на экран, поэтому конкурирующих обращений и зависаний практически нет, хотя прорисовка при шести окнах на слабом компе и тяжелее идет. Но в любом случае просмотр и есть просмотр, главное чтобы общий кэш нигде первым не стоял, иначе запороть в момент.
Чтобы писать все без проблем и конфликтов в один кэш нужна одна программа. Кроме того желателен общий для всех потоков кэш в оперативке, чтобы хоть как-то уменьшить фрагментацию базы + возможно, как в Оракле сразу, заранее, участки в файле кэша для квадратов уровня выделять.
relictus понятно пока всего этого не делал, так не было понятно было возможна ли закачка в несколько потоков вообще. Теперь, после удачных экспериментов, наверное думать будет. Только надо как-то заблокировать возможность многопоточной закачки с одного участка, чтобы Гугль не озверел.

ic1496

Цитата:

Вот только одного момента я не понял -- у меня 4 слоя - спутник, гибрид, карта, ландшафт. Заполненность какого слоя видно?

Текущего, т.е. того, что виден во вьювере.

Trilobit69

Цитата:

Хорошо бы в этот список добавить чекбоксы.

Добавлю, об этом писал выше.


Цитата:

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

Сейчас - да. В следующей версии сделаю чтоб из всех подключенных.

relictus
А есть ли резервы для ускорения работы с кешем, кроме как наращивать мощность процессора и опреативной памяти? На мой взгляд даже функция удаления еле тащится. Я знаю, что в моем кэше не более 500 мб эпизодически закаченных тайлов 18-19 уровня. На 2 уровне выделил всю землю указываю удалить 18-19 уровень и все слои. Так программа удаляет их уже 4 часа и конца этому не видно. Кнопкой делейт удалить быстрее. Речь идет о 2гб ОЗУ 630 мгц и процессоре 900 Мгц. Не самые медлительные возможности.

relictus
А импорт из кэша GMV вернёшь?

netrebos

Цитата:

А есть ли резервы для ускорения работы с кешем

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

Trilobit69

Цитата:

А импорт из кэша GMV вернёшь?

А он разве не работает? Сейчас проверил, все импортируется. Посмотри, правильно ли указан путь к кэшу GMV? "пытаюсь импортировать в него, не происходит ничего" - ну как ничего, что-то же прога пишет?

relictus
Я скинул в личку некоторые показания диспетчера задач при работе кэша в разных условиях.

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

relictus
Большое спасибо. Но я пока не смог ее попробовать. На некоторое время вообще притормозил закачки. От жадности нахватал столько разрозненых кусков, что теперь уперся в проблему упорядочения всего этого богатства в какой-то логичный кэш. Пока я вижу только один плюс версии мульти (Это огромный плюс, который к сожалению пока ничего мне не дает) -- если мы начинаем формировать базу с нуля и заранее планируем структуру архива. Например, есть заданная площадь -- один архив сразу отводится под 1-16 уровень, 2-й -- под 17--18 и 3-й - 19. Такое разделение, например по спутнику, дает примерно равные по объемам архивы.

Но вот тут-то и встает самая главная проблема при наличии разрозненых кэшей. Время закачки с гугла примерно равно времени обработки (перекидывания) тайлов между кешами в т.ч и между Satmap в satmap. Обрезание кеша в заданных границах через функцию удаление так же очень времяемкое занятие. До 15 -- 16 уровня это терпимо даже с большой площадью. А вот уже на 17-18-19 уровнях процесс растягивается на сутки, а то и несколько.

Что я имею ввиду? Версия мульти дает эффект ускорения работы -- так как поток информации расширяется за счет паралельных закачек. Но эти закачки надо еще объединить и версия мульти в таком же параллельном режиме этого делать не умеет (Точнее умеет делать только при экспорте в сас. Думаю, это стало возможно из-за многофайловой структуры архива САС). Т.е. каждый кусок закаченный мульти в режиме паралленой закачки должен уже ПОСЛЕДОВАТЕЛЬНО быть передан в выбранную структуру рабочего архива по конкретной площади. Весь выигрыш по времени от мульти закачки потерян (я не рассматриваю вариант если Гугль завтра исчезнет полностью). Т.е. -- нужно очень серьезное програмное ускорение работы с кешем без изменения возможностей железа. Первый ответ, который напрашивается -- забыть о разрозненых кусках и провести закачку заново -- уже под выбранную структуру кэша. Честно говоря -- мне не нравится такой ответ.

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

Вот некоторые простые расчеты для для действующего ограничения смотреть только на 6 уровней вперед для 17" монитора. (Я завидую вам обладатели 22" мониторов, но не сильно, т.к. не занимаюсь обработкой графики и видео каждый день)

Просмотр с 10 на 16 слой дает информацию по территории 50,2 тыс кв клм (стороны квадрата примерно 279х180 клм)
С 11 на 17 -- 12,7 тыс кв клм (141х90 клм)
С 12 на 18 -- 3,2 тыс кв клм (72х44,6 клм)
С 13 на 19 -- 707,8 кв клм (36,1х22,4 клм)

Т.е, например, при задании построить архив на 110,9 тыс кв клм реальной площади, на прямоугольном экране и с функциией выделения по квадрату мне приходится обрабатывать и просматривать информацию примерно по 750 тыс кв клм. (в моем случае большая часть площади океан). Т.е на 13 слое дающем инофрмацию только по 707,8 кв клм на 19 слое, я не в состоянии получить целостной информации по все площади. А просматривать такие объемы по кусочкам -- тот еще геморрой. Т.е мне очень важно, что бы я мог видеть 19й слой хотя бы с 10 уровня, что бы отлавливать крупные прорехи и подчищать их уже с 13-14 слоев.

relictus

Цитата:

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

Наверное должно, но не выскакивает.

Теперь заметки по поводу попыток (не очень удачных) просмотра закачанного.

- Многослойный просмотр до включения чек-боксов лучше пока вообще отключить. Хоть один слой можно будет нормально увидеть.
- При переходе на другой уровень выделение должно автоматтчески отключаться, иначе зависание гарантированно.
- Разница уровней должна быть не менее 8-ми, например, чтобы с 10-го смотреть 18-й.
Иначе крайне неудобно.

netrebos

Цитата:

нужно очень серьезное програмное ускорение работы с кешем

Как? Вот так вот взять и переплюнуть разработчиков движка SQLite и ускорить его работу во много раз? У меня есть кое-какие идеи, но не думаю, что они ускорят работу с кэшем в разы. Попробовать их, к сожалению, в ближайшее время не смогу


Цитата:

Т.е мне очень важно, что бы я мог видеть 19й слой хотя бы с 10 уровня

И еще раз "как"? +9 уровень наложения выражается в субпиксельном размере - как его отображать-то? +8 = 1х1 пиксель, это можно добавить, но не более.

rex

Цитата:

Наверное должно, но не выскакивает.

Понял. Значит еще чуть обновлю код, дам знать когда можно будет скачать.


Цитата:

Разница уровней должна быть не менее 8-ми

Да сделаю, но имей в виду, что процесс формирования такой схемы будет занимать значительное время, т.к. анализ, к примеру, 1764000 тайлов (+8 уровень наложения, разрешение 1680х1050) - дело не быстрое.

relictus
Расписываю подробно по шагам что делаю:
Создаю пустой файл
Добавляю его как кэш, он располагается последним в списке
Снимаю галочки у вышестоящих файлов кэша, ставлю галочку у нового
В каталогах указываю расположение кэша GoogleMV - D:\gmv
Выбираю в инструментарии импорт из кэша GoogleMV
В появившемся окне выбираю все уровни, все слои, заменять старые (можно выбрать и другой пункт - всё равно), жму ОК
Окно пропадает, ничего не происходит, никаких эффектов, никаких сообщений



Скачал по-новой полный комплект, а не только exe, как делал раньше, заработало!

relictus

Цитата:

+8 = 1х1 пиксель, это можно добавить, но не более.

Цитата:

Да сделаю, но имей в виду, что процесс формирования такой схемы будет занимать значительное время, т.к. анализ, к примеру, 1764000 тайлов (+8 уровень наложения, разрешение 1680х1050) - дело не быстрое.

В метрической системе это дает возможность глянуть с 11 на 19 слой на площади 12,8 тыс кв клм. на 17" мониторе.

С 10 на 18 -- 50,8 тыс кв клм
С 9 на 17 -- 199 тыс кв клм.

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


Цитата:

Вот так вот взять и переплюнуть разработчиков движка SQLite и ускорить его работу во много раз

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


Цитата:

У меня есть кое-какие идеи,

Даже если это произойдет и не в этом сезоне -- делать надо. Скорость обработки кэша повлияет на расширение универсальных возможностей программы. Кстати, чуток увеличить скорость обработки кеша можно и не вмешиваясь во внутренности SQLite. Например, дополнив инструментарий по импорту\экспорту кэша функцией выделения. Тогда будут забираться только тайлы к необходимому для построения кэша квадрату, а не все оказавшиеся на выбранном слое, которые затем надо обрезать функцией "удалить".






Добавлено:
relictus
И еще одно. Скорее это вопрос, чем предложение. А возможность сразу укладывать в один кеш параллельные закачки варианта мульти существуют или это тоже ограничение SQLite, которое не обойти? Если бы такая возможность была, можно было бы не связываться с обработкой, а просто перекачать требуемый кусок с помощью мульти и не париться.

Trilobit69

Цитата:

В каталогах указываю расположение кэша GoogleMV - D:\gmv

Кэш GMV должен быть в папке "Cache" (дефолтные настройки проги), поэтому ничего и не происходило...

netrebos

Цитата:

Очень бы хотелось, что бы это произошло по-быстрей.

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


Цитата:

Хотя не понятно, почему функция удалить или экспортировать кэш грузит процессор гораздо сильнее, чем функция записать в нем тайлы из гугля? Действия то одного порядка.

Чего уж тут непонятного? При удалении/экспорте/импорте сколько тайлов обрабатывается в секунду? А сколько при закачке с гугля? Как думаете, есть разница? Отсюда и нагрузка на проц.


Цитата:

А возможность сразу укладывать в один кеш параллельные закачки варианта мульти существуют или это тоже ограничение SQLite, которое не обойти?

Есть такая возможность у SQLite, но нет у меня. По-крайней мере, сейчас. Придется переделывать систему записи в кэш. И это значительно замедлит в него запись, т.к. сейчас запись идет в режиме эксклюзивной транзакции с блокированием БД на запись из других потоков.

relictus

Цитата:

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

Ну что тут ответить? -- деньги тоже элемент прогресса. Вот, например, ребята (http://www.pdafun.net/) , которые сделали аналог satmap для КПК на коммерческой основе и как-то с гуглем об этом договорились. Но их существенный минус -- отсутствие версии для ПС. Жаль, конечно если и Satmap уйдет из бесплатного интернета, но я, например, готов был бы выложить сотню, полторы, за готовый навигационный комплекс на двух девайсах. (Хотя именно отсутствие связи с ПС заставило меня пожадничать $59 -- качать с гугля по КПК еще то извращение). Пусть уважаемое собрание этого сайта не кидает в меня камни -- я не пытаюсь ни флеймить, ни делать кому-то рекламу.


Цитата:

Чего уж тут непонятного? При удалении/экспорте/импорте сколько тайлов обрабатывается в секунду? А сколько при закачке с гугля?

У меня сложилось ощущение, что на перекачку тайлов из одного кэша в другой требуется столько же времени сколько и на закачку с гугля того же объема. Почему при удалении/экспорте/импорте программе требуется больше времени чем на запись того же количества тайлов? Может проблема в том, что при записи обрабатываются реальные тайлы, а при удалении/экспорте/импорте программа пытается удалить\экспортировать\импортировать того, чего нет (незакаченные тайлы).



Добавлено:
relictus

Цитата:

Есть такая возможность у SQLite, но нет у меня. По-крайней мере, сейчас. Придется переделывать систему записи в кэш. И это значительно замедлит в него запись, т.к. сейчас запись идет в режиме эксклюзивной транзакции с блокированием БД на запись из других потоков.

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

netrebos

Цитата:

Почему при удалении/экспорте/импорте программе требуется больше времени чем на запись того же количества тайлов?

импорт\экспорт вроде идёт нормально.
скопировать\удалить идёт медленно, т.к. обрабатываются все тайлы в выделенной области.

Рекомендации импорт\экспорт:
размещать кэши на разных физ.дисках,
если есть возможность - загонять кэш в оперативную память или на RAM-drive,
тогда процесс будет идти быстрее.

relictus

Цитата:

Да сделаю, но имей в виду, что процесс формирования такой схемы будет занимать значительное время, т.к. анализ, к примеру, 1764000 тайлов (+8 уровень наложения, разрешение 1680х1050) - дело не быстрое.

Да я знаю, проверял на SAS. Поэтому стоит оставить для проверки только один слой. Но никто не мешает юзверю использовать меньшую разницу. Если 8-й уровень наложения больше шестого в 16 раз, то 7-го всего в 4-е . Разница в 8 уровней имеет смысл только для городов с уровнями 19-21 и для мониторов с расширением 1024х768. Для широкоэкранных вполне хватит и x7, но не у всех они уже есть. Большинство ноутов пока имеют самые заурядные 1280x800, редкие 1680x1050, а 1920 x 1200 так вообще только у некоторых за 2000 евро в не самой сильной комплектации.

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

relictus
импорт\экспорт
не хватает отображении информации какой уровень\слой обрабатывается
также нет возможности прерывания процесса.

Добавлено:
relictus

Цитата:

+9 уровень наложения выражается в субпиксельном размере - как его отображать-то?

+9, +10 и т.п.
или отмечать весь пиксель как отсутствующий, или вводить оттенки\цвета для "неполностью заполненных пикселей".

egor23

Цитата:

импорт\экспорт вроде идёт нормально.
скопировать\удалить идёт медленно, т.к. обрабатываются все тайлы в выделенной области.

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

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

Про разные физические диски согласен. Ох уж мне эти объемы.



Цитата:

не хватает отображении информации какой уровень\слой обрабатывается
также нет возможности прерывания процесса.

присоединяюсь

netrebos

Цитата:

Чего удалять программе, если туда в реальности не был записан ни один тайл?

Цитата:

т.к. обрабатываются все тайлы в выделенной области.

как понимаете, что есть наличие тайла, что его там нет, на скорости работы никак не скажится.

netrebos

Цитата:

Жаль, конечно если и Satmap уйдет из бесплатного интернета

Не уйдет.


Цитата:

Вопрос в том насколько сильно упадет эта скорость?

Значительно! Я потому и не трогаю аспект мультиюзерного доступа к кэшу.

rex

Цитата:

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

А куда ее запихнуть эту кнопку?

egor23

Цитата:

импорт\экспорт
не хватает отображении информации какой уровень\слой обрабатывается
также нет возможности прерывания процесса.

Могу сделать, но процесс чуть замедлится, т.к. надо будет пропускать очередь сообщений винды для отслеживания клика по кнопке stop.
И вообще, что-то прога превращается в комбайн по экспорту-импорту, мне это не нравится, она не для этого предназначена!

netrebos

Цитата:

Чего удалять программе, если туда в реальности не был записан ни один тайл?

Правильно ответил egor23

Цитата:

как понимаете, что есть наличие тайла, что его там нет, на скорости работы никак не скажится.

Т.к. проверяются ВСЕ тайлы.

relictus

Цитата:

И вообще, что-то прога превращается в комбайн по экспорту-импорту, мне это не нравится, она не для этого предназначена!

Есть такое слегка. Это объясняется ее эволюцией. Пока наиболее эффективная часть программы -- мульти пылесос из гугля. А вот с другими функциями таких ярких изменений не произошло. (Извиняюсь, забыл функцию построения заполняемости слоя После перехода на +8 и добавления функции обнавления информации о отсутствующих тайлах на гугуле очень хороший получится инструмент). А функция импорт экспорт тесно связана и с заявленной функцией 1 файл = 1 кэш. Разведение кэша по нужным файлам в программе выполняется через экспорт импорт. А так пока нет контакта с другими ресурсами, кроме гугля. Нет и навигационного блока. Вот мы и обсуждаем то что уже есть. Мульти-пылесос работает-то исправно, а клеить в ОЗИ все вроде давно научились. Тут вопросов не возникает.

Обновил версию мульти, ссылка прежняя.
rex
попробуй, как теперь с окном каптчи?
netrebos
Модифицировал код удаления выделенной области. На моем тестовом кэше процесс ускорился в 108 раз! Но есть и минус - кнопка СТОП во время удаления теперь не работает. За скорость приходится платить....

relictus

Цитата:

А куда ее запихнуть эту кнопку?

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


Цитата:

Я потому и не трогаю аспект мультиюзерного доступа к кэшу.

Если введете учет всех указанных кэшей при формировании списка тайлов для закачки и импорта-экспорта, то десять кэшей-приемников вообще не проблема. Раз в году их объединять вполне достаточно, да и то не обязательно.

rex

Цитата:

Если введете учет всех указанных кэшей

Не понял про учет, поясни.

relictus

Цитата:

Обновил версию мульти, ссылка прежняя.
rex
попробуй, как теперь с окном каптчи?
netrebos
Модифицировал код удаления выделенной области. На моем тестовом кэше процесс ускорился в 108 раз! Но есть и минус - кнопка СТОП во время удаления теперь не работает. За скорость приходится платить....

Чего-то не понял. в мульти режиме варианте файл SatMapGPS.exe, взятый по ссылки и определившийся как измененый 20 марта в 15:22:53, вообще не открылся.