Ru-Board.club
← Вернуться в раздел «Программы»

» SatMap

Автор: relictus
Дата сообщения: 24.03.2009 16:30
netrebos

Цитата:
Чего-то не понял

Упс... перезалил.
Автор: netrebos
Дата сообщения: 24.03.2009 16:39
relictus
И кнопка СТОП работает -- может ты чего не то положил по ссылки?


Добавлено:
relictus
щас посмотрим


Добавлено:
relictus
--якс сказала бензопила!!!!!!

Если правильно выше приведенное утверждение, что SQLite безразлично есть у него в архиве реальные тайлы или нет и при удалении она обрабатывает всю выделенную площадь, так как буд-то она заполнена тайлами -- то результат впечатляющий. 2,5 мин на тотальную зачистку 18-19 слоя спутника, гибрида, карты ландшафта по всей площади планеты со 2 слоя. Реальных тайло там было не много, что-то около 500 мб эпизодических тайлом 18 - 19 слоя в общем объеме кэша 4,5 гб. Во сколько это раз быстрее не знаю (надо бы какую-нибудь измерительную утилиту для теста прикрутить, что бы говорить одним порядком данных) -- но разница очень существенна в РАЗЫ. Угробить весь реальный кэш пока пожалел. Если это влияет на тест -- скажи, теперь это легко восполнимо.

Кстати кнопка СТОП работает, но выполняет провокационные функции -- при попытке нажать на нее программа виснит намертво. Если она связана со скоростью -- то ее можно убрать в жертву скорости.

Заметка по ходу -- при удалении не возникает информационное сообщение о том сколько удалено, как при закачке и импорте. О прекращение удаления можно судить только по смене кнопки ПУСК на ВЫПОЛНИТЬ. Если это не повлияет на скорость можно чего-то такое добавить или ограничиться каким-нибудь простеньким указателем о прекращении выполнения операции.

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


Автор: Trilobit69
Дата сообщения: 24.03.2009 18:45
relictus
Переконвертил кэш, всё залетало как на самолёте!

Заметил забавный глюк - меряю длину экватора, а она оказывается близка к нулю. Похоже измерение идёт по кратчайшему расстоянию между точками. Не знаю, поэтому, или по другой причине, длина нашей необьятной России оказыватся порядка 6 тыс. км. всего.


Ещё вот что подумалось, вдобавок к карте заполнения, было бы информативно отмечать на верхней полоске уровни, на которых есть тайлы в точке центра экрана (или курсора), скажем утолщением рамки. Если это конечно не приведёт к излишней загрузке процессора.
Автор: rex
Дата сообщения: 24.03.2009 18:55
relictus

Цитата:
Обновил версию мульти, ссылка прежняя.

Но это не мульти.


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

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


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


netrebos

Цитата:
Угробить весь реальный кэш пока пожалел. Если это влияет на тест -- скажи, теперь это легко восполнимо.

А кто мешает сначала сделать копию и гробить ее?
Автор: netrebos
Дата сообщения: 24.03.2009 18:57
rex

Цитата:
А кто мешает сначала сделать копию и гробить ее?

Пробелы в сообразительности.


Добавлено:
rex
у меня ссылка уже обновилась на правильную. файл SatMapGPS.exe определяется как измененный 24 марта в 13:14
Автор: relictus
Дата сообщения: 24.03.2009 19:47
netrebos

Цитата:
Если правильно выше приведенное утверждение, что SQLite безразлично есть у него в архиве реальные тайлы или нет

Это было справедливо до последней мульти-версии. А теперь все выполняется по формуле: "--якс сказала бензопила", то бишь удаление скопом

Цитата:
Кстати кнопка СТОП работает

Да как сказать работает - просто отображается Клик по ней реально никак не обрабатывается в проге, лучше ее не жмакать Версия-то тестовая, на любителей "пылесоса".

Цитата:
Заметка по ходу -- при удалении не возникает информационное сообщение о том сколько удалено, как при закачке и импорте.

А она нужна, эта инфа? Могу ввести, чуть замедлит процесс, но не в РАЗЫ.

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

Жалею - ускорить импорт/экспорт нельзя Там обработка потайлово, с проверкой условий заменять/не заменять и пр., а это ускорить нельзя.

Trilobit69

Цитата:
Заметил забавный глюк - меряю длину экватора, а она оказывается близка к нулю.

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

Цитата:
Если это конечно не приведёт к излишней загрузке процессора.

