» SatMap (2)

relictus

Цитата:

Не могу вспомнить, о чем это?

это о наложении, и о том что отрисовка идёт быстро, а тормозят процесс дисковые операции, скорее всего по каждому тайлу идёт отдельный запрос, вопрос - зачем это так?
http://forum.ru-board.com/topic.cgi?forum=5&topic=30026#8

Добавлено:
relictus
SRTM1 планируется добавить поддержку?
ftp://e0srp01u.ecs.nasa.gov/srtm/version2/SRTM1/

relictus

Цитата:

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

Скинул на мыло.

relictus
поставил я эту тулзу, и что я вижу

Код:
Произошла следующая ошибка:

* Доступ к кэшу запрещен

Извините, Вы не можете запросить:

http://mt1.google.com/mt/v=w2t.92&hl=ru&x=2743&y=299&z=12&s=

из этого кэша до тех пор, пока не пройдете аутентификацию.

egor23

Цитата:

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

А не так! В языке SQL есть такой оператор как SELECT, с его помощью я за РАЗ выбираю все необходимые мне тайлы. Если подключенных кэшей больше, то и раз больше. Тут оптимизировать нечего, а вот с графикой еще можно...


Цитата:

SRTM1 планируется добавить поддержку?

А зачем? Эти данные только для пиндосии.

tolyn77

Цитата:

так что я так думаю что что то с прогой не так

С прогой все так, сказали же уже, что все работает с проксей. Может ты что не то вводишь? Браузер через проксю ходит?

relictus

Цитата:

А не так! В языке SQL есть такой оператор как SELECT, с его помощью я за РАЗ выбираю все необходимые мне тайлы. Если подключенных кэшей больше, то и раз больше. Тут оптимизировать нечего, а вот с графикой еще можно...

повторю вопрос (хотелось бы понять почему так)

Цитата:

relictus
наложение

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

пример:
18 уровень спутник Москва (~120000 тайлов)
наложение 18-й уровень на 10-й
Кнопочка i - для подсчёта тратится всего 3 сек (~320 дисковых операций чтения)
Наложение - тратится 9мин 50сек (~175000 дисковых операций чтения)
вот LOG File Monitor:
http://download.sysinternals.com/Files/Filemon.zip
Filemon_i_3sec.7z
Filemon_+8 (10s_18s)_9m_50sec.7z

повторюсь - когда SatMap получает данные быстро - слой наложения строится мгновенно.

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

PS: я обычный пользователь - не программер, тонкостей всяких не знаю.

relictus
вообще то уже отвечал!!! ходит браузер на ура
может что с авторизацией не то имя пользователя и пароль для прокси сервера может не используются?
PS у меня есть компьютер который может ходить через прокси сервер и на прямую, так я на нем и тестирую работу,
если идти через прокси сервер то браузер показывает картинки прога не показывает,
если идти на прямую то браузер и прога показывает картинки

egor23

Цитата:

повторю вопрос (хотелось бы понять почему так)

Вот ты дотошный!
"Кнопочка i - для подсчёта тратится всего 3 сек" - элементарно быстрая операция, подсчет кол-ва файлов по индексу.
"Наложение - тратится 9мин 50сек" - (у меня, кстати, около 20 сек) - выборка всех тайлов видимых на экране, потом цикл по выборке, дабы считать координаты каждого тайла и отрисовка его на схеме.

Цитата:

я обычный пользователь - не программер, тонкостей всяких не знаю.

Вот и как тебе объяснить, что выборка - это не все данные, а только указатели на данные. Типа индекса, что ли...


Цитата:

вопросы на тему:
можно ли получать данные о том в какие места кэша будут идти операции чтения?

Нет, это внутренности SQLite.

tolyn77

Цитата:

может что с авторизацией не то имя пользователя и пароль для прокси сервера может не используются?

Хорошо, а каким именно способом ты пытаешься скачать через прокси:
1) через выделение
2) режим кэш+инет
3) инет
4) из контекстного меню "загрузить тайл"
5) скачать недостающие
?
Во всех случаях не работает?


