Перейти из форума на сайт.

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в on-line?
Вход Забыли пароль? Первый раз на этом сайте? Регистрация
Компьютерный форум Ru.Board » Компьютеры » Программы » SatMap (2)

Модерирует : gyra, Maz

Widok (02-08-2010 11:58): Лимит страниц. Продолжаем здесь.  Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106

   

relictus

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Предыдущие части темы

 
SatMap
просмотр, скачивание, кэширование, склейка и привязка спутниковых снимков/гибрида/карт/ландшафта с сервиса Google Maps.

 
FAQ
Настоятельно рекомендуется ознакомиться как опытным пользователям, так и всем новичкам.

 
Текущая версия 2.4.0 (multilingual):
История версий
полный комплект v2.4.0 (2.74 Mb)
v2.4.1.7 (только exe) (1.39 Mb)
SatMap API
 
* - архивы в формате 7-zip
 


Кэши скачанных районов
 


 
Официальный сайт http://satmap.narod.ru

 
Основные функции и возможности (на данный момент):
1. Импорт данных из кэша GoogleMV (версии 2.7+), GoogleV, EarthSlicer (только спутник), SatMap, SASPlanet, Global Mapper
2. Формат кэша: 1 кэш = 1 файл
3. До 100 подключаемых кэшей
4. Экспорт в кэш формата GoogleMV, SatMap, SASPLanet, GPSProga
5. Поиск, сохранение и переход по введенным координатам/названию места
6. Работа с путевыми точками и треками в формате OziExplorer (*.wpt, *.plt)
7. Измерение расстояния
8. Склейка/экспорт данных в графические форматы JPG, PNG, TIFF, ECW, JPEG2000, MrSID
9. Геопривязка в форматах Ozi Explorer, MapInfo, world-файл, TomTom overlay
10. Закачивание данных с сервиса Google Maps без бана
11. Показ высоты по данным SRTM
12. API для управления SatMap
13. Навигационный режим работы с GPS-приемником
14. Работа с базой данных географических названий объектов GNS
 
Планируется:
1. Работа с форматом kml/kmz
2. Возможность скачивать данные с других сервисов
3. и многое другое......
 
Программа распространяется бесплатно. Используйте ее на свой страх и риск.

Всего записей: 3696 | Зарегистр. 19-04-2005 | Отправлено: 13:17 02-04-2009 | Исправлено: relictus, 13:52 23-06-2010
wonovid

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Ув. relictus, у меня предложение: выпускайте следующий релиз, и давайте приступать к gps. Сезон уже в разгаре. Я даже могу помочь программировать.  
 
А оправдаться вы ещё успеете. В мемуарах

Всего записей: 65 | Зарегистр. 15-01-2009 | Отправлено: 11:56 06-04-2009 | Исправлено: wonovid, 13:34 06-04-2009
tolyn77



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

Всего записей: 1498 | Зарегистр. 07-09-2004 | Отправлено: 11:57 06-04-2009
relictus

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
egor23

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

Ок, напишу.
 

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

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

Цитата:
ничего невозможного нет

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

Всего записей: 3696 | Зарегистр. 19-04-2005 | Отправлено: 12:02 06-04-2009
egor23



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
relictus

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

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

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

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

Всего записей: 3832 | Зарегистр. 03-11-2003 | Отправлено: 13:08 06-04-2009
relictus

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
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.
Теперь, чтобы узнать какие тайлы я должен схематично нарисовать, я должен пробежаться по всей выборке и отрисовать схемы, согласно полученным координатам.
Так понятней?

Всего записей: 3696 | Зарегистр. 19-04-2005 | Отправлено: 13:21 06-04-2009
netrebos

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
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 года выпуска).  Удастся повысить безопасность черновика при подготовке конечного кэша. (Ошибки-то могут быть разными от "шаловливых ручек", до неправильной логики создания кэшей). А так же удастся избежать каши, если начнут подключаться другие ресурсы, кроме гугля -- вся каша останется в корзине, которая по мере использования уничтожается.        
 
 
     
 
 
 
 

Всего записей: 447 | Зарегистр. 19-09-2006 | Отправлено: 17:48 06-04-2009
egor23



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
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 гб и крайне минимально трогать их функциями отвечающими за обработку.

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

Всего записей: 3832 | Зарегистр. 03-11-2003 | Отправлено: 22:52 06-04-2009 | Исправлено: egor23, 23:04 06-04-2009
netrebos

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
egor23

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

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

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

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

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

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

Всего записей: 447 | Зарегистр. 19-09-2006 | Отправлено: 00:01 07-04-2009
egor23



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
netrebos

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

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

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

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

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

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

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

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

