Угол поворота

shadowjack · December 20, 2009, 12:02pm

В продолжение вчерашнего обсуждения.


#! /usr/bin/perl -w

use Math::Trig;
use strict;

my ($lat1, $lon1, $lat2, $lon2, $lat3, $lon3) = (55, 38, 56, 39, 57, 38.7);

my $x1 = ($lon2 - $lon1)*cos(deg2rad($lat2));
my $y1 = $lat2 - $lat1;
my $x2 = ($lon3 - $lon2)*cos(deg2rad($lat2));
my $y2 = $lat3 - $lat2;

my $a1 = rad2deg(atan2($x1, $y1));
my $a2 = rad2deg(atan2($x2, $y2));
my $a = $a2 - $a1;
$a += 360 if($a < -180);
$a -= 360 if($a > 180);

print "$a1 $a2 $a\n"

Как-то так. $a < 0 - поворот налево (против часовой), $a > 0 - направо (по часовой). Особо не тестил, но вроде работает. Функция atan2 в mysql есть.

vvoovv · December 20, 2009, 3:13pm

Не все присутствовали на встреча. Поясни, пожалуйста, что это за скрипт.

shadowjack · December 20, 2009, 3:39pm

Это пример, как определить угол поворота на перекрестке. KekcuHa сказал, что хотел сделать разную стоимость поворотов налево-направо-прямо на перекрестках. lat?, lon? - широта и долгота нода. 1,2,3 - индексы нодов соответственно from, via, to.

dimuzz · December 21, 2009, 6:47am

Как мне кажется, важен не сам факт изменения направления влево, а то, что поворот “левее всех других исходящих дорог”

liosha · December 21, 2009, 7:11am

Не, там речь шла о том, что поворот налево обычно занимает больше времени, чем поворот направо, и поэтому временной штраф при расчёте маршрута за левый поворот должен быть больше.

dimuzz · December 21, 2009, 8:02am

Не секрет, о какой программе шла речь?

Zkir · December 21, 2009, 8:10am

это-то и плохо ))

liosha · December 21, 2009, 8:13am

О PocketGIS

Ezhick · December 21, 2009, 8:39am

речь не о программе, а об ОСМ. Конечная цель - использование этой инфы в ПокетГИС.

Dmitry_Terentiev · December 24, 2009, 2:15pm

Немного не по теме. Как бы оргонизовать проверку зданий на “квадратность”, т.е. проверить прямоугольность всех углов?

Ezhick · December 24, 2009, 3:24pm

Нинадо! Далеко не все здания имеют прямые углы!!!

Ручками в жосме жмакаем Q и имеем счастье. Но выборочно!

Dmitry_Terentiev · December 25, 2009, 3:46am

Да я же не предлагаю делать автоматом, а только проверять. А там уже смотреть и ручками править. Меня интересует только алгоритм проверки.

Ezhick · December 25, 2009, 7:16am

Ок, сорри тогда Но имхо количество непрямоугольных домов будет такое, что ручками перепроверять потом каждый - сизифов труд. Я кривые домики правлю по ходу дела, увидел - исправил… В Мск целые районы попадаются криво нарисованные…

Dmitry_Terentiev · December 25, 2009, 1:14pm

Спасибо gis-lab: http://gis-lab.info/qa/aveazimuth.html

Dmitry_Terentiev · December 25, 2009, 1:51pm

Eще бы с координатами разобраться

shadowjack · December 25, 2009, 3:32pm

Только их формулка не учитывает знак (влево поворот или вправо), а моя - учитывает

Так у меня все с координатами

Dmitry_Terentiev · December 26, 2009, 7:38am

Вот пример перевода Lat Long To UTM: http://www.uwgb.edu/dutchs/UsefulData/UTMConversions1.xls

После перевода угол определяется верно

okhta · December 26, 2009, 12:07pm

UTM работает в JOSM в последних svn версиях
если поправить EPSG коды


Index: src/org/openstreetmap/josm/data/projection/UTM.java
===================================================================
--- src/org/openstreetmap/josm/data/projection/UTM.java    (revision 2679)
+++ src/org/openstreetmap/josm/data/projection/UTM.java    (working copy)
@@ -340,11 +340,11 @@
 
     public EastNorth latlon2eastNorth(LatLon p) {
         EastNorth a = MapLatLonToXY(Math.toRadians(p.lat()), Math.toRadians(p.lon()), UTMCentralMeridian(getzone()));
-        return new EastNorth(a.east() * UTMScaleFactor + 3500000.0, a.north() * UTMScaleFactor);
+        return new EastNorth(a.east() * UTMScaleFactor + 500000.0, a.north() * UTMScaleFactor);
     }
 
     public LatLon eastNorth2latlon(EastNorth p) {
-        return MapXYToLatLon((p.east()-3500000.0)/UTMScaleFactor, p.north()/UTMScaleFactor, UTMCentralMeridian(getzone()));
+        return MapXYToLatLon((p.east()-500000.0)/UTMScaleFactor, p.north()/UTMScaleFactor, UTMCentralMeridian(getzone()));
     }
 
     @Override public String toString() {
@@ -357,7 +357,7 @@
     }
 
     public String toCode() {
-        return "EPSG:"+ (325800 + getzone());
+        return "EPSG:"+ (32600 + getzone());
     }
 
     @Override
@@ -366,7 +366,7 @@
     }
 
     public String getCacheDirectoryName() {
-        return "epsg"+ (325800 + getzone());
+        return "epsg"+ (32600 + getzone());
     }
 
     public Bounds getWorldBoundsLatLon()
@@ -423,7 +423,7 @@
 
     public Collection<String> getPreferencesFromCode(String code)
     {
-        if(code.startsWith("EPSG:3258"))
+        if(code.startsWith("EPSG:326"))
         {
             try {
                 String zonestring = code.substring(9);

Dmitry_Terentiev · December 26, 2009, 7:09pm

Правильно-ли я понимаю. В ОSM данные хранятся в географических координатах (lon, lat). Для отображения на плоскости необходим пересчет в прямоугольную систему координат (в определнной проекции), например Меркатора (UTM). Также и для определения реального угла необходим пересчет. JOSM по умолчанию отобаражае в проекции Меркатора. Если не прав, поправьте. Сильно не бить.

okhta · December 26, 2009, 9:47pm

Трансверсальный Меркатор ™ это Меркатор примененный к зоне (lat/lon прямоугольник,
повернутый на 90°, поэтому “трансверсальный”). Не путайте c “обычным” Меркатором.

Сферического Меркатора с экваториальным радиусом Земли принятого в WGS84,
который используется также osm, google, microsoft и yahoo.
космоснимки, яндекс и майл.ру используют эллиптический Меркатор WGS84,
поэтому имеют сдвиг по отношению к osm, google, microsoft и yahoo , зависящий от широты (совпадают только на экваторе).