Файл 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 будет выкаблучиваться и через него не удасться передать поля с геометрическими примитивами - у всех бдшек есть функции для преобразования во чтонибудь текстовое.
Нет ни каких ограничений.
Мы пока ходим вокруг да около. 
Информации много, спасибо! Буду читать.
Вот нашел статью на Хабре, прям в руку.
Данные нужно класть в БД, умеющую работать с пространственными данными самостоятельно. Например, в 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?
На самом деле ни одна карта не дает права пилоту опускаться ниже минимальной безопасной высоты. Для разных типов ЛА она разная, но с запасом перекрывает и высоту деревьев и погрешность.
При этом, даже при посадки ЛА может снижаться только до высоты принятия решения при помощи приборных методов определения высоты, если до высоты принятия решения визуальный контакт с наземными ориентирами не установлен - ЛА уходит на второй круг или на запасной аэродром.
Катастрофу под Смоленском помните? Там они опустились ниже высоты принятия решения без визуального контакта с наземными ориентирами. А у них на борту был и барометрический высотомер, и радиовысотомер, и глиссадно-курсовой комплекс. Как они ими пользовались - это уже второй вопрос.
Первым же остается вопрос о соблюдении РЛЭ. А РЛЭ запрещает опускаться ниже безопасной. Ну а про неё я уже писал.
Поэтому данные SRTM нас устраивают.
За информацию спасибо! Буду работать в указанном направлении.
Однако вопросы еще будут.
С уважением, Дмитрий.
defond, я по смежной специальности - инженер по БРЭО, так что в курсе ситуации.
То, что РЛЭ запрещает - это чудесно, но есть требования к аэронавигационной информации, которым радарные (srtm) и полученные методом анализа стереопар (aster gdem) данные принципиально не могут соответствовать в силу того, что именно они показывают.
И разброд в показаниях разных средств, указывающих относительную высоту, будет еще более дезорганизующим: бароальтиметр показывает барометрическую высоту по давлению аэродрома, РВ показывает свое (зависит от подстилающей), а эта шарманка показывает свое (тоже зависит от подстилающей). Как это скажется на безопасности полетов - сказать затрудняюсь.
Господа, вот есть один небольшой вопрос: Информация о высотах берется из определенных источников. Зондирование земной поверхности да, не запрещено, но чтобы дать тому или иному месту высотную составляющею, нужны материалы, которые согласуются или нет с существующей лицензией. Вопрос мой таков: Как все вышевысказавшиеся видят лицензионную чистоту вносимых данных высотной состовляющей карты ОСМ?
А еще более витиевато выразиться было можно, вместо того, чтобы спросить: “Какова лицензия данных SRTM и GDEM?”
Ответ: у этих данных проблема с последующим коммерческим использованием производных продуктов, а потому http://wiki.openstreetmap.org/wiki/ASTER и http://wiki.openstreetmap.org/wiki/SRTM
У нас, грубо говоря, дополнительный комплекс, и он ни коем образом не подменяет основные средства навигации и пилотирования. Поэтому данные о высоте рельефа будут поступать пилоту в опосредованном виде (изолиния или цветовое обозначение). Вычислить точную высоту по оттенку зеленого или коричневого будет ну крайне затруднительно. А высота будет выдаваться в стандартных барометрических значениях или по данным РВ (в случае его установки и исключительно в соответствующем режиме). Снижение по барометрической ниже минимума на маршруте приведет к буйству комплекса, миганию транспарантов и противного женского голоса. Поэтому пилоту будет не до вычисления высоты по цвету на карте.
По поводу лицензии - а что Вас заставляет использовать в продукте данные STRIM? Продавайте продукт без карт, но с возможностью просмотра и работы с данными. А пользователь пусть сам решает - нарушать лицензию или не стоит. У гармина формат закрыт, но утилит, которые работают с файлами данных полно.
GIMP - без проблем работает с файлами Фотошопа. И что-то я не помню особых претензий от Фотошопа.
Если вопрос был про смешивание данных, то Вам ответил BushmanK.
Если вопрос про совместное использование, то опять же - это выбор пользователя, если не доказано обратное.
Видимо как то так…