Приведет и еще как.

rex

Цитата:
Но это не мульти.

Я по ошибке залил не ту версию, перезакачай, правильная должна быть от 24 марта 13:14. В заголовке проги должно быть слово multi.


Автор: netrebos
Дата сообщения: 24.03.2009 20:02
relictus
Да стоило угробить кеш в 4,43 гб, точнее его копии, как и советовал rex. Кеш составляли слои спутника с 1 по 16. Удаление выбиралось по максимуму -- все слои, все ресурсы. Первый раз копия была помещена в корень жесткого диска и удаление выдала error10-disc 1\0 error. Визуальный осмотр показал удаление всех слоев кроме 16 слоя. Повторная попытка привела к зависанию проги.

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

Но самое интересное, что ни в первом ни во втором случае win сразу не показал физического сокращения объема кэша -- продолжая указывать, что он весит 4,43 гб. После перезагрузки диска win показал сокращение первого кэша до 64 кб, а второй кэш упорно продолжал определить как 4,43 гб. Визуально он пуст.


Добавлено:
relictus

Цитата:
Клик по ней реально никак не обрабатывается в проге, лучше ее не жмакать
Еще как обрабатывается -- зависанием проги.


Добавлено:
relictus

Цитата:
А она нужна, эта инфа?


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


Цитата:
Жалею

Придется мне запасаться кетчупом.



Добавлено:
relictus
Проверил третий раз. Снова загнал кеш 4,43 гб в корень диска. (1-16 слой спутника) Со 2 слоя выбрал максимальное задание для удаления по всему миру. Удалила за те же 2,5 минуты. Никакой ругани и ошибок. Визуально все удалено. Но физический объем файла не уменьшился -- он по-прежнему весит 4,43 гб. Презагрузка диска ничего не меняет. Так должно быть или нет?
Автор: relictus
Дата сообщения: 24.03.2009 21:06
netrebos

Цитата:
Придется мне запасаться кетчупом.

То ли я тебя не понял, то ли ты меня - ускорить импорт/экспорт, НЕ УДАЛЯЯ ПРОВЕРКУ УСЛОВИЙ, нельзя. Кетчуп тебе не понадобится, да и шляпа цела будет


Цитата:
Так должно быть или нет?

Все верно, пока не сделаешь "упаковку" кэша, размер будет одинаков, что с удаленными тайлами, что без. Таков SQLite, да и некоторые другие движки БД. По аглицки же понимаешь? Вот цитата из гвайда к SQLite:
"When an object (table, index, or trigger) is dropped from the database, it leaves behind empty space. This makes the database file larger than it needs to be, but can speed up inserts. In time inserts and deletes can leave the database file structure fragmented, which slows down disk access to the database contents.
The VACUUM command cleans the main database by copying its contents to a temporary database file and reloading the original database file from the copy. This eliminates free pages, aligns table data to be contiguous, and otherwise cleans up the database file structure."
Автор: rex
Дата сообщения: 24.03.2009 21:17
netrebos

Цитата:
Проверил третий раз. Снова загнал кеш 4,43 гб в корень диска. (1-16 слой спутника) Со 2 слоя выбрал максимальное задание для удаления по всему миру. Удалила за те же 2,5 минуты. Никакой ругани и ошибок. Визуально все удалено. Но физический объем файла не уменьшился -- он по-прежнему весит 4,43 гб. Презагрузка диска ничего не меняет. Так должно быть или нет?

На "после удаления упаковать кэш" галка стоит?
Автор: egor23
Дата сообщения: 24.03.2009 22:02
relictus

Цитата:
То ли я тебя не понял, то ли ты меня - ускорить импорт/экспорт, НЕ УДАЛЯЯ ПРОВЕРКУ УСЛОВИЙ,

там же есть услосие - Заменять всё, ему-то не нужны "никакие проверки".
т.е. ускорить это режим можно.

Автор: netrebos
Дата сообщения: 24.03.2009 22:04
relictus

Цитата:
Все верно, пока не сделаешь "упаковку" кэша, размер будет одинаков, что с удаленными тайлами, что без. Таков SQLite, да и некоторые другие движки БД. По аглицки же понимаешь? Вот цитата из гвайда к SQLite:
"When an object (table, index, or trigger) is dropped from the database, it leaves behind empty space. This makes the database file larger than it needs to be, but can speed up inserts. In time inserts and deletes can leave the database file structure fragmented, which slows down disk access to the database contents.
The VACUUM command cleans the main database by copying its contents to a temporary database file and reloading the original database file from the copy. This eliminates free pages, aligns table data to be contiguous, and otherwise cleans up the database file structure."


