Изолинии высот

Не вопрос.

Есть авиационный комплекс. Пишется ПО на прологе (если знакомы). Нужно сделать блок навигации.

Навигационный блок представляет собой карту высот (высоты обозначаются цветом и изолиниями), карту ориентиров (населенные пункты, дороги, водные объекты и т.п.), карту аэродромов и ВОР-маяков, карту погоды, карту маршрута (маршрутная линия и специальные отметки). По большому счету это все слои, которые должны отображаться на навигационной карте.

Внешне навигационный блок выглядит вот так (условно, могут быть отличия).

Пролог может отрисовывать векторные карты, но для этого нужно получить координаты для полигонов, объектов и т.п.

Единственный формат, который я пока хоть немного понимаю - польский.

Сторонние программы для отрисовки карт нам не подходят. Комплекс должен отрисовывать карты самостоятельно.


Какая еще информация нужна?

Хм… задумка интересная и даже большая часть данных в ОСМ есть и карта погоды где-то была. Вот только хранить весь мир в .mp - это утопия, даже отфильтрованная на дороги, реки и НП. Тут как не крути необходима БД.

Файл mp с данными по рельефу, разделенные по регионам, есть. Карты погоды нет, поэтому если поделитесь - низкий Вам поклон! Интересует очень карта облаков и фронтов.

Вообще данные по погоде получаются нами отдельно.

В принципе файл mp можно обрабатывать и выбирать в БД только нужные данные. Это не самая большая сложность. У Гармина есть карты рельефа, но как работать с их форматом я пока не нашел.

Сейчас нам нужно определиться с источником данных по рельефу. Научиться читать формат, т.е. понять структуру. И попробовать его воспроизвести в виде карты.

Возможно, вам поможет http://planet.qgis.org/planet/tag/dem/ - тут строят изолинии по, если не путаю, srtm’овским рстрам. Для ASTER процедура примерно такая-же. Потом полученые изолинии можно в shp сохранить. shp помоему проще mp.

Остальные данные (дороги, реки, города, домики) на основе осм тоже можно взять в shp с гислаба (для снг) или геофабрики (для европы). Таким образом вам надо освоить работу с 1 широко документированным гисовским форматом - shp. mp - больше под автонавигацию приспособлен.

Мне это говорят уже несколько раз. Но shp формат нужно чем то открыть. Это ведь не текстовый файл. А как наша программа его откроет? ПО написано на Visual Prolog 7.4. И формат shp он не понимает.

А mp текстовый, его можно обработать утилитой - перегнать данные в БД. А из БД уже рисовать карту.

Пока у меня такая версия работы.

Можете посоветовать другой путь?

Вообще в прологе должны быть средства, чтобы прочитать файлик как набор байт, да и формат весьма распространен, может кто то уже написал парсер под пролог. Но, если с чтением бинарных файликов есть проблемы, можно перегнать в wkt/kml/geoJSON - они текстовые. Открыть посмотреть/обработать можно в любой настольной гис. К примеру - qgis.

Если всеравно вы записываете это в бд. То вопрос в каком виде это храниться в бд. Какой формат полей с геометрией?

Вот проект про погоду (http://openweathermap.org/). Если у Вас свой источник, то в чём собственно проблема ? Ведь кроме того что нарисовать облака на карте их как-то надо будет использовать при обработке данных.

Я не думаю, что на Прологе есть такой парсер. Но я уточню. Спасибо!

По поводу чтения бинарных файлов - тоже уточню.

Можете посоветовать источник адекватного описания структуры файлов wkt/kml/geoJSON?

Пока формата данных для БД нет. Мы только начали работать над навигационным блоком, т.е. сейчас идет сбор данных и выбор направления работы. Т.е. если Вы готовы что-то посоветовать - буду рад.

Видимо будет тип полигона/объекта и его координаты. Цвет, толщина линий и другие граф. признаки будут уже задаваться программой при рисовании.

Или есть другие предложения?

Данные будут использоваться обзорно, при принятии решения о выборе маршрута полета. Т.е. обходить облачность, отложить вылет и т.п. В расчетах будут использоваться точные данные по погоде от метеостанций аэродромов. Там есть специфические данные, которые обычные сервисы погоды не предоставляют.

А какая субд? Если есть возможность использовать postgres + postgis или SQLite (spatiallite) - то их и посоветую. Для них есть конверторы из shp готовые, на целевую систему потом просто дамп сольете.

Если в качестве субд можно использовать только что-то экзотическое/старое типа foxpro - ничего не посоветую :).

