Проблема системы координат и проекции

[vdemidov]

Короче, пока писал, понял - действительно проекции, как указал Демидов в том баге, разные, а при смене карты SAS планеты, по всей видимости, запоминает пиксельные координаты выделенного куска, а они будучи пересчитаны в геодезические по формулам новой проекции,не могут дать точно таких же результатов, т.к. формулы проекции уже другие и , хоть, и результат , теоретически ДОЛЖЕН быть такой же, но за счет вычислительных ошибок округления вылезают отличия. Видимо, это алгоритмическая ошибка - для точности перед переходом к новой СК (и или проекции) нужно запоминать не пиксельные координаты , а геодезические, чтобы не пересчитывать.То же самое касается и меток.

Глупость написали. Просто не забываем, что привязка делается для растра. Вот отсюда и вылазит разное округление. Тоесть заданный точно координатами прямоугольник округляется до пикселей. После чего считаются координаты этих пикселей. Еще раз повторяю, что это не баг.

[PavelML]

2 PavelML » С Новым годом.
Спасибо за ответ, но в нем много смутного.
Отвечая на вопрос 1) - почему меняются геодезические координаты выделенного куска в далеком после зпт знаке, Вы указываете на неортотрасформированность( т.е. на не выправленность снимков с учетом кривизны рельефа и угла съемки), но если бы причина была в этом , то разница была бы метры и десятки метров, а там итоговая разница в 2см. Вы посмотрите вложенный пример в предыдущем моем посте. Там разница в 6-м знаке после зпт. Да и вообще сравните yandex и google maps по рисунку на мостовой, скажем у памятника Петру у Исаакиевского собора в Питере, что хорошо видно - там нет никаких поднятых зданий. Короче, Вы стали объяснять, почему google и yandex maps так отличны по координатам, но и в этом случае Ваш ответ не подходит,т.к. отличие yandex от google несколько метров,а не 2 см.

Я извиняюсь, что не стал обсуждать тему несовпадения одних и тех же снимков из разных источников, просто подумал, что там особо обсуждать нечего.
Существует первичный источник (скажем NASA, ну я не знаю, DigitalGlobe) и первичная привязка, которая передается потребителям в том виде округления координат, который был скажем, проплачен. То есть подороже - поточнее, подешевле - погрубее. Потом первичный потребитель может перепродать материал еще кому-то - тоже сотворив что-нить с координатами привязки. И наконец - конечный потребитель решает свои проблемы производительности сервиса, выбирая уровень компромисса между скоростью и точностью. На все это могут накладываться несоотвествия при преобразованиях координат, если сервис включает в себя какие-то другие исходные материалы. Плюс ко всему - я не исключаю что кто-то, скажем в яндексе - вполне может получаемые снимки перепривязывать и вручную - для большей точности. Или наоборот - сдвигать если фсб поругает.
В любом случае эти погрешности на порядок меньше начальной погрешности автоматизированной привязки, о которой я говорил раньше, поэтому никто не придает им большого значения. Эти различия мы можем видеть при непосредственном сравнении в SAS.Planet, а ведь они не предназначены для одновременного использования в одном приложении!

Я же так понимаю логику SAS в данном вопросе - выделен прямоугольный кусок, он имеет геодезические координаты :
в Google maps спутник :
MMPLL,1, 39.8919636011124, 57.621134223924
MMPLL,2, 39.8941630125046, 57.621134223924
MMPLL,3, 39.8941630125046, 57.6200195883511
MMPLL,4, 39.8919636011124, 57.6200195883511
после чего карту меняем на yandex спутник. А SAS планета, как можно заметить, так уж устроена , что при смене карты, она геодезические координаты существующих меток,треков etc (и выделений в т.ч). НЕ трансформирует в систему координат НОВОЙ карты! Что в общем имеет свои удобства - можно сравнить насколько Системы координат различных карт будут отличными по координатам.

