Notes |
|
|
Да. Есть такое. Когда-нибудь нужно будет поправить. |
|
|
(0013215)
|
zed
|
04-11-2013 05:33
|
|
|
|
|
Может быть. Понятия не имею как это правильно сделать, поэтому и отложил эту хотелку в долгий ящик :) Займись если есть желание и возможность :) |
|
|
(0014565)
|
T_Im
|
16-08-2014 11:27
|
|
Если сложно заморачиваться с proj4, то для большинства случаев довольно будет скомпенсировать сдвиг по долготе. На основании вышеприведенной ссылки, это можно сделать по несложной формуле
Lat0, Lon0 - угол в координатах генштаба, Lat=Lat0, Lon вычисляется по формуле:
B = Lat0 * Pi / 180;
L = Lon0 * Pi / 180;
N = a * (1 - e2 * sin(B) ^ 2) ^ -0.5;
Lon = Lon0 + 206264.8062 / (N * cos(B)) * (-23.92 * sin(L) - 141.27 * cos(L) / 3600); |
|
|
(0014566)
|
zed
|
16-08-2014 11:39
|
|
Подкорректировал рассчёты. Только на чём теперь потестировать? |
|
|
(0014567)
|
T_Im
|
16-08-2014 12:46
|
|
В основном наборе карт: Генштаб -> Генштаб 1 км
И ткнуться в место, где хорошо видна склейка листов, например, сюда
N55°40'10,64" E38°29'48,90" |
|
|
(0014568)
|
zed
|
16-08-2014 12:59
|
|
|
|
(0014569)
|
T_Im
|
16-08-2014 13:07
|
|
А считаете как: через proj или по формуле? |
|
|
(0014570)
|
zed
|
16-08-2014 13:10
|
|
По формулам из статьи. Ни по X, ни по Y линии не совпадают. |
|
|
(0014571)
|
T_Im
|
16-08-2014 13:33
(edited on: 16-08-2014 13:34) |
|
По широте там немного кривая привязка, это нестрашно.
Пересчитал долготу одной из точек по фомрулам, у меня "компенсировалось" 60 из 120 метров разбега.
Сейчас попробую пересчитать заново.
|
|
|
(0014572)
|
zed
|
16-08-2014 13:41
|
|
|
|
(0014573)
|
zed
|
16-08-2014 14:41
|
|
Какая-то ошибка в формуле. Перевожу (72,0; 24,0) в пулково выдаёт (71,999910956; 24,004022247), а какой-то онлайн калькулятор выдаёт (72.00009373604956; 23.995977753010802), что полностью совпадает с сеткой из kml. Вот же ж засада :( |
|
|
(0014574)
|
T_Im
|
16-08-2014 14:55
(edited on: 16-08-2014 15:01) |
|
А у вас Эксель импортирует приложенный в статье файл? (у меня ругается на него и функции не добавляет).
Я просчитал одну из точек вручную по формуле, дельта по широте получилась практически в 2 раза меньше, чем по онлайн калькулятору (считал тут http://cs2cs.mygeodata.eu/ с подставлением вручную параметров как в формуле: +proj=longlat +ellps=krass +towgs84=23.92,-141.27,-80.91 +no_defs).
Вот как это выглядит:
Если рассчитанное по формуле смещение по широте удвоить - то точка ложится почти идеально на рассчитанную с погрешностью меньше 0,5 метра (см. две метки рядом).
|
|
|
(0014575)
|
T_Im
|
16-08-2014 15:20
|
|
>Какая-то ошибка в формуле. Перевожу (72,0; 24,0)
Вы не в ту сторону прибавили смещение. |
|
|
(0014576)
|
T_Im
|
16-08-2014 15:23
|
|
Если это учесть, ваша точка по формуле почти идеально попадет на место (а я у себя где то 1/2 потерял). |
|
|
(0014577)
|
zed
|
16-08-2014 15:26
|
|
Да, у них на сайте неправильно дано пояснение: WGS84_SK42_Lat переводит из SK42 в WGS64, а не наоборот.
Один фиг что-то не сходится с kml. |
|
|
(0014578)
|
T_Im
|
16-08-2014 15:40
|
|
Разница полметра. Это несущественно. |
|
|
(0014579)
|
T_Im
|
16-08-2014 15:41
|
|
(Должна получится 72,0000890044 23,995977753) |
|
|
(0014580)
|
zed
|
16-08-2014 17:19
(edited on: 16-08-2014 17:22) |
|
> Разница полметра. Это несущественно.
Разница получается существенно больше. Метров 15-20. Плюс появляется проблема: линии генштаба становятся не параллельны градусной сетке и появляются артефакты на стыках тайлов.
> (Должна получится 72,0000890044 23,995977753)
Да, точно так и получается. А в kml угол приходится на (72,000059 23,99649).
|
|
|
(0014581)
|
zed
|
16-08-2014 19:22
|
|
В приложенном exe сетка рисуется гораздо точнее, но есть артефакты. Код залил в отдельную ветку genshtab, пускай лежит пока не появится у кого желание довести до ума. |
|
|
(0014583)
|
Garl
|
16-08-2014 19:34
|
|
чего-то артефактов не замечено. или артефакт - это сдвиг линии сетки на 1 пиксель? |
|
|
(0014584)
|
zed
|
16-08-2014 19:37
|
|
Сдвиги линий, это цветочки. Ягодки на z21: при включённой сетке 10k или 5k в узловых точках линии не отрисовываются (обычно вертикальная). |
|
|
(0014585)
|
T_Im
|
16-08-2014 20:43
(edited on: 16-08-2014 20:51) |
|
ИМХО, формула считает верно, проблема в КМЛ-нике (непонятно, какие параметры использовались при преобразовании координат Pulkovo-> WGS84 в нем)
Вот тут описаны возможные параметры рассчетов: http://gis-lab.info/qa/datum-transform-sets.html#.D0.A1.D0.9A-42_-.3E_WGS84
Формула и два онлайн калькулятора (по моей ссылке, если задать +towgs84=23.92,-141.27,-80.91 - это dx dy dz) с точностью до последнего знака находят
23,995978
Это 3-х параметрическое преобразование по ГОСТ-у.
Еще есть 7-ми параметрическое преобразование, которое предлагает по дефолту калькулятор http://cs2cs.mygeodata.eu/ (если вбить в поиске Pulkovo). Его параметры +towgs84= совпадают с 7-ми параметрами ГОСТА с Гислаба и дают
23.996085
(разница 107 миллионных с 3-х параметрическим - это около 3,7 метра, и 405 миллионных с границей КМЛ 23.996490 - почти 14 метров)
Почти 4 метра по сравнению с имеющейся ошибкой в 140 метров - это пустяки.
Да и вообще включать уточненный алгоритм имеет смысл только начиная с километровки и масштабах больше z12 - выше эти 100+ метров погрешности будут меньше пикселя.
|
|
|
(0014586)
|
T_Im
|
18-08-2014 10:10
|
|
zed
Если несложно, подправьте еще пожалуйста, чтобы чтобы прямоугольное выделение с зажатым ctr+shift выделяло по исправленным границам (сейчас выделяет по старым). |
|
|
(0014587)
|
zed
|
18-08-2014 10:51
|
|
Могу, конечно, но оно всё равно пока в отдельной ветке лежит и в ночнушку не войдёт. Нужно ковырять из-за чего глючит отрисовка, но у меня нет идей и я без понятия в какую сторону смотреть. |
|
|
(0014588)
|
T_Im
|
18-08-2014 11:30
|
|
>Могу, конечно, но оно всё равно пока в отдельной ветке лежит и в ночнушку не войдёт.
Достаточно как в прошлый раз прикрепленного экзэшника.
>из-за чего глючит отрисовка, но у меня нет идей и я без понятия в какую сторону смотреть.
Там, вероятно, криво рендерится тонкая линия, которая была прямая, а стала чуть наклонной.
Скорее всего, наиболее простое но грубое решение - задать ей ширину на 1-2 пикселя больше. Или же поиграться с дефолтным фильтром рендеринга.
Не часто, но регулярно замечаю похожий баг, когда при перемещении в САС при отрисовке теряются куски путей (в старых версиях годовалой давности этого точно еще не было). Возможно, эти баги могут быть связаны. |
|
|
(0014589)
|
zed
|
18-08-2014 13:21
|
|
О, а с выделением тоже весело получается. В SAS же это прямоугольное выделение, а квадраты генштаба не прямоугольны. Т.е. получается что мы считаем верхнюю левую и правую нижнюю точки, а две другие улетают мимо. |
|
|
(0014590)
|
zed
|
18-08-2014 13:43
|
|
Приложил exe. Теперь чтобы получить точное (насколько позволяют расчёты) выделение по границам генштаба, нужно пользоваться полигональным выделением с включённым прилипанием к узлам сетки и с зажатым shift.
[Боромир-мем]Нельзя просто так взять и получить полигон генштаба.[/Боромир-мем] |
|
|
(0014591)
|
Garl
|
18-08-2014 14:05
|
|
Ну вот реально за всё время ни разу не мешала погрешность тупой прямоугольной генштабовой сетки. |
|
|
(0014592)
|
T_Im
|
18-08-2014 15:47
|
|
>Ну вот реально за всё время ни разу не мешала погрешность тупой прямоугольной генштабовой сетки.
Уже на километровке погрешность 120 метров заметна, а на 500-метровке превращается в большое неудобство, если совмещать по углам листы ГШ и склеенные в САС по границам ГШ снимки.
>Т.е. получается что мы считаем верхнюю левую и правую нижнюю точки, а две другие улетают мимо.
На 500-метровках разница получается меньше метра, что в разы меньше количества метров на пиксель для актуальных для них зумов z15-16. Поэтому, что полигоном, что прямоугольником, для обычных задач без разницы.
>Приложил exe.
Огромное спасибо!
) |
|