wkt или geoJSON - достаточно открыть готовый файлик. Полное описание рискну предположить что есть на сайте OGC (http://www.opengeospatial.org/)

SQLite пока подходит. Вроде сложностей быть не должно.

Посоветуете конвертер для SQLite и shp?

Сам я пользуюсь постгисиной для spatiallite http://www.gaia-gis.it/gaia-sins/spatialite-cookbook/html/impexp.html думаю официальный кукбук подойдет.

VIP с SQL-базами работает через ODBC, соответственно, работает со всем, что поддерживает ODBC.
Обычно это - MS SQL, ORACLE. кто-то упоминал работу с MYSQL.

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

Если ограничений нету - и у постгрехи и у spatiallite импорт из шейпов есть из коробки. У геопространственных расширений к ораклу и мсскьюлэь тоже должны быть. Если odbc будет выкаблучиваться и через него не удасться передать поля с геометрическими примитивами - у всех бдшек есть функции для преобразования во чтонибудь текстовое.

Нет ни каких ограничений.

Мы пока ходим вокруг да около. :slight_smile: Информации много, спасибо! Буду читать.

Вот нашел статью на Хабре, прям в руку.

Данные нужно класть в БД, умеющую работать с пространственными данными самостоятельно. Например, в sqlite (spatialite) или PostgreSQL (PostGIS). В этом случае будет возможность фильтровать геометрию средствами базы и работать всегда только с данными, попадающими в экстент текущего окна.

Конвертировать данные из шейпов (ESRI .shp) в базу можно множеством способов, включая банальный ogr2ogr из набора GDAL/OGR или FWTools. Пример - тут http://osgeo-org.1560.x6.nabble.com/ogr2ogr-and-spatialite-td3745308.html

Сами изолинии из любой доступной растровой модели местности (хоть SRTM, хоть GDEM) генерируются, например, http://www.gdal.org/gdal_contour.html А потом сгенерированное кладёте в базу и т.п. Никакая работа с польским форматом вам не требуется вообще. Как и OSM, правда.

Я только вот знаю, что в авиации есть разные способы исчисления высот, но в картах-то должна быть указана высота земли, как подстилающей поверхности. А не высота условной поверхности, покрывающей верхушки деревьев. В случае же SRTM и GDEM, это будет, в том числе, высота верхушек деревьев над эллипсоидом WGS84.

Спасибо!

В авиации высоты бывают разными - барометрическая, истинная и т.д. Вас смущает, что это высота условной поверхности, а Вы учитываете погрешность той же SRTM? :slight_smile:

На самом деле ни одна карта не дает права пилоту опускаться ниже минимальной безопасной высоты. Для разных типов ЛА она разная, но с запасом перекрывает и высоту деревьев и погрешность.

При этом, даже при посадки ЛА может снижаться только до высоты принятия решения при помощи приборных методов определения высоты, если до высоты принятия решения визуальный контакт с наземными ориентирами не установлен - ЛА уходит на второй круг или на запасной аэродром.

Катастрофу под Смоленском помните? Там они опустились ниже высоты принятия решения без визуального контакта с наземными ориентирами. А у них на борту был и барометрический высотомер, и радиовысотомер, и глиссадно-курсовой комплекс. Как они ими пользовались - это уже второй вопрос.

Первым же остается вопрос о соблюдении РЛЭ. А РЛЭ запрещает опускаться ниже безопасной. :slight_smile: Ну а про неё я уже писал.

Поэтому данные SRTM нас устраивают.

За информацию спасибо! Буду работать в указанном направлении.

Однако вопросы еще будут.

С уважением, Дмитрий.

defond, я по смежной специальности - инженер по БРЭО, так что в курсе ситуации.
То, что РЛЭ запрещает - это чудесно, но есть требования к аэронавигационной информации, которым радарные (srtm) и полученные методом анализа стереопар (aster gdem) данные принципиально не могут соответствовать в силу того, что именно они показывают.

И разброд в показаниях разных средств, указывающих относительную высоту, будет еще более дезорганизующим: бароальтиметр показывает барометрическую высоту по давлению аэродрома, РВ показывает свое (зависит от подстилающей), а эта шарманка показывает свое (тоже зависит от подстилающей). Как это скажется на безопасности полетов - сказать затрудняюсь.

Господа, вот есть один небольшой вопрос: Информация о высотах берется из определенных источников. Зондирование земной поверхности да, не запрещено, но чтобы дать тому или иному месту высотную составляющею, нужны материалы, которые согласуются или нет с существующей лицензией. Вопрос мой таков: Как все вышевысказавшиеся видят лицензионную чистоту вносимых данных высотной состовляющей карты ОСМ?