Нужно понять одну простую вещь: программа SAS.Planet НЕ ЯВЛЯЕТСЯ ГИС-ПРИЛОЖЕНИЕМ! Грубо говоря - это всего лишь браузер для картографического-материала! Существует какая-то исходная точка для привязки какой-то конкретной карты на общий экран, и она задана в описателе ZMP или она жестко зафиксирована сервером сервиса этой карты. А сервисы в принципе не предусматривают какой-либо совместимости между собой. Вот и получается сикось-накось. Это нормально, и с этим ничего нельзя сделать. Пройдет десяток лет, выработаются стандарты, видимо появятся глобальные сервисы для всех со строго стандартизированными параметрами привязки, вот тогда ситуация изменится.

Т.е. коль скоро геодезические координаты выделения не меняются(!!!) при переключении карт, то именно кусок со старыми (!) координатами углов и должен экспортироваться при склейке в новой карте, а на самом деле выходит вот такая ерунда :
MMPLL,1, 39.8919636011124, 57.6211326274473
MMPLL,2, 39.8941630125046, 57.6211326274473
MMPLL,3, 39.8941630125046, 57.6200187157729
MMPLL,4, 39.8919636011124, 57.6200187157729
По широте возникает откуда ни возьмись невязка в в 6 знаке после зпт - у значения, которое физически принципиально НЕ ДОЛЖНО меняться, и если оно меняется, то это признак какого-то бага или методической(может, алгоритмической) ошибки. Которую почему-то автор SAS на багтрекере так поспешил посчитать не ошибкой и закрыл обсуждение.

Я тоже эту неувязку ошибкой не считаю. Причина была уже объяснена - передаются координаты не углов картинки, а угловых пикселей. При этом даже если растры по структуре совершенно одинаковы и пиксели должны друг в друга попадать - теоретически - на практике у разных слоев существуют индивидуальные описатели привязки ZMP и они наверняка в чем-то отличаются. А значит - отличаются и расчеты точек привязки. Суть в том, что эти отличия слишком несущественны при таких размерах пикселя - чтобы обращать на них внимание. Что такое единица в шестом знаке после запятой в координатах широты? Это 11 САНТИМЕТРОВ. А размер одного пикселя какой?

Далее,вопросы 2,3,4.
Когда Вы говорите об "отсутствии ответственности за результат" у SAS планеты, то Вы имеете ввиду, что экспорт SAS планета делает от фонаря и там(в экспортируемых при склейке файлах) могут быть какие угодно баги ? Как-то резко получается, но вопросы-то остаются, можно даже общий вопрос поставить - о сравнении Google и Yandex maps, и какой датум будет наилучшим для трансформации Google maps в Yandex maps ?

Я уже сказал - САС.планета - это всего лишь браузер. За что купил, за то и продает. К ошибкам созданным картографическим сервисам - может добавляться ошибка привязки на сетку WGS-84 экрана САС, что не улучшает результат. Но даже эта ошибка - мизер по сравнению с ошибками, генерируемыми сервисом.
И самое главное. САС.планета не может конвертировать системы координат, она может только пытаться привязать то, что выдает сервер сервиса.
Вы копаете не в ту сторону. Лечить нужно не сервисы (в том числе САС), лечить нужно полученные результаты, сохраненные у Вас на диске в какой-либо форме, начиная от файлов кэша и заканчивая файлами склейки. В первом случае придется создавать собственный браузер, более сложный чем САС, чтобы он вносил поправки "на лету" по очень сложным функционалам для конкретных слоев и территорий. Причем каждый новый снимок или каждый новый слой ставил бы новую задачу для программиста.
А в последнем случае Вы можете создать набор разных датумов трансформации в глобал-маппере - для каждого конкретного случая - по результатам тщательной привязки руками каждого конкретного космического снимка. И тогда плевать на то - кто виноват в погрешностях и что с ними делать. Но это конечно годится только при работе исключительно с выгруженной склейкой.

И наконец о том , как найти Датум данной карты :
Не очень понятно, Вы имели ввиду, что СК и Проекция карты известны или вообще не известны ? Если известны , то почему "берем навскидку"?

А зачем тогда искать, если известны? Я отвечал на вопрос "как найти?"

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

По науке говорите?
Вам нужно найти более десятка точнейших числовых констант, ИМЕЯ В РУКАХ ТОЛЬКО РЕЗУЛЬТАТЫ ВЫЧИСЛЕНИЙ по сложнейшим формулам, включающим в себя квадраты, а также третью и четвертую степени синусов и косинусов! Вы пытались когда-нить взломать 128-битную ЭЦП? Так вот - эта задачка существенно посложнее будет.

