В продолжение вчерашнего обсуждения.
#! /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
2
Не все присутствовали на встреча. Поясни, пожалуйста, что это за скрипт.
Это пример, как определить угол поворота на перекрестке. KekcuHa сказал, что хотел сделать разную стоимость поворотов налево-направо-прямо на перекрестках. lat?, lon? - широта и долгота нода. 1,2,3 - индексы нодов соответственно from, via, to.
dimuzz
4
Как мне кажется, важен не сам факт изменения направления влево, а то, что поворот “левее всех других исходящих дорог” 
liosha
(liosha)
5
Не, там речь шла о том, что поворот налево обычно занимает больше времени, чем поворот направо, и поэтому временной штраф при расчёте маршрута за левый поворот должен быть больше.
dimuzz
6
Не секрет, о какой программе шла речь?
Ezhick
(Kirill)
9
речь не о программе, а об ОСМ. Конечная цель - использование этой инфы в ПокетГИС.
Немного не по теме. Как бы оргонизовать проверку зданий на “квадратность”, т.е. проверить прямоугольность всех углов?
Ezhick
(Kirill)
11
Нинадо! Далеко не все здания имеют прямые углы!!!
Ручками в жосме жмакаем Q и имеем счастье. Но выборочно!
Да я же не предлагаю делать автоматом, а только проверять. А там уже смотреть и ручками править. Меня интересует только алгоритм проверки.
Ezhick
(Kirill)
13
Ок, сорри тогда
Но имхо количество непрямоугольных домов будет такое, что ручками перепроверять потом каждый - сизифов труд. Я кривые домики правлю по ходу дела, увидел - исправил… В Мск целые районы попадаются криво нарисованные…
Eще бы с координатами разобраться
Только их формулка не учитывает знак (влево поворот или вправо), а моя - учитывает
Так у меня все с координатами
Вот пример перевода Lat Long To UTM: http://www.uwgb.edu/dutchs/UsefulData/UTMConversions1.xls
После перевода угол определяется верно
okhta
18
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);
Правильно-ли я понимаю. В ОSM данные хранятся в географических координатах (lon, lat). Для отображения на плоскости необходим пересчет в прямоугольную систему координат (в определнной проекции), например Меркатора (UTM). Также и для определения реального угла необходим пересчет. JOSM по умолчанию отобаражае в проекции Меркатора. Если не прав, поправьте. Сильно не бить.
okhta
20
Трансверсальный Меркатор ™ это Меркатор примененный к зоне (lat/lon прямоугольник,
повернутый на 90°, поэтому “трансверсальный”). Не путайте c “обычным” Меркатором.
Сферического Меркатора с экваториальным радиусом Земли принятого в WGS84,
который используется также osm, google, microsoft и yahoo.
космоснимки, яндекс и майл.ру используют эллиптический Меркатор WGS84,
поэтому имеют сдвиг по отношению к osm, google, microsoft и yahoo , зависящий от широты (совпадают только на экваторе).