Всего записей: 3832 | Зарегистр. 03-11-2003 | Отправлено: 00:30 07-04-2009 | Исправлено: egor23, 00:47 07-04-2009
netrebos

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
egor23

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

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

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

Всего записей: 447 | Зарегистр. 19-09-2006 | Отправлено: 02:50 07-04-2009
egor23



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
netrebos

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

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

Всего записей: 3832 | Зарегистр. 03-11-2003 | Отправлено: 03:58 07-04-2009
relictus

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
egor23

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

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

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

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

Всего записей: 3696 | Зарегистр. 19-04-2005 | Отправлено: 09:06 07-04-2009
egor23



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
relictus

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

это радует

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

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

Всего записей: 3832 | Зарегистр. 03-11-2003 | Отправлено: 09:43 07-04-2009
netrebos

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
egor23

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

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

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

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

Всего записей: 447 | Зарегистр. 19-09-2006 | Отправлено: 13:22 07-04-2009
egor23



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
netrebos

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

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

Всего записей: 3832 | Зарегистр. 03-11-2003 | Отправлено: 13:43 07-04-2009
wonovid

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Таки да, закачка в чужие кеши вместе с многопоточностью. Было бы очень здорово.

Всего записей: 65 | Зарегистр. 15-01-2009 | Отправлено: 13:47 07-04-2009 | Исправлено: wonovid, 14:11 07-04-2009
netrebos

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
egor23

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

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

Всего записей: 447 | Зарегистр. 19-09-2006 | Отправлено: 15:39 07-04-2009
rex



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
netrebos
Я себе подобрал оптимальную, с моей точки зрения, систему - базовый кэш (копия), в который, хоть он и копия ничего не пишется, не столько чтобы не попортить, сколько во избежание конфликтов доступа - это несколько файлов общим размером 50-100 GB, можно на внешнем диске - он используется всеми версиями SatMap только для чтения, т.е никогда не стоят первыми в списке кэшей. И "персональные" кэши для каждой из копий SatMap. Иногда делаю перекрестные ссылки этих кэшей друг на друга, но это чревато запретом на доступ и обрывом закачки.
 
Главная проблема такой системы не в ней самой, а в отсутствии в текущей версии SATMAP при формировании плана закачки, учета тайлов имеющихся в во всех подключенных кэшах кроме первого, из-за чего очень высок процент дублей.
relictus обещал это доделать, но пока застрял на чем-то другом.
 
Раз в неделю или месяц все инкрементные кэши можно импортировать в основные, ничем не рискуя, сейчас это приходится делать реже, по мере полного заполнения скачиваемого участка.
 
А кэш SAS может быть один на резервном диске, пока устойчивость кэша  SatMap под вопросом, но в целом, с учетом возможности отказа HD и прочих факторов, кэш SAS намного менее надежен чем кэш SatMap. Послений я могу скопировать с диска на диск, или зарезервировать другим способом со средней скоростью 1-2 GB в минуту, те есть за час - полтора. Кэш же SAS просто скопировать практически невозможно, а бэкап партиции тем же Акронисом занимает намного больше времени, чем бэкап обычного диска.  
Кстати если дефрагментацию базы SatMap можно сделать банальным экспортом, то дефрагментацию базы SAS сделать можно только сверхдолгим, и практически нереальным  копированием с диска на диск (что тоже экспорт, но ооочень медленный). Плюс куча мелких файлов занимает намного больше дискового пространства, чем компактная база.
 
Так что не думаю, что relictus стоит тратить время на дополнительные приспособления к кэшу SAS. Кэш SAS временная мера, даже для самой SAS.

Всего записей: 2319 | Зарегистр. 20-10-2003 | Отправлено: 16:51 07-04-2009 | Исправлено: rex, 16:58 07-04-2009
netrebos

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
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 решает, а то еще голосование устроим раз речь зашла о демократии.  
 
 
 
 
 

Всего записей: 447 | Зарегистр. 19-09-2006 | Отправлено: 18:43 07-04-2009
egor23



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
netrebos

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

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

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

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

Всего записей: 3832 | Зарегистр. 03-11-2003 | Отправлено: 19:33 07-04-2009 | Исправлено: egor23, 19:41 07-04-2009
   

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106

Компьютерный форум Ru.Board » Компьютеры » Программы » SatMap (2)
Widok (02-08-2010 11:58): Лимит страниц. Продолжаем здесь.


Реклама на форуме Ru.Board.

Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
Modified by Ru.B0ard
© Ru.B0ard 2000-2024

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru