Экспорт и импорт X Y Z

[zed]

чем меньше знают про закрытый формат - тем дольше он проживет в неизменном виде

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

я лично заинтересован в НЕраспространении формата в широкий доступ

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

[Parasite]

чем меньше знают про закрытый формат - тем дольше он проживет в неизменном виде

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

Как зашифруют - так и расшифруется. Они это уже не раз меняли.

я лично заинтересован в НЕраспространении формата в широкий доступ

А я лично заинтересован в противоположном...

Ну так лично я - не против Вашей заинтересованности. Удачи.

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

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

А так, знания пропадают даром, что говориться ни себе, ни людям.

Заблуждение.

[zed]

Как зашифруют - так и расшифруется. Они это уже не раз меняли.

Со времён Гайи, алгоритм шифровки всё тот же, хотя прошло уже наверное года 4? И даже такая серьёзная утечка информации в сеть, не заставила их что-то радикально менять, чтоб гайя не смогла работать. Они прибегли лишь к угрозам и возможно, подкупу. Правильно, это ведь намного проще, чем заново изобретать велосипед.
Так что это ваше "Они это уже не раз меняли" не очень понятно.

[Parasite]

Они прибегли лишь к угрозам и возможно, подкупу. Правильно, это ведь намного проще, чем заново изобретать велосипед.
Так что это ваше "Они это уже не раз меняли" не очень понятно.

На это лишь скажу, что алгоритм как минимум выделения ключа из ответа сервера разнится от версии к версии клиента, и от версии к версии от становится запутаннее (а сам ответ сервера - длиннее по размеру и со введением все большего и большего числа "сторонних" данных в теле ответа). Я понимаю, что это может быть не очень понятным - но это есть, и с этим приходится жить.
PS: заметьте, что вышесказанное относится к началу начал работы с ГЕ (второй ответ сервера от начала работы). Дальше, разумеется - больше, но уже выходит за рамки обсуждения данной темы.

[zed]

Вообще-то, я говорю не про ответы сервера, а про файлы: картинки/рельеф и проч. - они зашифрованы, а ключ для дешифровки каждый раз передаётся клиенту с файлом вида hl=ru-RU&gl=ru, и ключ этот, от версии клиента не зависит, и всегда одинаковой длины 1024 байт, и всегда в нём одни и те же байты (кроме седьмого - в нём версия текущей базы). Т.е. и алгоритм и ключ шифрования из года в год всё те же.

заметьте, что вышесказанное относится к началу начал работы с ГЕ (второй ответ сервера от начала работы)

ну, поскольку все эти файлы качает сам ГЕ, то нас как бы мало интересуют их запросы/ответы. Поэтому, как бы они не путали сам процесс авторизации, мы прекрасно можем получить доступ к файлам, до тех пор, пока гугловцы не решаться на смену алгоритма шифрования файлов. О чём я, собственно, и говорил.

Что касается рельефа, то данные по нему вполне можно взять в свободном доступе с ftp у NASA. Единственный вопрос, на сколько точнее (и точнее ли) данные по рельефу у гугла, поскольку на ftp существует 2 версии точности рельефа: 30 м. и 90 м.(подробнее про SRTM).

[zed]

Кстати, предлагаю встроить/подключить в SAS.Планета слой Рельеф. Данные по высоте, можно загружать у NASA, вот пример запроса http://worldwind25.arc.nasa.gov/wwelevation/wwelevation.aspx?T=srtm30pluszip&L=5&X=328&Y=230 в итоге загружается zip архив с файлом Y_X.bil внутри. Формат BIL - стандартный, и я думаю проблем с ним не будет. А информацию о высоте, в SAS можно отображать рядом с координатами в строке статуса, в зависимости от положения курсора мыши.
Для примера, прикрепил файл рельефа NASA (загруженный по приведенной ссылке).

[Parasite]

