На главную... Продукты | Технологии | Классификаторы | Проекты | Скачать | Цены| Форум | Статьи | Обучение | Контакты

Владимир Егоров (Все сообщения пользователя)

Поиск  Пользователи  Правила  Войти
Форум » Пользователи » Владимир Егоров
Выбрать дату в календареВыбрать дату в календаре

Страницы: Пред. 1 2 3 4 5 6 7 8 9 10 11 ... 21 След.
mapEditWms
 
Метод MessageHandler статический?

Я бы вообще TASKPARMEX нулями забил, и всё.

И ещё, судя по описанию, docHandle больше похоже на ui->MapView1 (QWidget???), чем на HMAP.
[CODE]#ifdef WIN32API

 HWND        Handle;          // Идентификатор главного окна приложения

#else

 MSGHANDLER  Handle;          // Идентификатор обработчика команд главного окна приложения

#endif

 HWND        DocHandle;       // Идентификатор окна карты (документа)

 long int    StayOnTop;       // Признак выставления форме свойтсва StayOnTop  // 14/05/05
[/CODE]
Эти поля и сама структура видимо изначально вообще для WINDOWS делались.
Тот  же MSGHANDLER используется под Linux вместо окна, которому события посылаются (как CallBack функция) .
Она у нас как правило static long onMsg(...){..}

Но я вероятно не прав, так как с TASKPARMEX не работал.

Но если натравить поиск на TASKPARMEX по компонентам для gisdesigner (QDMapVIew и прочие QD*) или примерам из пакета, то может быть там найдутся примеры как этой структурой пользоваться.

А может дело вообще не в этом (не в TASKPARMEX).
mapEditWms
 
[CODE]typedef long int (* MSGHANDLER)
  (long int hwnd, long int code, long int p1, long int p2, long int typemsg);
[/CODE]
MapView1 - это метод с такой сигнатурой ?

У Вас же там куча предупреждений от компилятора должна была быть.
Изменено: Владимир Егоров - 13.06.2019 23:56:45
mapSelectLayer влияет только на одну карту из mpt
 
mapSetSiteViewSelect пробовали ?
[MAPAPI] Получение данных о проекции растра, [MAPAPI] Получение данных о проекции растра
 
[QUOTE]Владимир Егоров написал:
При этом вручную внести эти данные в Rsw файл я не могу, так как функция picexLoadRasterToRswUn создаёт файл в формате 1.04, который закрыт, я нашёл только описание формата версии 2.00 и 2.01[/QUOTE]
Я нашёл упоминание этой версии в mappicex.h, с декабря 2018-го года получается искал =)
[CODE]//========================================================================
// Привязка растра с масштабированием по двум точкам
// Внимание: Возможна устанавка отличных друг от друга размеров пикселя по X и по Y
//
// ВАЖНО:
// Если размеры пикселя по X и по Y отличаются друг от друга, то в растр
// устанавливается версия  1.04 (0x0104).
// Растры версии 1.04 открываются в ПО начинаяя с 11-ой версии.
//
// hMap        - карта, содержащая векторные данные;
// rswName     - имя файла растра
// pointMet1   - Координаты первой точки  в метрах
// pointMet1   - Координаты первой точки в метрах
// pointMet2   - Координаты второй точки  в метрах
// pointMet2   - Координаты второй точки в метрах
// message     - флаг на выдачу сообщений (0\1)
// При ошибке возвращает ноль
//==========================================================­==============
_PICIMP long int _PICAPI AttachRswWithScaling(HMAP hMap, const char* rswName,
                                            DOUBLEPOINT *pointMet1, DOUBLEPOINT *pointMetNew1,
                                            DOUBLEPOINT *pointMet2, DOUBLEPOINT *pointMetNew2,
                                            int message);
[/CODE]
То есть на сайте в документации к rsw/mtw не хватает пометки про эту особенность.
[MAPAPI] Получение данных о проекции растра, [MAPAPI] Получение данных о проекции растра
 
[QUOTE]Dmitry_ написал:
Если в функциях привязки растра параметр hmap задать равным 0, то растр будет открыт в отдельном документе:[/QUOTE]
Функция RswTransformingBySquareMethod не запускается (возвращает 0) если ей передать первым параметром 0, то есть открывать растр в отдельном документе нужно самому.
И все другие функции из семейства функций привязок вроде тоже без hmap не запускаются.

Но это в версии 12.5.0 gisdesigner.

Может в следующих версиях уже по другому будет.


По поводу разницы алгоритмов.
Насколько я понял,
AttachRswWithScalingAndRotation - это линейное преобразование, сдвиг - масштаб - поворот, двух точек достаточно для вычисления параметров.
RswTransformingBySquareMethod - это линейное преобразование, афинное (A0, A1, A2; B0, B1, B2) X = A0 + A1*Xi + A2*Yi; Y = B0 + B1*Xi + B2*Yi.  Шесть параметров вычисляются методом наименьших квадратов, поэтому нужно минимум 4 точки (чтобы количество строк в матрице было больше чем количество столбцов = 3)