Добавлено:
Насчет FAQa решил не мудрить, а просто сделал страничку на сайте: FAQ. Формат - простейший html, желающие могут либо напрямую добавлять код (но потом скидывать его мне), либо присылать мне вопрос-ответ, а я буду добавлять его.
А то открывать здесь топ для ФАКа и ограничивать в него доступ не просто...

relictus

Цитата:

у меня, кстати, около 20 сек

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

а так увеличить скорость можно сделал экспорт кэша, тогда данные упорядочиваются и чтнение их идёт последовательно с вытекающими..., по-сути на пределе линейной скорости диска считываются данные, что приемлимо, когда данные куда-то копируются, а в данном случае не очень:
наложение 18-го уровня на 10-й Москва:
68сек (средняя скорость диска ~30МБ\с)
28сек (средняя скорость диска ~60МБ\с)
Filemon_m181_1min_8sec.7z
Filemon_m181_28sec.7z

Цитата:

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

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

Цитата:

что выборка - это не все данные

слово выборка к "математике" относится

egor23

Цитата:

если говорим об одном и том же кэше

Нет. Я проверял на двух своих подключенных: 1.91 ГБ в сумме, не упорядоченные.
Комп: AMD 64 X2 5600+ 2.91 ГГц, 3.25 ГБ ОЗУ, разрешение 1280х1024.


Цитата:

а координаты тайлов неизвестны заранее? их надо полчучать откуда-то?

Конечно. Из выборки.


Цитата:

слово выборка к "математике" относится

SELECT — оператор языка SQL, возвращающий набор данных (выборку) из базы.

relictus
после удаления упаковаять кэш
предупреждение о том чтобы не суетились - это хорошо, а вот то что требуется на диске дополнительно место = объёму упаковываемого кэша не написали.

Цитата:

Я проверял на двух своих подключенных: 1.91 ГБ в сумме

примерно столько занимает 18уровень слой спутник сам по себе.

Цитата:

Конечно. Из выборки.

а почему координаты "неизвестны"? их разве нельзя рассчитать?
или нет возможности получить и сопоставить данные о тайлах: координаты - есть\нет тайл?

Цитата:

SELECT — оператор языка SQL, возвращающий набор данных (выборку) из базы.

это было сказано к тому, что со словом выборкой знаком, а с тем что там и как делает SQL незнаком.

Цитата:

А то открывать здесь топ для ФАКа и ограничивать в него доступ не просто...

ничего невозможного нет

Ув. relictus, у меня предложение: выпускайте следующий релиз, и давайте приступать к gps. Сезон уже в разгаре. Я даже могу помочь программировать.

А оправдаться вы ещё успеете. В мемуарах

relictus
1) через выделение
не качает
2) режим кэш+инет
не качает
3) инет
не качает
4) из контекстного меню "загрузить тайл"
не качает
5) скачать недостающие
не качает
а причем тут эти режимы? я ведь пишу что когда я меняю настройки, ходить помимо прокси сервера, программа все тайлы качает без проблем

egor23

Цитата:

что требуется на диске дополнительно место = объёму упаковываемого кэша не написали

Ок, напишу.


Цитата:

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

Ну как их рассчитать? Допустим, сделал ты выборку на какой-то район, в нее попали тайлы (упрощенно) 1110, 1111, 1112, 1123, 1548, 2000, ... Вот первые три элемента выборки идут последовательно, потом пропуск нескольких тайлов, а следющие идут вразнобой. Элемент выборки - это не тайл!
Как еще объяснить? Приезжай в гости, покажу как это работает в реале по-шагово


Цитата:

ничего невозможного нет

То есть? Если знаешь, скажи.

relictus

Цитата:

Ну как их рассчитать? Допустим, сделал ты выборку на какой-то район, в нее попали тайлы (упрощенно) 1110, 1111, 1112, 1123, 1548, 2000, ... Вот первые три элемента выборки идут последовательно, потом пропуск нескольких тайлов, а следющие идут вразнобой. Элемент выборки - это не тайл!
Как еще объяснить?

ммм... начнём сначала, в общих чертах:
1. есть окно SatMap пусть 1280х1024, т.е. для +8 - 1.2млн.тайлов
2. получить из "индекса" об этих тайлах информацию возможно "сразу" - есть\нет тайл?


Цитата:

То есть? Если знаешь, скажи.

