netrebos
Full Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
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 слоев.
|
Всего записей: 447 | Зарегистр. 19-09-2006 | Отправлено: 17:16 23-03-2009 | Исправлено: netrebos, 17:28 23-03-2009 |
|
) ускорить удаление можно будет. Хотя оно и сейчас транзактивно выполняется. 