М-да. Это видимо объясняет реакцию виндов о которой собрался писать. После перезагрузки диска -- войти в версию мульти, занимавшуюся удалением становится невозможным. Появляется сообщение "невозможно сохранить файл конфигурации". Удалить сообщение удается только перезагрузкой, но перед ней появлется еще одно сообщение "Access violation at adress 006B3213 in module "SatMapGPS.exe". Read of address 00000008".

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

Добавлено:
rex
Уже понял, что свалял дурака. Не стоит галки. И так если эта версия получит широкое распространение требуется ограничение для шаловливых ручек -- убрать кнопку СТОП и ввести автоматическу упаковку кэша.
Автор: rex
Дата сообщения: 24.03.2009 23:29
netrebos

Цитата:
и ввести автоматическу упаковку кэша.

А вот этого не надо!!!
Если человеку надо пару сотен сбойных тайлов рельефа удалить, перепаковывать всю базу совсем не обязательно, особенно если у него не квадро с шестью гигабайтами DDR3.

Глобально же никто, или почти никто, таким образом редактировать кэш не будет. Проще это делать через импрорт экспорт в самой SatMap, либо через свалку файлов GMV, а сейчас можно и через гораздо более структурированный чем кэш GMV кэш SAS. Разместил кэш на другом диске, на созданной специально для него партиции и вали все туда. Кстати в SAS и удаление выбранного региона есть. Удалять правда потом этот склад нормальным образом дико долго, но форматнуть при необходимости партицию пару секунд, для чего ее и стоит сделать. Скорость экспорта-импорта кэшей SatMap - SAS - SatMap если они на разных дисках 3-4 GB в час. Послойный импорт у SatMap есть. Территориальный не проверял.
Когда же relictus введет импорт сразу несколких кэшей подряд, а не как сейчас по одному, и GMV будет ненужен - создал пустой кэш и импортируй туда ночью все что надо из всех кэшей сразу.

Автор: netrebos
Дата сообщения: 25.03.2009 00:09
relictus

Мд-а ну наконец выставил все галки правильно. И результат уже не столь впечатляющий -- 35 минут на всю задачу. Зато разобрался, что эта задача разделана на два этапа. 1) Собственно удаление. (Происходит мгновенно или почти мгновенно. Но наступают вышеописанные косяки, если не сделать следующую операцию) 2)упаковка кэша. Она тянется столько времени, сколько нужно программе заполнить файл journal. На 4,3 гб ушло 35 минут. Одинаковое количество времени и по сложному заданию (уничтожить весь кэш) и по относительно простенькому -- убрать зону Западной Сибири и Китая, где есть только эпизодические файлы, что и отразил реальный объем кэша -- он сократился до 4,1 гб. Т.е. 200 мб удалялись 35 минут. На протяжении этапа упаковки диспетчер сообщал о том, что Satmap "не отвечает". Может железо и влияет на процесс, но не думаю -- загрузка процессора в это время не превышала 40% в пиковых значениях, а в среднем 8-13%. Да и памяти отъедало около 400 мб. Так что, если не удастся ускорить упаковку, эта функция по-прежнему остается функцией для мазахистов. Тратить 35 минут на удаление случайных тайлов, которые не весят более 500 мб жалко. А весь кэш быстрее удалить делейтом.


Добавлено:
rex

Цитата:
А вот этого не надо!!!

уже разобрался смотри выше.


Цитата:
Глобально же никто, или почти никто, таким образом редактировать кэш не будет. Проще это делать через импрорт экспорт в самой SatMap, либо через свалку файлов GMV, а сейчас можно и через гораздо более структурированный чем кэш GMV кэш SAS. Разместил кэш на другом диске, на созданной специально для него партиции и вали все туда. Кстати в SAS и удаление выбранного региона есть. Удалять правда потом этот склад нормальным образом дико долго, но форматнуть при необходимости партицию пару секунд, для чего ее и стоит сделать. Скорость экспорта-импорта кэшей SatMap - SAS - SatMap если они на разных дисках 3-4 GB в час. Послойный импорт у SatMap есть. Территориальный не проверял.
Когда же relictus введет импорт сразу несколких кэшей подряд, а не как сейчас по одному, и GMV будет ненужен - создал пустой кэш и импортируй туда ночью все что надо из всех кэшей сразу.


