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

DCT
Возврату нет)
Нажать на импорт тоже вроде не долго. А импортируя в базу планеты не обязательно удалять kml, конечно лишнее размножение, но зато на много быстрее скорость обработки. И когданибудь будет экспорт в kml.
Не нравится мне так как было раньше - из-за очень долгой загрузки KML файла. В таком варианте можно работать с небольшими kml а когда речь заходила о тойже бланковке в KML программа явно не справлялась.

Цитата:

Возврату нет)

Вопрос не в том, чтобы вернуть "как было" (включая библиотеку KML и прочие фичи), а в том, чтобы добавить новый zmp слой у которого в params.txt прописать Ext=.kml и "тип кэша"="все в одной папке". (это было бы прикольно - можно будет наклонировать слоев типа KML-достопримечательности, KML-трэки и включать их по отдельности)


Цитата:

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

Так это проблемы пользователей: KML-бланковка всего мира - это была явная глупость. У меня грузлся 1,5МБ KML с ~1200 точек - чуток подтормаживало, но не жаловался. )

DCT

Цитата:

можно будет наклонировать слоев типа KML-достопримечательности, KML-трэки и включать их по отдельности

а сейчас нельзя? сделай по образу и подобию слоя вики или панорамио

Цитата:

>>можно будет наклонировать слоев типа KML-достопримечательности, KML-трэки и включать их по отдельности

>а сейчас нельзя? сделай по образу и подобию слоя вики или панорамио

для этого нужно чтобы программа брала всё из одной папки а не искала файлы *.KML по уровням...

zporuchik

Цитата:

сделай по образу и подобию слоя вики или панорамио

о том и речь чтобы подключить KML как пользовательский слой по образу и подобию вики или панорамио
но:

Цитата:

для этого нужно чтобы программа брала всё из одной папки а не искала файлы *.KML по уровням...

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

Но преимущества очевидны: можно наделать вручную кучу тематических слоев (достопремечательности, трэки, посты ДПС ... кому что нужно!) - при этом будет очень легко делиться отдельными объектами=файлами с говорящими названиями (что сейчас с sml вообще невозможно).
Кстати, GE и Yandex пошли по похожему пути с информационными тематическими слоями - IMHO это правильно.

TheGarl
DCT

Цитата:

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

я ж еще в начале (когда подключали слой вики и панорамио) говорил, что нет смысла качать по слоям, т.к. получается размножение - точка с фотками. что на 10м точка, что на 19м - точка.

zporuchik
А какже еще качать? Если сервис отдает по слоям и по тайлам?

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

az52
Цитата:

А зачем же запускали?)
Теперь надолго, у меня около месяца держался.

Цитата:

Стандартный ответ. Токо зачем на месяц то банить, гугл и тот всего на сутки.

Бан прошел. 12дней

zporuchik
тогда поломается вся тайловая "архитектура" программы.

RussellMur
Это радует, подобрели)

zporuchik
С Wikimapia и Panoramio тайловая структура жизненно необходима - на нижних слоях там столько объектов, что если одну область объединить в один KML, то никакой GE его не потянет... Поэтому у обеих сервисов есть лимит на количество объектов в тайле (объекты с более низким рейтингом идут в более глубокий слой).

az52
Но кэш "все в одной папке" нетормозит, если точек меньше нескольких тысяч. Причем, если дать возможность раскидать по тематическим слоям свои KML-ники - то тормозов в обычных ситуациях (90% пользователей) не будет.

С тех пор как отпала возможность узнавать набор снимков у DG обновилась Москва, теперь можно загружать снимки 5/8/2008 по tid 7015679895. Это бы все ничего, да только по умолчанию грузится старый снимок, т.е. теперь не всегда можно узнать о доступности новых снимков( В связи с этим все усилия теперь кладу на поиск возможности узнавать набор снимков) Надеюсь конечно и на вашу помощь
Сейчас прорабатываю terraserver.com, как выяснилось он использует снимки DG в том числе и 49 стека, и показывает даты снимков и tid, но там все давольно криво, во первых - показывает все tid только выбранной даты (при этом на одну дату попадают по какой то причине снимки разных дат) и при этом может вообще снимок не той даты показывать. Список доступных снимков нужен ну просто как воздух!)

