| 
		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. 
Огромное спасибо! 
 
)			 | 
		 
		 
	 |