Этой логикой я пользуюсь уже давно. Территориального экспорта-импорта кэшей SatMap - SAS - SatMap не существует. Остается только просить сделать такой. Или усложнить алгоритм SatMap (послойный импорт)- SAS -- (территориальный импорт) SAS -- (послойный) SatMap.

В общем все эти трепыхания с кэшем (а тем более с функцией удаления) наверное стоит оставить до тех пор пока программа не получит такую же внятную конфигурацию на ее использовании, как и на входе. На входе быстрый сбор информации с гугля уже есть. А что на выходе -- пока не понятно. Если самостоятельная навигационная система с несколькими файлами -- это одно. Если конвертор в ОЗИ -- другое. Но уж больно много ограничений от SLQLite -- туда не ходи, сюда не ходи.
Автор: relictus
Дата сообщения: 25.03.2009 08:27
egor23

Цитата:
там же есть услосие - Заменять всё, ему-то не нужны "никакие проверки".
т.е. ускорить это режим можно.

Все равно одна проверка нужна: если тайл есть в кэше, то UPDATE, нет - INSERT.

netrebos

Цитата:
М-да. Это видимо объясняет реакцию виндов о которой собрался писать. После перезагрузки диска -- войти в версию мульти, занимавшуюся удалением становится невозможным. Появляется сообщение "невозможно сохранить файл конфигурации". Удалить сообщение удается только перезагрузкой, но перед ней появлется еще одно сообщение "Access violation at adress 006B3213 in module "SatMapGPS.exe". Read of address 00000008".

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


Цитата:
Мд-а ну наконец выставил все галки правильно. И результат уже не столь впечатляющий -- 35 минут на всю задачу. Зато разобрался, что эта задача разделана на два этапа. 1) Собственно удаление. (Происходит мгновенно или почти мгновенно. Но наступают вышеописанные косяки, если не сделать следующую операцию) 2)упаковка кэша. Она тянется столько времени, сколько нужно программе заполнить файл journal. На 4,3 гб ушло 35 минут.

Я специально не выставил автоупаковку кэша, т.к. ее следует применять только в целях уменьшить размер файла БД. Место, оставшееся после удаления записей будет использовано для добавления новых записей. VACUUM - оперция не быстрая, к тому же она не имеет callback функции, отсюда и
Цитата:
На протяжении этапа упаковки диспетчер сообщал о том, что Satmap "не отвечает"

Надеюсь вот эта инфа до конца прояснит ситуацию с упаковкой:

Цитата:
When you delete information from a SQLite database, the unused disk space is added to an internal "free-list" and is reused the next time you insert data. The disk space is not lost. But neither is it returned to the operating system.
If you delete a lot of data and want to shrink the database file, run the VACUUM command. VACUUM will reconstruct the database from scratch. This will leave the database with an empty free-list and a file that is minimal in size. Note, however, that the VACUUM can take some time to run (around a half second per megabyte) and it can use up to twice as much temporary disk space as the original file while it is running.


Автор: TheGarl
Дата сообщения: 25.03.2009 09:17
2relictus

Цитата:
наложить схему заполнения уровнем,

может не номера уровнеё там писать а +1 +2 +3 .....

а то получается выбрал я 15 уровень зазумировался, и наивный думал, что он мне всё ещё 15 зум выделяет ...
Автор: relictus
Дата сообщения: 25.03.2009 09:25
TheGarl

Цитата:
может не номера уровнеё там писать а +1 +2 +3 ..

Да мне все равно, что писать. Тут у нас есть критики интерфейса SatMap, пусть выскажутся, как правильней
Автор: egor23
Дата сообщения: 25.03.2009 10:27
relictus

Цитата:
может не номера уровнеё там писать а +1 +2 +3 .....


Цитата:
Да мне все равно, что писать. Тут у нас есть критики интерфейса SatMap, пусть выскажутся, как правильней

+1 и т.п. неудобно будет, то выбрал конкретный уровень и сразу ясно какой.

TheGarl

Цитата:
а то получается выбрал я 15 уровень зазумировался, и наивный думал, что он мне всё ещё 15 зум выделяет ...