раньше вроде к batva обращались с разного рода просьбами.

wonovid

Цитата:

Я даже могу помочь программировать.

Ловлю на слове
Имеется полигон (array of TPoint), могут быть самопересечения. Надо написать функцию для определения координат тайлов, попадающих в полигон. Берешься?

tolyn77

Цитата:

а причем тут эти режимы?

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

Добавлено:
egor23

Цитата:

получить из "индекса" об этих тайлах информацию возможно "сразу" - есть\нет тайл?

SELECT x,y,available FROM tiles WHERE (x >= 1000 AND x <= 2000) AND (y >= 1000 AND y <= 2000) AND (layer=satellite) AND (level=18)
На этом примере я имею набор данных (координаты тайла и признак его доступности) для все тайлов, координаты которых удовлетворяют условию 1000<x<2000 и 1000<y<2000, для слоя спутник уровня 18.
Теперь, чтобы узнать какие тайлы я должен схематично нарисовать, я должен пробежаться по всей выборке и отрисовать схемы, согласно полученным координатам.
Так понятней?

relictus
egor23
Если я правильно понял ваш научный спор -- то relictus утверждает, что библиотека SQLite в случае с наложением уперлась в предел своей производительности, а egor23 считает возможным отжать еще немного. Поскольку программу реализует relictus, я склонен верить ему (даже если это и не так -- пока он не найдет разгадки, быстрее она не заработает). Если прав egor23 -- слава богу. Но я предлагаю вам посмотреть на проблему с другой стороны. Когда вы говорите о "наложении", удалении", переконвертации кэша -- вы имеете ввиду один этап работы -- "подготовку рабочей картографической библиотеки в одном файле". Преимущества использования уже готовой библиотеки в одном фале очевидны. Но вот процесс подготовки такого файла в этой библиотеки у меня до сих пор не вызывает доверия. Поскольку все тесты я делал не "из любви к поэзии", а с конкретной целью -- собрать очень большую базу -- то у меня выработался примерно такой порядок работы.

Закачивание -- SatMap вариант мульти (каждый экзешник в отдельной папке с отдельным кэшем). Такой механизм много потоковой закачки затыкает за пояс все остальные.

Хранение и обработка черновика -- в кэше SAS. Туда сваливается весь улов версий мульти. И не важно закачала SATmap всю выбранную зону или нет -- при таких объемах невольно вспомнишь советские времена и расписание очередности работы с компьютером. Это же и защита от дурака (что очень важно) -- такой кэш действительно трудно угробить невольной ошибкой. Просмотр скаченных слоев, подчистка пропусков -- тоже там. Винды с этим справляются быстрее. А пропуск в 1 - 2 тыс тайлов можно докачать и допотопным механизмом с ограничением на 900 тайлов. Таким образом в кэше образовалось около 170 гб мусора по площади 110 тыс кв клм. Там не только гугль, но он доминирует.

Готовый к использованию, логически закругленный кэш -- в SatMap. Пока делал толко экспериментальные, не превышающие 15гб. Но в результате планирую утрясти весь мусор в 50-70 гб, разделенные на несколько файлов по 4 -- 15 гб и крайне минимально трогать их функциями отвечающими за обработку. А черновик, как и советовали ранее, просто форматнуть.

К чему я клоню? С таким архивом, который я собрал за месяц, в одиночку не справится ни с SAS, ни Satmap. Поэтому у меня уже четко сформировалось предложение, весь этот процесс уместить в рамках одной браузера. Т.е дать возможность работать в одном окне и со старыми форматами кэша типа SAS, под управлением винды и получать на выходе несколько файлов SQLite. Или, иначе говоря, создать надежную мусорную корзину. (Кому как больше нравится). SQLite не переплюнет винды в средней производительности, останутся только ограничения по железу. (Например, SAS подхватывается даже допотопным IBM 93 года выпуска). Удастся повысить безопасность черновика при подготовке конечного кэша. (Ошибки-то могут быть разными от "шаловливых ручек", до неправильной логики создания кэшей). А так же удастся избежать каши, если начнут подключаться другие ресурсы, кроме гугля -- вся каша останется в корзине, которая по мере использования уничтожается.

relictus

Цитата:

SELECT x,y,available FROM tiles WHERE (x >= 1000 AND x <= 2000) AND (y >= 1000 AND y <= 2000) AND (layer=satellite) AND (level=18)
На этом примере я имею набор данных (координаты тайла и признак его доступности) для все тайлов, координаты которых удовлетворяют условию 1000<x<2000 и 1000<y<2000, для слоя спутник уровня 18.
Теперь, чтобы узнать какие тайлы я должен схематично нарисовать, я должен пробежаться по всей выборке и отрисовать схемы, согласно полученным координатам.
Так понятней?

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

Индекс (базы данных)
http://ru.wikipedia.org/wiki/Индекс_(базы_данных)

Производительность SELECT-запросов
http://www.rusdoc.ru/articles/proizvoditelnost_select-zaprosov/17331/

netrebos

Цитата:

Если я правильно понял ваш научный спор

у нас не спор, т.к. я не знаю SQL
у меня просто непонятка, за каким надо выбирать данные шурша "всё" базу (в данном случае 18 уровень слой спутник ~ 1900МБ), с учётом того, что основной объём базы - это файлы, а записи о тайлах занимают незначительный объём.

Цитата:

Хранение и обработка черновика -- в кэше SAS

лишее действие, в общем слчучае.

Цитата:

Но в результате планирую утрясти весь мусор в 50-70 гб, разделенные на несколько файлов по 4 -- 15 гб и крайне минимально трогать их функциями отвечающими за обработку.

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

egor23

Цитата:

лишее действие, в общем слчучае.

Согласен, что лишнее, но необходимое. Для базы выше 2 гб нужен черновик, иначе возможность потери информации слишком велика. А на 2гб одной версии SatMap требуется пара суток. Но на это лишнее действие иду не только в целях безопасности -- в чистовой обработке САС справляется быстрее -- быстрее прорисовывает заполняемость слоев (Там это зависит от реального ОЗУ и процессора). Хотя там и недомудрили с информацией о тайлах отсутствующих на сервере. К тому же функция полигонного выделения сильно помогает.
А потеря времени на пергонке из кэша в кэш и торможения во время обработки, явления разного порядка. Перегнать кэш -- занятие автоматизированное, не требующего присутствия и минимизирующее ошибки. Торможение же в процессе обработки кэша провоцируют невосполнимый ущерб.



Цитата:

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

Качать один город в многослойном растре, за редким исключением бессмысленно -- на все крупные европейские, североамериканские и азиатские города есть вполне информативные векторы, например, IGo с картами от Телеатласа (с весом не более 500 мб). Ну а если его нет у Телеатласа, то даже в России в таком городе не заблудишься. Остаются только столицы африканских и латиноамериканских государств. Наш случай как раз "и т.п." -- места без доступной вообще, либо свежей, картографической съемки. Например, уложите в один файл (спутник, гибрид и ландшафт) авто-пеше-верховой маршрут от Новосибирска до горы Белуха с ответвлением на Телецкое озеро. Или всю Карелию -- так и получится около 40гб на один файл. Стремно хранить такой файл -- лучше разделить на слои и картоосновы.


Цитата:

у меня просто непонятка, за каким надо выбирать данные шурша "всё" базу (в данном случае 18 уровень слой спутник ~ 1900МБ)

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

netrebos

Цитата:

А на 2гб одной версии SatMap требуется пара суток.

2ГБ чего? если это спутник, то скорее всего быстрее (зависит от ширины канала и т.п.).
когда в тестовых целях качал Москву спутник 18уровень (120 000 тайлов), в 4-ре потока и канал был загружен на 100% (1Mbit\c), ушло примерно 4.5 часа.

Цитата:

Качать один город в многослойном растре, за редким исключением бессмысленно -- на все крупные европейские, североамериканские и азиатские города есть вполне информативные векторы, например, IGo с картами от Телеатласа (с весом не более 500 мб).

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

Цитата:

Наш случай как раз "и т.п." -- места без доступной вообще, либо свежей, картографической съемки.

ну это наша реальность

Цитата:

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

думаю это не предел, можно выжать больше.

egor23

Цитата:

2ГБ чего? если это спутник, то скорее всего быстрее