RswTransformingByBorderMethod - это нелинейное преобразование (видимо, "нелинейный резиновый лист", как описано здесь: [URL=http://help.gisserver.ru/ru/rswtrans/rtip.html.]http://help.gisserver.ru/ru/rswtrans/rtip.html[/URL]), не уверен.

И насколько я понял, для этого метода важно, чтобы опорные точки распологались на рамке листа ( 4 угла), а если опорных точек больше 4, то они должны распологаться равномерно.


Далее, для растров уже спроецированных на плоскость (то есть, находящихся в какой-то локальной прямоугольной системе координат) лучше применять линейные преобразования.
Так же, линейные преобразования есть смысл применять для растров, немного сдвинутых относительно векторной карты (или более точной растровой).
То есть, это случаи когда у вас уже привязанный растр при наложении на основную карту немного смещён/повернут.
Или, когда у вас есть скриншот района из гугло/яндекс карт, и вы хотите его привязать.

Нелинейные преобразования (которое RswTransformingByBorderMethod) лучше применять для отсканированных бумажных листов топографической карты, когда привязка идёт по рамке и/или точкам пересечения километровой сетки. И в этом случае чем больше точек, тем лучше.


Поправьте меня пожалуйста,  если я неправильно что-нибудь написал.
[MAPAPI] Получение данных о проекции растра, [MAPAPI] Получение данных о проекции растра
 
Спасибо.
[MAPAPI] Получение данных о проекции растра, [MAPAPI] Получение данных о проекции растра
 
gisdesigner 12.5.0 (ГИС Конструктор для QtDesigner)


Продолжу тему с привязкой растра, но уже без файлов привязок.

То есть на входе - изображение, и оператор, который может отметить на изображении точки и сказать какие у этих точек координаты.

1)
Подход в целом такой же как и в случае с файлами привязки, но мне интересно для каких целей используется параметр HMAP в функциях для привязки растрова из mappicex.h:
Скрытый текст

Ну то есть что будет, если я сделаю растр из изображения с помощью функции picexLoadRasterToRswUn, потом открою его и выставлю параметры проекции, датум и эллипсоид (как СК-42, к примеру),
закрою, потом открою векторную карту в системе координат уже другой (например, UTM на WGS84), и попытаюсь привязать растр с помощью функции привязки (любой), отдав первым параметром векторную карту, а в каждой паре точек в качестве фактической точки буду отдавать координаты с растра (в СК-42), а в качестве теоретической (желаемой) точки буду отдавать точку с векторной карты (в UTM).



Это так работает?
Данные о проекции и системе координат из HMAP (открытой векторной карты) используются для того, чтобы обработать желаемые координаты точки?
И тогда есть возможность исходные координаты задавать в системе растра, а желаемые в системе открытой векторной карты?


2)
А ещё, я не очень понял чем отличаются друг от друга функции трансформации растров по рамке и МНК.
Какие-то из этих функции работают дольше но точнее?
Или разница только в параметрах обработки рамки?

Пометки "нелинейное трансформирование | расчёт коэффициентов по МНК | вообще никакой пометки" сбивают с толку.

Что правильнее/корректнее использовать?
Программа вылетает при пересчете координат карты Region.sit в СК-42, Программа вылетает при пересчете координат карты Region.sit в СК-42
 
[CODE] // Преобразование координат из геодезической системы координат карты к
// в геодезические координаты в радианах (общеземной эллипсоид WGS84)
// (поддерживается не для всех карт !)
// При ошибке возвращает ноль

_MAPIMP long int _MAPAPI mapGeoToGeoWGS843D(HMAP hMap, double *Bx, double *Ly,
                                           double *H);
[/CODE]Там вроде HMAP ожидается, а не HANDLE
mapPlaneUTMToGeoWGS84ByZone описание gisdesigner11, mapPlaneUTMToGeoWGS84ByZone описание gisdesigner11
 
Здравствуйте.

Разбирался сейчас с функцией mapPlaneUTMToGeoWGS84ByZone в старой версии gisdesigner [B](11-ая версия)[/B]

На форуме информации не нашёл, поэтому оставлю здесь пост, может кому-нибудь пригодится (для большинства эти вещи очевидны, вероятно).

Итак, функция:
[CODE] // Преобразование координат в метрах на местности из заданной зоны UTM
// в геодезические координаты в системе WGS-84.         // 03/07/06
// zone - номер исходной зоны системы UTM
// x,y  - преобразуемые координаты
// на входе метры в одной зоне UTM, на выходе - радианы WGS-84.
// При ошибке возвращает 0

_MAPIMP long int _MAPAPI mapPlaneUTMToGeoWGS84ByZone(long int zone, double * x, double * y);

[/CODE]
С помощью этой функции я хотел вычислить координаты левого нижнего угла растрового файла , у которого в паспорте написано что он в системе UTM на WGS84.

[CODE] // Типы флага "Тип карты"
 typedef enum MAPTYPE
 {
// UNDEFINED   = -1,      // Не установлено
  TOPOGRAPHIC  = 1,      // Топографическая (СК42), требует осевой меридиан
  CK_42        = 1,      // Система координат 42 года, требует осевой меридиан
  ...
  UTMWGS84     = 11,     // UTM на WGS84, требует осевой меридиан
  ...
 }
  MAPTYPE;
[/CODE]Проекция, эллипсоид и система координат (поля в паспорте rsw) действительно соответствуют этому типу карты.

Координаты (по паспорту rsw) левого нижнего угла rsw:

[CODE]X: 6.69006e+06
Y: 609109 [/CODE]На выходе мы хотим получить WGS84 долготу/широту.
Если использовать PHOTOMOD GeoCalculator, то результат будет:

[CODE]B:60.332346299
L:28.976193205
[/CODE]Тут главное не забыть, что в паспорте rsw ось X направлена вверх, ось Y направлена вправо (как в проекции Гаусса-Крюгера), а в универсальной поперечной проекции Меркатора ось Y вверх, а ось X вправо.
Соответственно, X - это широта, а Y - это долгота (не смотря на то, что в проекции Меркатора Y это широта, а X долгота)

Зоны в Меркаторе нумеруются не так, как в Гауссе-Крюгере, они сдвинуты на 30 вправо относительно зон Гаусса-Крюгера:[CODE]int MapIndexer::calcTransverseMercatorZone(double axisMeridianInRadian)
{
   int x = (calcSK42Zone(axisMeridianInRadian) + 30) % 60;
   return x?x:60;
}
[/CODE]
В паспорте rsw осевой меридиан (AxisMeridian) указан как 27 градусов, это 5-ая зона в Гауссе-Крюгере и 35-ая зона в Меркаторе.
Указываем данные (35-ая зона, E, N) в фотоплане и получаем координаты: [URL=https://drive.google.com/open?id=1w0sWn14g88qmiZbKYG9tnVUmpLgXqkrb]Скриншот[/URL]

А чтобы получить те же координаты с помощью mapPlaneUTMToGeoWGS84ByZone нам придётся отредактировать Y.

Сначала вычтем из него значение FalseEast из паспорта карты (смещение центра координат  на восток) и получим расстояние от точки до осевого меридиана по оси Y

FalseEast в паспорте rsw указан как 500000 (метров), то есть Y получится 109109 вместо 609109.

Дальше к значению нужно прибавить номер зоны в меркаторе умноженный на 1000000 (миллион), то есть 35 * 10^6, получим 35109109.

И вот теперь функция mapPlaneUTMToGeoWGS84ByZone сможет вычислить для нас координаты.
Пример:

[CODE] int zone = 35;
   double FalseEast = 500000.0;
   double X = 6690060.0;
   double Y = 609109.0;
   double Bx = X;
   double Ly = zone*1000000.0 + (Y - FalseEast);
   long rc = mapPlaneUTMToGeoWGS84ByZone(zone, &Bx, &Ly);
   if (rc != 0){
       qDebug() << "Utm B:" << Bx/M_PI*180.0 << " L: " << Ly/M_PI*180.0;
       qDebug() << "Utm B:" << Bx << " L: " << Ly;
   }[/CODE][CODE]Utm B: 60.3323 L: 28.9762
Utm B: 1.053  L:  0.50573
[/CODE]

Upd. А для точек в южном полушарии, вероятно, из X надо будет вычитать FalseNorth (поле в паспорте rsw) равное 10000000 (10 миллионов) метров. Чтобы, к примеру, из значения 3309940.0 получить -6690060.0 и уже вот это отрицательное значение отдавать в функцию mapPlaneUTMToGeoWGS84ByZone
Изменено: Владимир Егоров - 29.05.2019 16:39:45
Обновление версии ГИС Конструктор, Нелегальная копия модуля - libqdmapacces.so
 
Там вроде баг есть с хранением координат в дискретах в sit файлах в версиях gisdesigner 12.3.1+ (это я про второй пункт).
Изменено: Владимир Егоров - 31.05.2019 15:36:34
Страницы: Пред. 1 2 3 4 5 6 7 8 9 10 11 ... 21 След.



© КБ Панорама, 1991-2024

Регистрируясь или авторизуясь на форуме, Вы соглашаетесь с Политикой конфиденциальности