Чего вы хотите?

[Bigbambr]

Хочу! Очень хочу, чтобы при щелчке на треке высвечивалось не только его название, но и время и скорость прохождения данного участка трека.

[Parasite]

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

Как по одному щелчку (одной точке) предлагается определять участок трека (у которого должны быть как минимум начало И конец (две точки))?

[Papazol]

Сменив tid или версию (вовсе для этого в zmp лезть не надо) всё равно надо искать места обновлений!
Ничего никуда записывать не надо (только в буфер в памяти куда тайл будет загружен процедурой его загрузки лишь для того чтобы сравнить его содержимое с тайлом из кеша. После чего тайл смело выкидывается и сохраняется лишь информация о том новый ли это тайл). В случае же если новый снимок хуже старого то хоть затраться трафику - если ты его закачаешь и затрёшь старый, то "вырванные волосы не вставишь назад". (по крайней мере без танцев с бубнами). Что касаемо повторной загрузки всех новых тайлов, то реалии жизни таковы, что их количесво в 99.99% случаев будет равно нулю. Так что совершенно не страшно

Пусть в zmp лезть и не надо, это не принципиально, но не лучше ли сначала найти места обновлений, а потом приступить к скачиванию? По всему шарику не будешь ведь проверять обновления, по крайней мере таким способом. Значит, участок для проверки будет не огромный, а, например, область какая-нибудь. На 14-м уровне вполне можно визуализировать обновления. Не знаю, у кого как, а у меня проблема не в обновлениях старых съёмок, а в обнаружении новых, ранее не покрытых участков. Если сначала смотреть в Google Earth, где обновления происходят раньше, да к тому же участки в высоким разрешением там видны на низких уровнях, то можно хотя бы приблизительно очертить новые покрытия, а затем, перейдя в SAS.Планету, закачать их, разумеется, если они уже вставлены в Google Maps. Я так делаю, может, это неправильно?
По поводу записи новых (или не новых) проверочных тайлов. Если цель - уменьшить трафик, то записывать надо, по крайней мере, те тайлы, что отличаются от имеющихся, иначе их придётся закачивать повторно, что не способствует экономии трафика. До визуальной проверки качества новой съёмки придётся складывать эти тайлы в отдельную папку, чтобы не затронуть старой съёмки. А оценить качество новых съёмок, особенно если речь идёт не о замене низкого разрешения на высокое (тут вопросов нет), а именно о новых снимках одного и того же места с высоким разрешением, можно только после закачки некоторого целого участка, то есть всех тайлов, а не каждого 2-го или 8-го.
Если цель фичи другая (какая?), то, возможно, я в своих размышлениях ошибаюсь.
Почему количество новых тайлов в 99.99% случаев будет равно нулю, я не понял. Хотелось бы наоборот!

[ELITE]

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

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

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

[mountcat]

Я хочу чтоб при склейке настройки цвета (гамма и контраст) работали не только для BMP. Дело в том. что в ВИРТУАЛ ЗЕМЛЯ они химичат с гаммой, скачал, а соотвествия с оригиналом нет, приходится корректировать гамму, а склеивать я привык в джипег, бмп-шки много времени на ораб занимают и жрут мемори много.

Присоединяюсь. При просмотре на КПК снимки по-любому всё делать светлее приходится, иначе не видно... Опция есть, но для JPG не работает...

[Parasite]

Присоединяюсь. При просмотре на КПК снимки по-любому всё делать светлее приходится, иначе не видно... Опция есть, но для JPG не работает...

Что мешает свести в БМП, а потом конвертнуть в жпег? Это можно делать вот прямо сейчас, а не обвешивать программу совершенно посторонними и нужными единицам фишками (которые, более того, элементарно выполняются вот прямо сегодня и намного более лучшими путями и инструментами, чем это потенциально сможет делать САС даже в отдаленном будущем)?

Напомню, что основная задача САСа - вовсе НЕ редактирование гаммы у больших битмапов.

а нельзя ли реализовать систему интелектуальной загрузки (на основе простейшей нейронной сети) тайлов

Прикольно.
См.выше.

[VMatveev]

Есть предложения. САС ведь худо-бедно читает кэш этого GoogleEarth-a, а ведь в GE на многие районы просто прорва "исторических" снимков, и очень часто возникает ситуация, когда хороший предыдущий снимок известные обкурыши перекрывают фуфловым новым снимком, а в GM "исторические" снимки недоступны. Поэтому хочется чтобы по возможности в САС добавили выбор версии снимков при чтении кэша GE. Еще хочецца, чтобы при перепроецировании GE-шных тайлов применялось сглаживание какой-нибудь интерполяцией. Спасибо.
Надеюсь это не "совершенно посторонние и нужные единицам фишки" © "Parasite"

А работа c GE-шными данными через GeoCacher например, очень неудобна. Похоже на "с аквалангом, в гамаке, и стоя"

[vdemidov]

К сожалению, в последней версии GE поменялся формат хранения тайлов в кэше. Раньше были jpg, а сейчас фиг знает что. До тех пор пока не будет понятно что с этим "фиг знает что" делать, никаких перспектив работы SAS.Планеты с кэшем GE напрямую нет. Только через GeoCacher.

[Bigbambr]

Как по одному щелчку (одной точке) предлагается определять участок трека (у которого должны быть как минимум начало И конец (две точки))?

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

[Parasite]

Как по одному щелчку (одной точке) предлагается определять участок трека (у которого должны быть как минимум начало И конец (две точки))?

Каждая точка записана в файле. Поэтому время ее прохождения известно.

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

Я имею ввиду замер скорости между точками, ближайшими к той, в которую я ткнул.

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

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