Да, и что Вы имели ввиду, говоря о паре датумов ?

Если мы пытаемся определить неизвестный датум одной карты по другой карте той же местности, но с известным датумом - значит мы оперируем парой датумов - первичным и конечным. Логично? 8)))

[kefi]

2 vdemidov >

Глупость написали. Просто не забываем, что привязка делается для растра. Вот отсюда и вылазит разное округление. Тоесть заданный точно координатами прямоугольник округляется до пикселей. После чего считаются координаты этих пикселей. Еще раз повторяю, что это не баг.

Вы не поняли, что я написал, точнее, к сожалению, как это часто происходит - поняли неверно. И аргументируете совсем не по тому поводу. Я толкую про то, что координаты прямоугольника в одной СК не должны пересчитываться, при смене карты (так же как и не пересчитываются координаты меток, во-всяком случае, пользователь, не в состоянии этого заметить, если координаты меток все-таки пересчитываются при смене карты), а Вы повторяете вновь и вновь, что координаты прямоугольника выделения пересчитываются. Вы бы уж тогда, объясняли бы - почему же они пересчитываются при смене карты ? И в чем глупость заключается, написанная мной?

2 PavelML » Усе - утонул в потоке слов. Не смог из них выделить ответов на поставленные выше вполне конкретные вопросы. Если там и есть ответы, то на какие-то другие вопросы - м.б. Вы решили объяснить , как "взломать 128-битную ЭЦП " ? Не знаю ...

[vdemidov]

Вы бы уж тогда, объясняли бы - почему же они пересчитываются при смене карты

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

[kefi]

2 vdemidov » Ну так я разве не об этом же писал ? Но Вы это назвали глупостью. Хотя, конечно, опять же Ваша фраза "в файлах привязки указаны не координаты выделенного вами прямоугольника. Это координаты угловых пикселей склеенной картинки" может двояко пониматься - координаты угловых пикселей это кроме x и y так же и градусные широта и долгота B и L. Т.е., трудно понять, что Вы имеете ввиду. А вообще , представляется логичным, что , если пользователь выделил область, то он рассчитывает на то, что при склейке (экспорте) он получит вырезку области, ограниченной градусными координатами B и L без всяких вычислительных погрешностей.

[vdemidov]

А вообще , представляется логичным, что , если пользователь выделил область, то он рассчитывает на то, что при склейке (экспорте) он получит вырезку области, ограниченной градусными координатами B и L без всяких вычислительных погрешностей.

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

[kefi]

2 vdemidov »

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

Этот результат как раз и есть погрешность из-за того, "что мы работаем с дискретными изображениями". А чтобы не было таких погрешностей нужно не пиксели делить, а оставлять при переключении карты неизменными градусные координаты,единожды установленные при выделении.
Т.е. вы привязываетесь к x,y пиксельным координатам, пересчитывая их в градусные при переходе к новой проекции,а гораздо правильнее было бы, если бы вы выделив кусок каким угодно способом, запоминали градусные координаты B,L, оставляя их неизменными при переходе к новой проекции, и не пересчитывали их из пиксельных x,y. У вас же с метками именно так происходит - b[ градусные B,L координаты не зависят от карты и остаются постоянными, отчего же с координатами углов выделения какие-то пересчеты (x,y->B,L) возникают ?

Кстати, а как SAS планета узнает координаты тайлов ? Т.е. вопрос о том , как осуществляется привязка.

[garl]

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

[kefi]

2 garl » Вы , по-видимому, не поняли - я как раз об этом и пишу - о выделенной области, о том, что геодезические координаты меняются за счет погрешностей пересчета при смене карты - и в KML это видно и во всех других сопутствующих файлах.

[Tolik]

геодезические координаты меняются за счет погрешностей пересчета

Я вот давно читаю эту переписку (не особо внимательно), никак не пойму: в чём проблема-то?
Чем именно Вам мешают эти погрешности? Чего Вы хотите добиться от этого выделения?