какая взаимосвязь между выбран уровень 15 или же выбран +5, и тем что у Вас там происходит?
Автор: rex
Дата сообщения: 25.03.2009 10:27
relictus
Наивность обычно утрачивается после первого же раза, а арифметикой придется заниматься каждый раз, так что оставь все как есть. Главное сделай поскорее однослойность наложения - опционально или вообще и 8-мь уровней. Сейчас чтобы во всех этих оттенках и полутонах разобраться надо художником быть.
Автор: egor23
Дата сообщения: 25.03.2009 10:36
relictus

Цитата:
+1 и т.п. неудобно будет, то выбрал конкретный уровень и сразу ясно какой.

или можно двойную нумерацию ввести в скобочках +
например: 8 (+2)
Автор: relictus
Дата сообщения: 25.03.2009 10:57
egor23

Цитата:
или можно двойную нумерацию ввести в скобочках +
например: 8 (+2)

ИМХО, самое то
Автор: rex
Дата сообщения: 25.03.2009 12:56
relictus
Если собираешься выходить на американский рынок, то давать решение сверхсложной математической задачи (8-6=?) действительно
Цитата:
самое то

Только не забудь английский интерфейс сделать, а то у них с русским еще хуже чем с арифметикой.


Автор: relictus
Дата сообщения: 25.03.2009 13:03
rex
Лучше скажи, как там с окном каптчи?
Автор: netrebos
Дата сообщения: 25.03.2009 18:29
relictus

Цитата:
Надеюсь вот эта инфа до конца прояснит ситуацию с упаковкой:


Согласен, прояснила. И после того, как проспался после бесконечного копирования 4 гб для очередного убийства более оптимистично взглянул на процесс -- само удаление стало очень быстрым, что очень существенно для построения файла по конкретной территории. Может быть для удобства можно было бы предложить выбор -- "удалять внутри выделенной зоны" и "удалять внешнюю сторону выделенной зоны". Так проще будет "вырубать" виртуальный "кубик" многослойного растра. А для придания процессу завершенного вида можно будет выполнить и команду VACUUM. 35 минут на 4 гб файл -- окончательной обработки вполне приемлемо.

А вот с этим стоит разобраться по-внимательней:

Цитата:
После перезагрузки диска -- войти в версию мульти, занимавшуюся удалением становится невозможным. Появляется сообщение "невозможно сохранить файл конфигурации". Удалить сообщение удается только перезагрузкой, но перед ней появлется еще одно сообщение "Access violation at adress 006B3213 in module "SatMapGPS.exe". Read of address 00000008".

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


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



Цитата:
На протяжении этапа упаковки диспетчер сообщал о том, что Satmap "не отвечает"

Это психологическая проблема среднестатистического пользователя виндов -- если программа в диспетчере долгое время "не отвечает", она воспринимается как "зависшая". Если бы Satmap был коммерческим проектом, я категорично настаивал бы на некоем информационном сообщении пользователю, о выполнении определнного процесса. Ну а я теперь знаю, что в данном конкретном случае надо просто смотреть на изменения с файлом journal.



Цитата:
там же есть услосие - Заменять всё, ему-то не нужны "никакие проверки".
т.е. ускорить это режим можно.

Все равно одна проверка нужна: если тайл есть в кэше, то UPDATE, нет - INSERT.


Эти варианты тоже надо покрутить ручками, а потом уже думать о кетчупе.

rex

Цитата:
Наивность обычно утрачивается после первого же раза, а арифметикой придется заниматься каждый раз, так что оставь все как есть. Главное сделай поскорее однослойность наложения - опционально или вообще и 8-мь уровней. Сейчас чтобы во всех этих оттенках и полутонах разобраться надо художником быть.


Согласен, с оговоркой -- синий цвет (цветовая гамма не принципиальна) указывающий на отсутствие тайлов на сервере Гугла должен остаться обязательно. В крайнем случае можно будет в дальнейшем подправить под любителей "юзабилити", в том числе и под меня. Пока скажу только, что мне удобней реальное указание выбираемого слоя, а не арифметическое и галочка против цифры.

Сейчас пока прошу дополнить эту функцию возможностью "обновить информацию об отсутстующих тайлах на Гугле" без перезакички.

Ну и наконец про последнюю версию мульти и каптчу поверх окон.
У меня не всплывает. Поставил этой ночью уже 20 пылесосов -- загрузка ЦП только 40%, память 1 гб. Т.е при наличии 2 гб озу можно смело ставить до 40 пылесосов. Но капчу пришлось вводить переключаясб между програмками.









Автор: rex
Дата сообщения: 25.03.2009 19:17
netrebos

Цитата:
синий цвет (цветовая гамма не принципиальна)

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

