» SAS.Планета (часть 2)

az52

Цитата:

Если я верно понял, то проблема решается просто - установить на время работы программы принудительно символ-разделитель, например, запятую, системной функцией WinAPI (какой точно, не помню, но могу попробовать вспомнить )


Это будет не совсем корректно.

Возможно, да. Сегодня поинтересовался на этот счёт у коллеги, что решил в одном из проектов аналогичную задачу - правда, там чуть не так было: в нужный момент (например, перед сохранением файла или перед его открытием) модифицировалась глобальная переменная DecimalSeparator (это фича Borland C++/Delphi). Вероятно, это корректнее. Но это так, размышления просто к слову. Возможно, в Вашем случае ситуация будет несколько иная, тут, разумеется, Вам виднее.

Цитата:

в нужный момент (например, перед сохранением файла или перед его открытием) модифицировалась глобальная переменная DecimalSeparator (это фича Borland C++/Delphi)

Я также делаю, что то видать свернул) Посмотрю.

что прячется за
encrypt=YmxlPGhv Z24naGU8 YmA1MTU3 ZWUsY2Ng NCw1MzRi LDk4Nzcs MWA0NDJk MWVkYzJg J2BxcWhl PDEzMTAx MVInbXI8 NTgneWI8 MjMvNTYz OTI4MjQ0 NTc5OSd4 Yjw3MS8x MzI3ODc5 OTA4OTIy J2xxcTw5 J2h2PDMz ODAnaGk8 MzM4MCdk eXVkb3Vy ZHU8YG1t
для l=42 возможно посмотреть tidы?

RussellMur
Закодированный запрос, Base64 где каждый четный байт + 1 каждый нечетный - 1 (вроде так). Можете раскодировать, но пожалуйста не выкладывайте нигде раскодированный запрос, т.к. это может привести к прикрытию ключика (как уже было с другими). Можно, еще проще в исходниках посмотреть. Я уверен. что для 42 ничего особенного не будет.

Там где я смотрел, на 42-м снимков меньше (нету части старых), чем на 49-м. Но 42-й интересен тем, что на нем более новые снимки идут поверх старых по умолчанию (а на 49-м для Москвы новые лежат под старыми).

Vista SP2: многопоточка работает на ура, качаю счас в 5 потоков последней версии

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

сохраняется ли это marks.sml ?

можно ли по правой кнопке в меню треков\точек\областей выводить эту доп.информацию в список? аля информация о картах DG?

для чего это нужно:
если поход многодневный легко искать место ночёвок. места перивалов и т.п.

как вариант делать секции градиентными по дате но это имхо изврат.

так же нужно учитывать что есть трэки в которых эта доп.инфа отсутствует(забита пробелами)

спасибо за внимание!

По поводу:
"Там где я смотрел, на 42-м снимков меньше (нету части старых), чем на 49-м. Но 42-й интересен тем, что на нем более новые снимки идут поверх старых по умолчанию (а на 49-м для Москвы новые лежат под старыми)."

Сам счас пользую 42 слой там снимков больше кроме того есть еще такие фишки как:

1. После tid можно вставлять несколько снимков через запятую, при том их порядок имеет значение, таким образом можно делать разные перекрытия снимками и в итоге добиться лучшей картинки, я таким образом избавился от облака над курганом:
mercator-spheroid&coll=&tid=7016122383,7016122384,7016122241,7016122242&n=1&l=42& +

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

2. Таким же образом через запятую можно чередовать и подбирать очередность слоев коллекции, то бишь:
mercator-spheroid&coll=701,714& и mercator-spheroid&coll=714,701& будут по разному отображаться

Если кто еще не в курсе workdao сделал шикарнейший разбор по покрытию разных стеков, и о чудо, 42 стек содержит "кучу" снимков которых нет в 49!

workdao
1,2 - уже известны данные фишки.

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

workdao
Кто ж их упомнит все)

пока что мне очень интересна простукивалка тайла на номер снимка, поскольку на 42 слое не все ID снимков отображаются...
и кто нить пробовал найти закономерность между названием снимка такого формата ID=1010010007D6D005 и 7016122241 ?

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

Цитата:

пока что мне очень интересна простукивалка тайла на номер снимка, поскольку на 42 слое не все ID снимков отображаются

Да, хорошо бы, но ключик существующий по которому находятся снимки для 49 стека не поддерживает 42 (может вру, чуть попозже проверю точно точно не поддерживает).

Цитата:

кто нить пробовал найти закономерность между названием снимка такого формата ID=1010010007D6D005 и 7016122241

Пробовали, недавно здесь обсуждали, связи не нашли.

Цитата:

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

) Вот вы тоже сколько нового нашли, и все разбросано по отдельным постам, так и у меня. Надо как то систематизировать, все руки не дойдут.

Добавлено:
workdao
Так как вы без ландсат загружали?

не понял про это
Так как вы без ландсат загружали?
что именно?


Добавлено:
15 слой на 42 стеке без "зеленки" грузится... а из него уже и формировал остальные слои

Вот примерное расположение снимков стека 42 в России:

Как видно снимки распологаются только в центральной сибири, немного расстраивает( Но покрытие там очень существенное.

az52
Знакомый случайно обнаружил ещё одну недоработочку, и снова связанную с региональными настройками системы При операции экспорта выделенной области в файл (последняя вкладка), если указано упаковать в ZIP, имя ZIP-файла формируется автоматически, и в конце имени оно содержит системную дату. А дата для этого берётся точь-в-точь в том формате, в каком она установлена в региональных настройках Windows. И если она стоит как по умолчанию для русской ОС, ДД.ММ.ГГГГ, то всё получается нормально. А вот стоит её установить в формат ДД/ММ/ГГ (как у знакомого в системе и было), сгенерированное имя файла тут же становится недопустимым для файловой системы, и операция создания архива глохнет. Поправьте, пожалуйста.

однако нефтяной регион фоткали

workdao

Цитата:

Сам счас пользую 42 слой там снимков больше кроме того есть еще такие фишки как:

Вам повезло, у меня на 42 снимков меньше.

Кстати, а какие tid у снимков с "недоступными" датами?

Я недавно тоже сканировал другие слои, но ничего интересного не нашел:

Цитата:

Результаты по Москве:
список слоев, где что то есть (сканировал 1-60 с пустым coll, в скобках одинаковые побайтно файлы)
Hi-Res: (1 19 23 41 49 52 53) (7 17) 33, 42, 22
Ландсат: (26 28 32 50)
-----
Какие снимки на каких слоях (из "рабочих") можно быстро проверить с помощью [more=команды:]
for %i in (1,19,23,41,49,52,53,7,17,33,42,22,26,28,32,50) do wget "http://www0.globexplorer.com/tiles/img?p=mercator-spheroid&coll=&tid=&n=1&l=%i&t=a&e=0&key=6sdickehgixpwemrnsicjwldxisjenchfieolxdfsgplsdfmkskkoidstqlmndjw&xi=XXX&yi=YYY&z=ZZ" -O %i.jpg
Где XXX, YYY, ZZ скопировать из ссылки, масштаб желательно брать 14-й
Скачать Wget http://users.ugent.be/~bpuype/cgi-bin/fetch.pl?dl=wget/wget.exe
[/more]

Еще мне кажется, что на l=53 может быть что то ценное (для моих мест там не меньше снимков, чем для 49-го, значит, где то может быть и больше )

az52
А из каких стэков (1 19 23 41 49 52 53) (7 17) 33, 42, 22 нельзя получить даты всех снимков? Может там огранизовать поиск для разных регионов?

Вот к этим стекам есть доступ по нынешнему ключику:
1, GlobeXplorer Premium Stack
2, USGS 1:24k Topo Stack
4, GlobeXplorer Premium Portal Stack
6, APUSA Stack
7, DigitalGlobe Stack
11, CitiPix by GlobeXplorer ODI stack
13, DOQQ Stack
14, I-cubed Image Stack
18, CitiPix by GlobeXplorer ODI plus RDI stack
19, WMS Premium
20, National Map Data Stack
30, Sanborn Stack
49, Country Coverage

А вообще еще известны названия для следующих стеков:
1, GlobeXplorer Premium Stack
2, USGS 1:24k Topo Stack
3, GlobeXplorer Basic Stack
4, GlobeXplorer Premium Portal Stack
5, GDT Stack
6, APUSA Stack
7, DigitalGlobe Stack
10, GlobeXplorer Standard Stack
11, CitiPix by GlobeXplorer ODI stack
13, DOQQ Stack
14, I-cubed Image Stack
15, I-cubed Map Stack
16, STDB Demo Stack
18, CitiPix by GlobeXplorer ODI plus RDI stack
19, WMS Premium
20, National Map Data Stack
21, NavTech Accuracy Data Stack
22, NavTech Propietary Data Stack
26, GlobeXplorer Premium 3D Data Stack
27, NAIP Stack (Аэрофотосъемка в рамках Национальной Сельскохозяйственной Программы, National
Agricultural Imagery Program)
28, EarthSat Stack
30, Sanborn Stack
32, Current Events Stack
33, GlobeXplorer Deluxe Stack
34, GlobeXplorer Deluxe Portal Stack
41, DigitalGlobe owned
47, DIBU Data
49, Country Coverage

Добавлено:

Цитата:

Еще мне кажется, что на l=53 может быть что то ценное (для моих мест там не меньше снимков, чем для 49-го, значит, где то может быть и больше

Да, мне тоже кажется что должно быть чтонить но не факт что по России. Надо искать.

если вы так много знаете, может поможете разгадать снимоки для местности?
48.9976 27.7190

по запросу у DG только 3751072908,1999-01-01,"MDA EarthSat",-1,15.0,"Color",100000.0

NPC
Нету ничего(

az52
Итого, скрытые сюрпризы могут быть еще на 7-ми уровнях: 17 22 23 33 41 52 53 )

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

az52 вот почему закачка утекает

В ближайшее время планируется выпустить патч для линейки KAV/KIS 2010 (9.0.0.459).

В патч будет входить драйвер klif, исправляющий проблему с утечкой памяти, приводящей к нехватке памяти для приложений и, как следствие - порче графического GUI ОС.
Просим тех, кто столкнулся с подобной проблемой проверить данное исправление.

NPC
Думаеш по той же причине?

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


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

из плюсов:
ну перво наперво - будет очень наглядно особливо в горной местности
экономия трафика соответственно.


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

в общем как-то вот так. генератор идей блин.

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

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

к примеру создал я kml территории c digitalglobe (изменив относительную ссылку на ту куда я в дальнейшем залью кеш с тайлами) затем залили сам кеш на http сервер, подгрузил kml файл в гугле ефф и радуюсь просмотром нужной мне карты DG в 3D

TheGarl
Лучше доработать парсер кмл чтоб он понимал картинки.


Цитата:

к примеру создал я kml территории c digitalglobe (изменив относительную ссылку на ту куда я в дальнейшем залью кеш с тайлами) затем залили сам кеш на http сервер, подгрузил kml файл в гугле ефф и радуюсь просмотром нужной мне карты DG в 3D

Чет я не понял.

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

workdao
Все равно не понял) Можно с самого начала.