ключ для дешифровки каждый раз передаётся клиенту с файлом вида hl=ru-RU&gl=ru

На самом же деле передается файл dbRoot.v5 с переменной длиной и меняющимся контентом от версии к версии, и это второй файл в процессе авторизации оф.клиента (и он содержит много чего еще).
Никакие hl=ru-RU&gl=ru в чистом виде между клиентом и сервером НЕ передаются (по состоянию на год назад и ранее - когда я последний раз занимался вопросом эмуляции клиента ГЕ). Сейчас вряд ли чего изменилось, судя по тому что старые клиенты - работают, как и эмуляция оных.

PS: просьба дать URL на файл "hl=ru-RU&gl=ru", если таковой существует.

[zed]

Ну да, раньше он был просто dbRoot.v5, а сейчас в зависимости от региональных настроек это: hl=ru-RU&gl=ru (или hl=ru-RU&gl=by - для Беларуси, и т.д.)
URL вот такой: http://kh.google.com/dbRoot.v5?hl=ru-RU&gl=ru (что интересно, загружается даже браузером без всяких авторизаций).
Этот файл содержит ключ (1024 байт) + xml данные (зашифрованные и заархивированные). Вот здесь лежит чисто xml в zip архиве: hl=ru-RU&gl=by.zip. Можно в блокноте посмотреть, что же это за "...много чего еще", и станет понятно, почему он переменной длины (в зависимости от версии баз, но никак не от версии клиента).
К авторизации этот файл отношения не имеет, т.к. клиент нормально работает даже не получив этот файл.

[Parasite]

раньше он был просто dbRoot.v5, а сейчас в зависимости от региональных настроек это: hl=ru-RU&gl=ru (или hl=ru-RU&gl=by - для Беларуси, и т.д.) URL вот такой: http://kh.google.com/dbRoot.v5?hl=ru-RU&gl=ru

Ну дак это просто параметры, передаваемые гуглесерверу при запросе dbRoot.v5.
При их игнорировании всё столь же прекрасно работает, а если нет разницы - то зачем передавать серверу больше?

Можно в блокноте посмотреть, что же это за "...много чего еще"

Дак я знаю, "что еще" там лежит.
Вопрос был не про "что еще", а про ключ. По состоянию на "год назад" было следующее:
1. клиенту выдавался разный dbRoot в зависимости от запроса клиента (и оный dbRoot был РАЗНОЙ длины в разных случаях, разница была от 15Кб в случае старых версий до 48Кб в случае новых)
2. последовательность нахождения ключа в этих разных dbRoot была разной (банальная перестановка байт в другом порядке, но достаточно попортившая жизнь в свое время).
3. dbRoot тянулся только под авторизацией (а при авторизации передавалась версия клиента - в ответ на что сервер и засылал тот или иной dbRoot). При попытке протягивания его до авторизации была стандартная 404.

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

клиент нормально работает даже не получив этот файл.

Заблуждение.
Оторви от клиента существующий кэш (в который dbRoot тоже складируется, причем в первую очередь - еще ДО первого тайла), запрети dbRoot.v5 на файрволе и убедись в своей ошибке. Клиент НЕ МОЖЕТ нормально работать без ключа - а ключ передается как раз в составе данного файла.

[zed]

...то зачем передавать серверу больше?

Мы говорим о разном? Я привел URL запроса клиента-серверу, как это существует на данный момент. У вас есть какой-то "клиент" в котором вы можете управлять тем что передавать а что нет?

Можно в блокноте посмотреть, что же это за "...много чего еще"

Дак я знаю, "что еще" там лежит.

Не сомневаюсь. Фраза относилась к тем, кто не знает и кого заинтересовало - что же там такое лежит?

Вопрос был не про "что еще", а про ключ. По состоянию на "год назад" было следующее..

По состоянию на сегодня - всё стало проще, и заморочек с ключом нет. Ваши знания устарели.

Оторви от клиента существующий кэш...

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