Добавлено:
relictus

Цитата:
Лучше скажи, как там с окном каптчи?

Пока каптч не было
Автор: netrebos
Дата сообщения: 25.03.2009 19:32
rex

Цитата:
У меня был знакомый, который ориентировался не по цвету светофора, а по порядку горящих лампочек.


Если relictus адаптирует программу программу под дальтоников и североамериканцев (я бы еще предложил безруких и безногих ветеранов Вьъетнама) -- он получит нобелевскую премию, а у нас, боюсь, не хватит денег на ее приобретение. Будем стучаться в другую ветку этого форума за ключиком.

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





Добавлено:
А вот +8 наиболее акутально.
Автор: rex
Дата сообщения: 25.03.2009 20:20
relictus

Цитата:
Лучше скажи, как там с окном каптчи?

Како было, тако есть

netrebos

Цитата:
он получит нобелевскую премию

Програмистам дают только шнобелевские
Автор: Trilobit69
Дата сообщения: 25.03.2009 20:45
relictus

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

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

Ещё один момент:

Цитата:

БСЭ
РСФСР занимает большую часть Восточной Европы и Северную Азию. Протяжённость в меридиональном направлении 2,5—4 тыс. км, в широтном — 9 тыс. км. Самая западная точка — на границе с Польшей (19°38' в. д.), а крайняя восточная — на острове Ратманова в группе островов Диомида в Беринговом проливе (169°02' з. д.).


В сатмапе же вместо 9 тыс.км. можно намерять только 7
Автор: relictus
Дата сообщения: 26.03.2009 08:53
netrebos

Цитата:
Кстати замена экзешника ни к чему не приводит. Приходилось полностью удалять программу и устанавливать ее заново. Надо попробовать создать те же условия на другой машине -- но смогу это сделать только завтра. Сегодня у меня не будет другого компа и внешнего накопителя с вариантами satmap тоже с собой нет. Может быть стоит прислать тебе "поломавшуюся" версию программы без кэша? Но смогу сделать это только завтра.

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


Цитата:
Эти варианты тоже надо покрутить ручками

В смысле?

rex

Цитата:
Како было, тако есть

Ну блин, щаз еще раз изменю код, пусть только не вылезет это окно!

Trilobit69

Цитата:
В сатмапе же вместо 9 тыс.км. можно намерять только 7

ХЗ почему так... использовал для расчета формулы типа как здесь:
http://www.ipedia.net/information/great-circle+distance

Добавлено:
Обновил мульти. rex - пробуй каптчу!
Автор: netrebos
Дата сообщения: 26.03.2009 16:16
Trilobit69
Я думаю, что ответ на ваш вопрос есть отношение проекции крупномаштабного гугля к реальной сфере земли. Гугль это простая Geographic (Latitude/Longitude) и говорить о точности на крупном масштабе не приходится. Вот здесь есть математические расчеты перевода Гугля в Меркатор http://xitrostige.narod.ru/projection.html. Думаю, если бы вы промерили весь маршрут с польской границы до острова Ратманова на 17 -- 19 слое то получили бы искомые 9 тыс клм. Может даже можно написать утилиту для счисления погрешности на крупном масштабе -- но боюсь она не будет слишком точна, т.к. речь идет о фотографии. Да и практическая ценность не очевидна. За все время существования гугля я не встречал морских и авиационных штурманов всерьез рассматривающих построение курса через гугль. Практическое применение гугля в навигации -- как раз в мелком масштабе (в этом случае Lat/Long дает наименьшую погрешность) и отсутствии картографической съемки для труднодоступных районов. Поэтому-то ценность генштабовских пятикилометровок никто не отменял, даже не смотря на устаревшую съемку объектов инфраструктуры. А к курпномасштабному Гуглю стоит относиться как к индексной карте в ОЗИ -- не более.

Кстати, relictus коль речь зашла об использовании SatMap в построении длинных курсов, не предусмотреть ли возможность отображения в программе растров генштаба, привязанного в ОЗИ. Но это уже разговор следующего уровня трансформации программы, после шлифовки работы с кэшем. Я имею ввиду связь с ГПС, навигационные рассчеты и навигацию в реальном времени.




Автор: relictus
Дата сообщения: 26.03.2009 16:33
netrebos

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

Есть такая задумка, самому нужна, но сейчас не до проги вообще

Страницы: 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667

Предыдущая тема: 2gis (ДубльГИС) 2ГИС


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.