Столкнулся с таким вопросом — каков масштаб, т.е. соответствие, реальных расстояний в милях отображаемым на электронной карте в приемоиндикаторах GPS и ГЛОНАСС при увеличении 1.0?
Поясню — если я использую коэффициент ZOOM = 1.0, то чему соответствует расстояние в 100 пикселов по горизонтали или вертикали? Масштабу бумажной карты 1:10000, или может быть 1:50000, или какой-то другой?
Есть ли такие стандарты?
Речь о бумажных картах или всё об электроном уст-ве? Если второе, то в чём проблема? Гауга имеет область отображения, имеющую конкретный размер в пикселях. Карта имеет радиус отображения (по аналогии с дефолтным ГПС), счёт идёт относительно позиции самолёта — вот это и есть центр системы координат. Считаем расстояние в км или милях от текущей позиции самолёта до маяка (используя формулы большого круга), переводим их в пиксели и всё.
Нет, это неверно. В реале нет понятия пиксель и масштаб в пикселях (по сути его нету и в симуляторе). Параметр Range имеет определённый диапазон значений. Например в Ту-204 в КИНО есть кадры с картами, при этом рабочий диапазон карты от 20 до 1280 км в радиусе. Вот от этого значения и отталкиваемся. Расстояние между самолётом и маяками всегда в КМ, радиус отображения здесь по сути ограничивает область видимости. Вот смотрите как у меня в Ту-204 это сделано.
Это окружные маяки в радиусе 20км
А это в радиусе 1280км
Речь идет об электронных устройствах для FSX, которые должны соответствовать реальным приборам, например, российскому авиационному приемоиндикатору ГЛОНАСС/GPS СН-4312-02 производства КБ НАВИС, российскому TSS ГЛОНАСС/GPS ТРАНЗАС или Garmin 1000.
А проблема (даже не проблема, а вопрос) в том, что кнопкой RNG в иностранных устройствах или кнопкой Масштаб в российских устройствах устанавливается масштаб карты. В программе С++ для масштабирования используется коэффициент ZOOM, который имеет различные значения, в том числе и 1.0.
Так вот при таком ZOOM =1.0 сколько миль дистанции будет в 10 или 50, или в 100 пикселах? Для всех ли приборов это соотношение одинаково, или нет? Т.е. есть ли стандарт, или его нет? Пока не нашел по этому поводу никакой информации.
Я пока взял такое соотношение: 10 пикселов = 1 миля.
Но не знаю, насколько это правильно.
Красиво сделано, ничего не скажешь!
За подсказку спасибо! Подумаю еще, как карту масштабировать.
Меня смутил вот этот параметр в карте XML, который используется как в FS9, так и в FSX:
<Macro Name=»CalculateZoomFactor»>2000 1500 1000 500 350 200 150 100 50 35 20 15 10 5 3.5 2.0 1.5 1.0 0.576037 0.329164 0.246873 0.164582 0.082290 0 24 @1 case</Macro>
Насколько я его понял, это и есть коэффициент масштабирования карты. Среди этих значений есть коэффициент 1.0. Поэтому и в С++ я принял эту таблицу коэффициентов, как массив, но уперся в соотношение расстояний в милях и в пикселах для 1.0.
И еще — формулы, которыми я пользуюсь, дают ортодромическую дистанцию в милях. Поэтому я расчеты все веду в милях. А индикацию дистанций буду производить в километрах или в милях в зависимости от того, как это сделано в реальном приемоиндикаторе.
В новых отечественных приемоиндикаторах ГЛОНАСС/GPS используется рельеф карты в своеобразной палитре, отличающейся от иностранных карт с рельефом. Например, такой палитрой отличается приемоиндикатор TSS разработки Транзас. А вот в СН-4312-02 КБ НАВИС используется черная карта.
С учетом интенсивного вооружения самолетов приемоиндикаторами ГЛОНАСС скоро такие карты в симуляторе станут актуальными. Вот на базе своих разработок и можно будет делать то, что не позволяет дефолтный Garmin.
Прикрепленные изображения
Похоже именно на то, что это диапазоны и есть. А Вам обязательно делать на базе дефолтного ГПС? Ведь отрисовать карту имея все нужные формулы плёвое дело.
С дефолтным Garmin_ом у меня ничего не получилось. Вытащить информацию по террайну и остальным данным через Visual Studio 2010 Professoinal с использованием gps_info и прочих премудростей, и соответственно отрисовать их с помощью GDI+ я не смог.
Поэтому схема такая — создал свои собственные базы данных, в том числе и Земли, их и буду отображать на своей карте с помощью своей математики. А от FSX останется только обновлять данные при создании новых сценариев. И от баз AIRAC тоже обновлять.
Карту в самолет поставил, веду отладку отображения данных на карте.
На самом деле это правильный подход. А Вы не пробовали через fs9gps? gps_info, насколько я помню, входит в стандартные примеры СДК и сильно много там не сделаешь, при этом пример гауги упирается именно на использование дефолтного гармина как «подложки». Вам знаком файл под названием fs9gps Complete Guidebook v1.1.pdf ? Если нет — забейте в гугл и скачайте. Это Вам поможет в очень многом, хотя бы понять, как оно всё задумано в симе (при этом разница между девяткой и десяткой минимальна). Примеры там правда все на ХМЛ, но это не должно быть проблемой.
Я у себя сделал почти аналогично Вашему решению, за исключением использования внешней базы, мне просто лень было писать и придумывать всю обвязку для работы с базой, ведь 99% маяков уже есть в симе, из базы нужны только фиксы, заходы и т.п., а их можно оформить по-другому. Поэтому я и тяну маяки из сима на основе выставленного радиуса устр-ва с небольшим запасом.
Для разработчиков карт.
Формулы для вычисления азимута ортодромического и дистанции ортодромической я взял из хорошего морского пособия, как-то ближе и понятнее оно мне.
Приведенные формулы работают во всем диапазоне дистанций.
Пояснение:
— сначала рассчитываются азимут и дистанция ортодромические по координатам двух точек;
— затем рассчитываются поправки к ним; поправка к азимуту незначительна, не превышает 0.2 градусов и для рисования карты можно ею пренебречь; поправка к дистанции может быть достаточно большой, ее целесообразно вычислять.
При работе с формулами надо уделить особое внимание размерности величин, иначе коэффициенты формул будут неверны!
Азимут вычисляется в четвертной размерности, т.е. от 0 до 90 градусов. Для перевода его в круговой отсчет надо воспользоваться правилом, помещенным в верхней части страницы с формулами. Значение четвертного азимута при переводе в круговой отсчет берется без знака, т.е. абсолютное значение!
Пример в качестве теста:
Поправка Д = -0.54389 градусов
Прикрепленные изображения
Пробовал читать данные для построения карты и через fs9gps. Нашел на форуме fsdeveloper.com даже исходники С++ для карты FS9. В девятке этот проект работает прекрасно, а в десятке не хочет. На поле карты есть только поле и ничего более. Разобраться в этом проекте не смог, поэтому и решил делать все свое с нуля.
За файл Complete Guidebook v1.1.pdf большое спасибо! Не знал раньше о его существовании. Скачал, почитаю, уверен, что пригодится.
Всем программистам посоветую вот это http://williams.best….net/avform.htm
Описано понятным языком и с упором именно на программирование.
Полезный ресурс, спасибо! Кое-что возьму на вооружение.
Исходные формулы А и Д на этом ресурсе те же, что и в приведенном мною пособии, это вызывает к ресурсу доверие.
Помаленьку дело с картой продвигается. Масштаб все же понадобился, как я уже говорил — 10 пкс = 1 миля.
При размере поля карты 800х440 пикселов при таком масштабе и шкале Range 35 миль аэродром отображается вполне прилично.
Теперь уперся в проблему отображения множества аэропортов. Если их будет 100 в выбранном радиусе?
Это же для каждого из них в программу надо включать свой блок рисования со своими координатами X Y!
У меня этот блок составляет 7 строчек. Это получается, надо писать 700 строчек и для каждого аэропорта, который еще неизвестно, будет или нет в данном случае, выделять память?
А еще отображать другие элементы карты!
Чувствую, что-то не так делаю.
Прикрепленные изображения
Конечно не так. Можно спросить, как Вы пишете? Просто можно объяснить всё по полочкам, но это требует знания парадигм ООП и т.п. Ибо «блок 7 строчек» — это метод класса, аэропорт — навигационный элемент, как и ВОР, НДБ и т.д. Надо решить три проблемы: собрать ВСЕ элементы навигации в заданом радиусе, разложить их на типы сохранив в одном списке и вывести собсно на экран с учётом поворота карты, курса самолёта и т.п. Всё это очень легко решаемо с помощью ООП, процедурное программирование точно выльется в 700 или больше строк.
Пишу с использованием ООП и GDI+. Проект карты на данный момент включает 7 заголовочных файлов, 8 файлов исходного кода, 1 файл ресурса rc и два файла самого ресурса (bmp и текста). Файлов ресурсов (txt) будет значительно больше, думаю не меньше десятка.
Однако я вижу, что применение объектов не уменьшает количества шагов, выполняемых программой. Оно лишь вносит некоторое удобство для программиста и сокращает видимое количество строк. Семьсот строчек никуда не денутся, просто они будут записаны в виде 10 строчек. Не уменьшают они и выделяемую память. Поэтому вопрос производительности с применением ООП радикально не решается..
Возможно, что я неверно понимаю принцип отрисовки элементов карты в GDI+. Пока я исхожу из того, что каждый рисованный элемент карты (значок аэропорта, текст, линия, значок VOR, NDB, путевой точки и т.д.) должен иметь свой блок рисования, с использованием класса объекта или нет — это уже другой вопрос. И все эти блоки одновременно должны обновляться с каждым кадром или с установленной периодичностью. Таким образом, в обработке одновременно и постоянно должно находиться большущее число графических элементов, которые попадают в видимое поле карты.
Поэтому я и засомневался, сможет ли компьютер переваривать все это в процессе полета? Может быть как-то по-другому можно рисовать множество одинаковых элементов в разных координатах?
Может быть формировать из всего этого статичные картинки и обновлять с каждым кадром? Но будет ли успевать программа за доли секунды формировать такие картинки?
Мне кажется Вы задумываетесь малость не о том. В симе у Вас не особо много возможностей выбрать момент отрисовки, для этого есть только PANEL_SERVICE_PRE_UPDATE/DRAW. Подумайте о классовой диаграмме, разбейте все элементы карты на типы, подтипы и т.п., выявите общие свойства, это даст возможность написать общий функционал один раз и использовать его эффективно.
Ещё один момент: рисовать всё по точкам/отрезкам можно, но не везде имеет смысл. Т.е. всякие мелкие стрелочки, маркеры и т.п. рисовать векторами — зачем? Можно использовать технику блитинга, ибо блитинг прямоугольных поверхностей поддерживается давно на аппаратном уровне. В тамагочи я так и делаю, у меня большинство элементов рисованы в виде картинок (мало того, большинство это большинства вообще построено с использованием спрайтов). Рисую я только динамическую часть (например в кадре топливной системы на КИНО активные топливные магистрали). Касаемо карт тоже проблем нету — я уже показывал скриншот с маяками в радиусе 1380км, ни один ФПС не съедается.
А вообще я по-моему Вас гружу уже всякой спецификой. Не обращайте внимания пока на размер кода, пишите как думали. Оптимизировать можно до бесконечности.
Сообщение отредактировал icebear: 17 January 2014 — 16:47
Именно такая специфика и полезна! Большое спасибо за подсказки и советы, методики и организация программы становятся всё понятнее!
Загрузил аэродромы Московской воздушной зоны с последовательной прорисовкой всех элементов. К счастью никакого торможения нет, в полете крутил Сессну-172 как только на ней это возможно. ФПС держался на уровне 44. Правда и аэродромов маловато, однако приятно.
Прикрепленные изображения