az52

Цитата:

Сейчас прорабатываю terraserver.com

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

Цитата:

и при этом может вообще снимок не той даты показывать

Цитата:

на одну дату попадают по какой то причине снимки разных дат

Мне такое попадалось и на DG, например, если они склеили мозаику города из снимков разных дат и прописали им всем наименьшую дату. Посмотрел на terraserver.com - у них действительно попадаются неправильные даты снимков.
пример: мозаика из снимков 2008-05-21 и 2008-07-22, под ними снимок 2008-06-13 (грузится по tid, в списке отсутствует). SAS-DG показывает на всей мозаике 2008-05-21, terraserver на тоже 2008-05-21 + еще дополнительный слой 2008-07-22, но на этом слое реальный снимок 2008-06-13
Вывод: единственный способ надежно установить дату снимка - сопоставить вид с превью из каталога.
Насчет доступных снимков с terraserver.com: список снимков там больше, НО terraserver.com не видит часть выложенных на DG снимков (((

DCT

Цитата:

Вывод: единственный способ надежно установить дату снимка - сопоставить вид с превью из каталога.

Надо найти способ загружать как раньше, один tid - одна дата. И тогда будет точно, а когда начинается объединение разных tid в один слой вот тут начинаются касяки.
Вот еще что нашел, если вместо img в ссылке на тайл поставить info, даст xml с инфой, токо инфа какаято ненужная - провайдер да разрешение, блин хоть бы дату дали.

Добавлено:

Цитата:

Насчет доступных снимков с terraserver.com: список снимков там больше, НО terraserver.com не видит часть выложенных на DG снимков (((

Пример плиз

[more=Например...] точка E36°19'32.80" N49°45'49.49"
_ttp://www.terraserver.com/view.asp?cx=307611&cy=5515970&proj=32637&mpp=2.5&pic=img&prov=gx19&stac=7065&ovrl=-1&drwl=-1

terraserver показывает тут 2 снимка 5/21/2008 и 7/22/2008 (на самом деле правильные даты 2008-07-22 и 2008-03-28 - видно, что второй снимок весенний!)

Но тут есть еще один снимок 2008-06-13 _ttp://www0.globexplorer.com/tiles/img?p=mercator-spheroid&coll=&tid=7015880981&n=1&l=49&t=a&e=0&key=6sdickehgixpwemrnsicjwldxisjenchfieolxdfsgplsdfmkskkoidstqlmndjw&xi=19690&yi=11146&z=15

Причем, самое прикольное, что километрах в 10 восточнее terraserver видит край снимка 2008-06-13 и правильно определяет его дату, но он не видит, что он есть и в этой точке тоже!
[/more]

Все!!!
Совместно с zporuchik мы решили проблему.
В следующей версии будет все как было когдато)


Добавлено:
Блин столько снимков 2008 года появилось за это время

Добавлено:
Версия 90601 (от 01.06.09)
1. Наконец то вернул возможность смотреть ВСЕ доступные снимки DigitalGlobe (благодарность zOn, мы с ним посидели маленько и разгадали что DG там пишет в encrypt). Возможно ф-я проработает не долго, но если что, проблема решаема.
2. Исправил неверное определение к-т южного полушария для проеции меркатор на эллипсоиде.

az52
Браво! Теперь и в моем примере все корректно показывает!
(значит в том случае виноват terraserver: неправильно обрабатывает ответ со слоями от image.globexplorer.com)

Цитата:

значит в том случае виноват terraserver: неправильно обрабатывает ответ со слоями от image.globexplorer.com

Именно, они мытаются почему то по первым 3-м (ImageAtlas) или первым 4-м (terraserver) цифрам tid систематизировать снимки по датам, хотя эти 3-4 цифры совпадают порой у снимков совершенно разных дат (я так понимаю объединение идет по пространственному признаку, т.е. упрощенно, если один снимок покрыл одну половину города а другой - другую то их объединяют).

Цитата:

Версия 90601 (от 01.06.09)
1. Наконец то вернул возможность смотреть ВСЕ доступные снимки DigitalGlobe (благодарность zOn, мы с ним посидели маленько и разгадали что DG там пишет в encrypt). Возможно ф-я проработает не долго, но если что, проблема решаема.

az52 ух ты! супер обновление! по Москве снимки действительно сентябрь 2008!

NPC

Цитата:

по Москве снимки действительно сентябрь 2008

Там несколько полосок (май и сентябрь) 2008-го года, которые удобнее всего грузить по coll=701. Но на всю Москву снимков 2008-го года пока нет (отсутствует восточная часть). У меня такое впечатление, что они сейчас собирают мозаику-обновление Москвы для одного из популярных сервисов.
кстати, там где несколько снимков лежат друг на друге - изменяя порядок перечисления tid можно менять порядок их склейки
на примере Москвы:
tid=7015881609,7015679895 загрузит майский снимок (70156...), "поверх" сентябрьского
tid=7015679895,7015881609 (в таком порядке грузит по умолчанию coll=701&tid=) загрузит сентябрьский снимок, а по его краям майский

az52
это замечательно
а может доработать механизм выбора тид? как-то больно муторно ручками его прописывать?
может в каком-либо окошечке ставить галочки (и перемещать для создания последовательности) у нужных тид, а САС их бы сам писал в запрос

Добавлено:
давай уже заодно у людей узнаем - надо ли прикручивать http://navteq.com ?

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

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

Добавлено:

Цитата:

а потому наибольшую ценность навтек может представлять в качестве гибридного слоя

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

подождем, т.к. навтек пока на стадии бетты

Добавлено:
az52
шапку на радостях забыл исправить?

Добавлено:

Цитата:

а может доработать механизм выбора тид?

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

Добавлено:
в идеале (на данный момент, а потом еще чонить придумаю) надо делать + к просмотру списка, еще ф-wb. просмотра доступных тид.
т.е. я выбираю "ПОСМОТРЕТЬ доступные тайлы" и в окошке у меня данный тайл с разными тид и с подписью.
а то вот не совсем понятно какой тид лучше август 2008 или ноябрь 2008?

Добавлено:
az52

Цитата:

в идеале (на данный момент, а потом еще чонить придумаю)

я ж говорил, что придумаю
вот в ГЕ есть отображение границ снимков (тид) и там можно запросить предпросмотр его. Грузится картинка превью с ДГ (помоему), в запросе присутствует его тид, а также (видимо) по запросу инфо можно получить эти самые границы ТИД.

Добавлено:
Ну, блин, народ!
Вы чо? Спите? У меня тут театр одного актера?

zporuchik
Спокойствие, только спокойствие!

Цитата:

вот в ГЕ есть отображение границ снимков (тид) и там можно запросить предпросмотр его. Грузится картинка превью с ДГ (помоему), в запросе присутствует его тид, а также (видимо) по запросу инфо можно получить эти самые границы ТИД.

а) Там выдается только CatalogID, он не совпадает с tid, и по всей видимости между ними нет никакой связи (((.
б) Более того, DG зачастую выкладывает сцену неполностью - так что реальные "границы ТИД" можно узнать только вручную (.

О!
Чот новенькое: http://code.google.com/intl/ru/apis/earth/

Добавлено:
а это что?
http://www.terrametrics.com/truviewer/

Добавлено:
Эх!
Вот до этого бы добраться: http://www.europa.uk.com/gallery.php

zporuchik
(продолжая про DG) Алгоритм нахождения границ tid существует: при попытке грузить тайлы за границей будут грузиться черные тайлы фиксированного (маленького) размера. Методом последовательных приближений можно найти все 4 границы. НО сцена состоит чаще всего из многих tid, чаще всего их номера отличаются на единицу, но в мозаиках мне также встречалась жуткая мешанина из разных снимков с близкими (в пределах нескольких десятков) tid.
Лучше вариант: таким же методом в соседних точках посылать запрос на список снимков и создавать список всех Tid для одной даты. Но это при активном использовании могут забанить.


Цитата:

ПОСМОТРЕТЬ доступные тайлы

+1. Это можно было бы прикрутить через движок IE, который заюзан при показе sml и kml.

Добавлено:
DG такими тэмпами выкладывает обновления, что через год разобраться в коллекции снимков будет нелегко. Уже сейчас приходится каждый снимок DG выкачивать как отдельный zmp-слой. Поскольку Google, KS, VE, Yh, Ya тоже обновляются, скоро надо будет к SAS приделывать функцию "выдать информацию о скачанных кэшах для этого места"

DCT
ссылка на превью ГЕ:
http://archive.digitalglobe.com/archive/showBrowse.php?catID=10100100080C5801

всё же его както можно вычислять наверно
т.к. ид соседних снимков с одной датой идут последовательно catID=10100100080C5801, catID=10100100080C5802

казалось, бы, что где то на Земле должен быть catID=10100100080C5803, но его нет.
это наводит на мысль, что в этой цифре есть инфо о месте и времени, НО...
слишком мало меняющихся цифр:
101001000 - не изменно
80C580 - изменяется (HEX)
1 - номер снимка "сессии" в HEX. полосу снимков с одной датой длиннее 16 не нашел, т.е.
начало
2008-08-19
Catalog ID: 1010010008747201
Cloud Cover: 1%, Quality: 99

а конец
2008-08-19
Catalog ID: 101001000874720F
Cloud Cover: 2%, Quality: 99

zporuchik
Несколько фактов:
- один и тот же снимок может попасть в разные Tid (в состав мозаики и "сам по себе") - tid у них полностью различаются.
- если сцена выложена неполностью, то оставшийся кусок с DG никакими манипуляциями не загрузишь (пытался +-1 Tid)
Что можно попробовать покопать (посмотрю уже завтра):
- у сцены может увеличиваться tid либо на север, либо на юг. Надо будет сравнить, как меняется catID у такой сцены.
- Где то мне попадалось, что длинная сцена состояла из нескольких последовательных снимков (у них различались catID на единицу), но эти снимки шли "внахлест" - в месте пересечения меняя tid можно было грузить (метров 200-500) либо конец первого, либо начало второго снимка - надо посмотреть, как при этом менялись Tid.

Добавлено:
Кстати, с DG можно грузить превью и в лучшем качестве (при этом грузится вся серия последовательных снимков, каталожный номер заканчивается на 00) - для той картинки это будет
http://browse.digitalglobe.com/imagefinder/showBrowseImage?catalogId=10100100080C5800&imageHeight=natres&imageWidth=natres
Если не будет грузить, зайти сюда _ttp://browse.digitalglobe.com/imagefinder ввести ID, и перегрзить http://browse.digitalglobe.com/imagefinder/showBrowseImage?catalogId=10100100080C5800&imageHeight=natres&imageWidth=natres (там по видимому по кукисам открывается сессия, которая если timed-out, то ссылки http://browse.digitalglobe.com/imagefinder/showBrowseImage?catalogId= перестают работать)

Добавлено:
2ALL
Кстати, самый полный и удобный каталог для просмотра превьюшек всех Hi-Res спутников - http://search.kosmosnimki.ru/. Если ссылка оттуда на превьюшку идет через DG, то надо в конце прописать &imageHeight=natres&imageWidth=natres - качество превьюшки заметно улучшается ))).

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

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

DCT

Цитата:

один и тот же снимок может попасть в разные Tid (в состав мозаики и "сам по себе") - tid у них полностью различаются.

Опять же, к-ты пожалуйста)


Цитата:

самый полный и удобный каталог

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

Все идем в москву и ставим параметр ls=22
Это не WorlView-1? Судя по разрешению и недавости добовления он самый! Тогда вообще интересно, и скоро придется задумываься как узнавать tid для 22 стека)

Цитата:

и скоро придется задумываься как узнавать tid для 22 стека)

может уже пора?

Цитата:

может уже пора?

Через terraserver не получится, у них там походу доступ только к 19 и 49