А каптчу вводить? Без организации круглосуточного "каптч-поста" с вахтами тогда необойдешься. Утром поставил ландшафт на одном потоке 532,5 тыс тайлов 2,8 гб -- за 16 часов забрал 128,5 тыс -- примерно 8тыс т\ч или 133 т\м. каптч не просил.


Цитата:

думаю это не предел, можно выжать больше

слово за relictus, изучившего ссылки.

netrebos

Цитата:

А каптчу вводить?

капча только на спутнике выскакивает.
для бытового применения SatMap подходит 6-8ч в день работы в фоне \ в несколько потоков.
несколько капч ввести не критично.

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

egor23

Цитата:

получать данные возможно не ползая по всей базе? (из "индекса", кажется)

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

netrebos

Цитата:

В этом мне кажется и есть предел производительности SQLite -- ей надо прошуршать всю базу

Да нет же! Данные выбираются по индексу! ПО ИНДЕКСУ!!! А это не есть просмотр всей БД!

relictus

Цитата:

Я занимаюсь кодингом более 25 лет, из них не менее половины - работа с БД.

это радует

Цитата:

Неужели ты думаешь, что я создал индексы и вообще всю структуру БД просто наобум? На все тесты, в том числе и на достижение максимальной производительности ушло несколько месяцев в прошедшем году...

это печалит, и добавляет работы, повторной

тогды хотелки, 1-простая хотелка, 2-спорная хотелка:
Настройки-Кэш
Хранилища тайлов
1. Сделать счётчик количества подключенных кэшей.
2. Усложнить структуру подключаемых кэшей, ввести группы (папки\подпапки), чтобы можно было быстро подключать\отключать кэши.

для FAQ-а:
...
делайте упорядочивание данных в кэше (экспорт), это ускорит работу с ним.
...

egor23

Цитата:

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

экспорт из одного кэша Satmap в другой кэш Satmap?


relictus


Цитата:

А это не есть просмотр всей БД!

Но есть предел производительности?

У меня тоже хотелка -- сделать в настройках возможность подключения нескольких кэшей для закачки напрямую, в том числе и сас. Для сторонних кэшей не нужны даже никакие другие функции -- только прямая закачка из Satmap. Структура кэшей тебе хорошо известна, так что технических проблем не должно быть. Цель -- получить бронебойную мусурную корзину для больших черновиков и экономить время на экспорт в многофайловые архивы. Одновременно решается вопрос мультизакачки в один кэш. Как показал опыт экспорта из кэша SatMap в САС, Сас легко выдерживает параллельный экспорт из нескольких мультяшек. Затронув эту тему, как накликал. Часов 20 стояло в три потока SatMap, каждый нахватавший уже по 150 -- 200 тыс тайлов, как дернул меня черт выйти в интернет с того же компа, а на сайте видиозаставка. То ли ОЗУ, то ли процессор перегрузились и винды выдали сообщение с ошибкой записи на диске и указанием работавших кэшей. Мультяшки, ясно, висели. Результат -- все 3 кэша пусты (64кб), и 20 часов в пустую. А если бы это был черновик под 100 гб -- плакала бы работенка? А если ребенок дернет за проводок между накопителем и USB? Не могу же я изолировать детей и отстрелить кота, считающего, что самое удобное место для его задницы аккомулятор ноутбука?

netrebos

Цитата:

экспорт из одного кэша Satmap в другой кэш Satmap?

угу

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

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

egor23

Цитата:

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

Ничего себе немного -- особенно с 18 -- 19 слоя. Все зависит от площади. А обосновать не хочешь -- может это не FAQ, а запрос на поиск решения?

netrebos
Я себе подобрал оптимальную, с моей точки зрения, систему - базовый кэш (копия), в который, хоть он и копия ничего не пишется, не столько чтобы не попортить, сколько во избежание конфликтов доступа - это несколько файлов общим размером 50-100 GB, можно на внешнем диске - он используется всеми версиями SatMap только для чтения, т.е никогда не стоят первыми в списке кэшей. И "персональные" кэши для каждой из копий SatMap. Иногда делаю перекрестные ссылки этих кэшей друг на друга, но это чревато запретом на доступ и обрывом закачки.

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

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

А кэш SAS может быть один на резервном диске, пока устойчивость кэша SatMap под вопросом, но в целом, с учетом возможности отказа HD и прочих факторов, кэш SAS намного менее надежен чем кэш SatMap. Послений я могу скопировать с диска на диск, или зарезервировать другим способом со средней скоростью 1-2 GB в минуту, те есть за час - полтора. Кэш же SAS просто скопировать практически невозможно, а бэкап партиции тем же Акронисом занимает намного больше времени, чем бэкап обычного диска.
Кстати если дефрагментацию базы SatMap можно сделать банальным экспортом, то дефрагментацию базы SAS сделать можно только сверхдолгим, и практически нереальным копированием с диска на диск (что тоже экспорт, но ооочень медленный). Плюс куча мелких файлов занимает намного больше дискового пространства, чем компактная база.

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

rex

Цитата:

Я себе подобрал оптимальную

Одновременно и согласен, и нет.

Цитата:

Я себе подобрал оптимальную, с моей точки зрения, систему

такая система подразумевает слишком много резервных дисков, занятых обработкой только одной базы, потому что не плохо было бы иметь еще и "копию копии". Что произойдет, если во время например, "обрезания -- упаковки" ребенок выдернет шнур накопителя. База издохнет.


Цитата:

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

-- согласен, нет ничего вечного


Цитата:

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

-- тоже верно

А вот с этим абсолютно не согласен:

Цитата:

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

1) Раз уже возможен импорт\экспорт, чуть сократить порядок ходов с "выкачиваем" - "экспортируем" до просто "выкачиваем" большого труда не составит, а экономия времязатрат пользователя на обработку черновиков сократится вдвое, а то и втрое, если учитывать уточнение egor23 об
Цитата:

ограничение на размер одиночного кэша

2) На относительно короткий отрезок времени, когда нужно развернуть всю черновую базу, действующий кэш САС более ударопрочен на разные воздействия пользователя -- угробить десяток тайлов безобиднее, чем 2 -- 4 гб даже промежуточного архива. За это время издыхание HD возможно, но не гарантировано. А в остальном кэш САС крайне неудобен (по крайней мере в зоне гугля), согласен. Но именно об этом отрезки времени я и пекусь. Заодно можно сэкономить как минимум один накопитель на хранении копии.
.
3) Сама надстройка САС пока несколько шире функций SatMap, что дает дополнительные преимущества в работе с черновиком. Одно полигонное выделение чего стоит (не в упрек). Отрисовка заполняемости слоев так же происходит быстрее. Да и количество подключенных ресурсов велико -- иногда полезно для сравнения с черновиком в одном окне.

4) Как ни странно, но допотопный механизм выкачивания тайлов САС для меня оказался очень удобным для подчистки небольших пропусков -- он лучше справляется с некоторыми особенностями моей сети именно во время коротких, около 100 тайлов, закачек.



Цитата:

Кэш SAS временная мера, даже для самой SAS.

GoogleMV оказался временной мерой для GoogleMV. Тем не менее САС предусматривает возможность сразу формировать кэш в формате GoogleMV -- удобная демократия выбора, на определенном этапе расширившая чьи-то возможности. Когда что-то есть -- можно пользоваться, можно нет. Когда нет -- то нет и выбора.

Ну целый роман накропал -- пусть relictus решает, а то еще голосование устроим раз речь зашла о демократии.

netrebos

Цитата:

А обосновать не хочешь -- может это не FAQ, а запрос на поиск решения?

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

Цитата:

Ничего себе немного -- особенно с 18 -- 19 слоя. Все зависит от площади.

пример (без крайностей) для спутника:
у меня доступно ~2000-2100МБ опер.памяти
навскидку: размер кэша будет - 1600-1700МБ \ размер тайла 25кБ (средний размер тайлов ещё меньше) \ кэш на 25% больше размера файлов,
т.е. размер тайлов будет 1280-1360МБ, итого количество тайлов ~52000-55000.

этап 1: выкачка области разбитой на участки, более мелкие, каждый одиночный кэш экспортируется по отдельности, предварительно загнав кэш в опер.память.
этап2: объденение кэшей, т.е. экспорт всех одиночных кэшей в один кэш.