Comments 35
В статье описываются методы, но совершенно не наблюдается ответ на простой вопрос: «Зачем?» Проекция Гаусса-Крюгера имеет свои конкретные задачи и область применимости. Что вы хотите сделать помимо них, в статье никак не раскрывается.
Данный метод был разработан для картографической системы, которая работает именно в этой проекции.
Хорошо. Какие цели и задачи ставит перед собой эта система? Вы сейчас попытались изобрести псевдоконическую проекцию.
Исходные для карты, которые используются в этой системе, используют проекцию Гаусса-Крюгера (до масштаба 1кк). И поэтому необходимо было придумать метод, который бы позволял отображать некоторую область карты в этой проекции определенного масштаба без разрывов и искажений с поворотом относительно севера и зуммирования. Необходимо отображать одновременно более одного осевого меридиана и при этом данные должны оставаться в исходной проекции.
Цели — бортовое применение.
Цели — бортовое применение.
А почему бы не использовать более подходящие для этих целей проекции? Сходите в Ленинскую библиотеку, посмотрите на полетные карты.
Ответ прост: Потому что необходимо использовать именно эту проекции.
Увы, на любой конференции такой аргумент будет осмеян, а автор будет подвергнут суровому остракизму.
Есть такой документ Техническое задание.
То есть прихоть заказчика?
Тогда строго определяйте область применения.
Выставлять спущенное сверху ТЗ как абсолютную истину для читателя не стоит.
Тогда строго определяйте область применения.
Выставлять спущенное сверху ТЗ как абсолютную истину для читателя не стоит.
Я старался в статье для хабра исключить слова «бортовой» и «бортовая цифровая вычислительная машина» и сфокусироваться только на самом методе.
«Бортовые цифровые вычислительные машины» нынче есть почти в каждом современном автомобиле. В том числе решающие вашу задачу, показ карты.
Дабы не быть голословным теоретиком, самое красивое решение ближайшей к вашей задачи, которое я видел, было в проекте ТОПО.Беларусь для Garmin.
Исходный формат, как и у вас — SXF. Сконвертирован из листов в де-факто стандартный любительский MP, в WGS84. Сшит в одно общее полотно. Сконвертирован в формат Garmin.
Дальше — фаза отображения, на которой уже можно изголяться, как угодно. Внутри гарминовского формата всё лежит в виде r-дерева, из которого можно быстро достать любой кусок в том же самом WGS84. Большинство устройств показывают карту в равнопромежуточной проекции с φ0, равным центру экрана, полностью избегая искажений в пределах экрана на ближних зумах.
Что конкретно в техническом задании мешает сделать что-то подобное?
Дабы не быть голословным теоретиком, самое красивое решение ближайшей к вашей задачи, которое я видел, было в проекте ТОПО.Беларусь для Garmin.
Исходный формат, как и у вас — SXF. Сконвертирован из листов в де-факто стандартный любительский MP, в WGS84. Сшит в одно общее полотно. Сконвертирован в формат Garmin.
Дальше — фаза отображения, на которой уже можно изголяться, как угодно. Внутри гарминовского формата всё лежит в виде r-дерева, из которого можно быстро достать любой кусок в том же самом WGS84. Большинство устройств показывают карту в равнопромежуточной проекции с φ0, равным центру экрана, полностью избегая искажений в пределах экрана на ближних зумах.
Что конкретно в техническом задании мешает сделать что-то подобное?
Уточню. Речь идет про летательные аппараты, и соответственно требования к аппаратной части совершенно другие, которая, мягко говоря, не блещет производительностью и емкостью накопителей. Я, разумеется, не могу вдаваться в технические подробности.
Понятное дело, что на PC или на том же смартфоне(sic!) можно реализовать более сложные алгоритмы.
Проблема состоит в том, что необходимо отображать карту именно в проекции ГК для масштабов (1:100k — 1:1M) и в проекции Меркатора(1:5M). Это требование прописано в ТЗ. У нас, конечно не один проект, но требования к проекциям и масштабам везде примерно одинаковое.
Уточню — карта полностью векторная и хранить ее необходимо именно в векторном формате. Если хранить карту в геоцентрической WGS84 потребуется произвести пересчет на борту всех точек всех объектов после выборки этого куска из базы, проще хранить уже в целевой проекции. Объектов очень много. Тут опять же производительность.
То есть наилучшее решение которое у нас получилось — хранить карту, разбитую на фрагменты в необходимой проекции.
Подытожу: Мешает явное указание проекций в Т.З. и низкая производительность.
Понятное дело, что на PC или на том же смартфоне(sic!) можно реализовать более сложные алгоритмы.
Проблема состоит в том, что необходимо отображать карту именно в проекции ГК для масштабов (1:100k — 1:1M) и в проекции Меркатора(1:5M). Это требование прописано в ТЗ. У нас, конечно не один проект, но требования к проекциям и масштабам везде примерно одинаковое.
Уточню — карта полностью векторная и хранить ее необходимо именно в векторном формате. Если хранить карту в геоцентрической WGS84 потребуется произвести пересчет на борту всех точек всех объектов после выборки этого куска из базы, проще хранить уже в целевой проекции. Объектов очень много. Тут опять же производительность.
То есть наилучшее решение которое у нас получилось — хранить карту, разбитую на фрагменты в необходимой проекции.
Подытожу: Мешает явное указание проекций в Т.З. и низкая производительность.
Производительность и ёмкость накопителей — понятие растяжимое. Гарминовские навигаторы тоже ею не блещут (десятки мегагерц, сотни мегабайт места до не столь уж и давних пор), но с задачей справляются без подобных извращений.
«Пересчёт всех точек» при нормальной оптимизации кода для отображения на экране представляет из себя масштабирование+поворот, которые у вас уже и так выполняются. Вот только поворот надо выполнять один раз, а не несколько и разных на разных участках.
Ну и любые алгоритмы оптимизации выборки на границах отработают на порядки лучше — вам надо будет выбирать из одной непрерывной карты, а не из нескольких. Так что использование вашего подхода в условиях ограниченного хардваря вдвойне непонятно.
«Пересчёт всех точек» при нормальной оптимизации кода для отображения на экране представляет из себя масштабирование+поворот, которые у вас уже и так выполняются. Вот только поворот надо выполнять один раз, а не несколько и разных на разных участках.
Ну и любые алгоритмы оптимизации выборки на границах отработают на порядки лучше — вам надо будет выбирать из одной непрерывной карты, а не из нескольких. Так что использование вашего подхода в условиях ограниченного хардваря вдвойне непонятно.
По мимо задачи формирования изображения одной лишь векторной карты присутствует задача формирования рельефа, задача формирования подписей объектов, точечных объектов, искусственный препятствий, аэронавигационных данных и тп. Это только визуальные задачи.
Помимо визуальных задач, если еще расчетные и задачи по выдачи потребителям.
И все это, по сути, работает на одном процессоре.
Требования же к скорости формирования изображения не менее 25фпс.
Пересчет всех точек. Чтобы произвести пересчет точек вида масштаб+поворот достаточно просто умножить их на матрицу преобразования. Средствами OpenGL это делается аппаратно, но не всегда у нас есть вообще что-то кроме fb.
Для того чтобы преобразовать координаты из СК-42 необходимо использовать монстроуозные формулы из ГОСТ Р51794-2008. А если брать пересчет МГС-84 в ГК, то нужен промежуточный пересчет в СК-42.
Затраты на формирования параметров GKZone много меньше, чем просто затраты на формирование изображения.
Выбирать фрагменты и известными индексами гораздо быстрее, чем выбирать объекты из непрерывной карты. То есть мы сразу знаем какие фрагменты и откуда необходимо прочитать исходя из матриц в GKZone. При движении карты не приходиться формировать листы и текстуры для уже подгруженных фрагментов. Работать с фрагментами проще и понятнее чем с непрерывным массивом («окном» ) объектов. Я бы мог написать статью как раз про подход к формированию карт и к ее визуализации.
Вы не сможете читать с диска все объекты из одного места. Фрагмент же читается целиком.
Я, конечно, могу ошибаться и ваш подход быстрее.
Если у вас есть опыт работы с встраиваемыми ГИС, то не могли бы вы поделиться ссылками на какую-нибудь литературу по этому поводу, описание форматов, алгоритмов, опенсорс проекты и т.п.
Помимо визуальных задач, если еще расчетные и задачи по выдачи потребителям.
И все это, по сути, работает на одном процессоре.
Требования же к скорости формирования изображения не менее 25фпс.
Пересчет всех точек. Чтобы произвести пересчет точек вида масштаб+поворот достаточно просто умножить их на матрицу преобразования. Средствами OpenGL это делается аппаратно, но не всегда у нас есть вообще что-то кроме fb.
Для того чтобы преобразовать координаты из СК-42 необходимо использовать монстроуозные формулы из ГОСТ Р51794-2008. А если брать пересчет МГС-84 в ГК, то нужен промежуточный пересчет в СК-42.
Затраты на формирования параметров GKZone много меньше, чем просто затраты на формирование изображения.
Выбирать фрагменты и известными индексами гораздо быстрее, чем выбирать объекты из непрерывной карты. То есть мы сразу знаем какие фрагменты и откуда необходимо прочитать исходя из матриц в GKZone. При движении карты не приходиться формировать листы и текстуры для уже подгруженных фрагментов. Работать с фрагментами проще и понятнее чем с непрерывным массивом («окном» ) объектов. Я бы мог написать статью как раз про подход к формированию карт и к ее визуализации.
Вы не сможете читать с диска все объекты из одного места. Фрагмент же читается целиком.
Я, конечно, могу ошибаться и ваш подход быстрее.
Если у вас есть опыт работы с встраиваемыми ГИС, то не могли бы вы поделиться ссылками на какую-нибудь литературу по этому поводу, описание форматов, алгоритмов, опенсорс проекты и т.п.
Вы немного меня не понимаете, видимо.
Почему проблемой одновременного отображения листов проекции Гаусса-Крюгера или UTM никто не занимается? Потому что в этом нет необходимости. Тот факт, что вам пришлось решать эту задачу, вызывает глубочайшее сочувствие и уважение к упорству в изобретении псевдоконической проекции.
Ваш метод не занимается описанием земной поверхности, не создает новую модель, а пытает собрать из уже существующей модели еще одну модель. Постмодернизм в картографии какой-то.
Но у любого картографа вызовет как минимум вопросы цель таких изысканий. Она ненаучна, она является костылем для некоего ПО, которое спроектировано заточенным под одну, неоптимальную для своих задач проекцию. Практически любое геоинформационное ПО сейчас умеет отображать данные в любой подходящей проекции.
Почему проблемой одновременного отображения листов проекции Гаусса-Крюгера или UTM никто не занимается? Потому что в этом нет необходимости. Тот факт, что вам пришлось решать эту задачу, вызывает глубочайшее сочувствие и уважение к упорству в изобретении псевдоконической проекции.
Ваш метод не занимается описанием земной поверхности, не создает новую модель, а пытает собрать из уже существующей модели еще одну модель. Постмодернизм в картографии какой-то.
Но у любого картографа вызовет как минимум вопросы цель таких изысканий. Она ненаучна, она является костылем для некоего ПО, которое спроектировано заточенным под одну, неоптимальную для своих задач проекцию. Практически любое геоинформационное ПО сейчас умеет отображать данные в любой подходящей проекции.
В той сфере, в которой мне приходиться работать, в качестве исходных данных используются листы SXF в проекции Гаусса-Крюгера для карт малого масштаба и проекция Меркатора для крупномасштабных(обзорных) карт. В техническом задании на большинство проектов, с которыми мне приходиться работать, четко прописано использования этих данных в качестве исходных. Так же существуют задачи по выдаче геоинформационных данных бортовым потребителям в заданной проекции. А так же требования по соответствию цифровых изображений бумажным аналогам этих листов.
Здесь есть четкие требования, которые принимаются не нами. Применение подобных карт как стандарт де факто.
Другие существующие решения очень примитивны и сводятся к увеличению избыточности данных и сшиванию по одному осевому меридиану дополнительных листов карт, при этом на борту очень ограниченные вычислительные ресурсы и ресурсы памяти. Поэтому данный метод в этой сфере очень полезен.
Статья не претендует на особую научность. Цель данной статьи рассказать о проблемах, которые были поставлены перед нами и о способе их решения.
Вы даже не представляете какие абсурдные требования существуют в этой сфере и насколько все отстает от переднего края технологий.
Прошу прощения за ссылки на википедию, просто последние ваши комментарии походили на некий троллинг.
Здесь есть четкие требования, которые принимаются не нами. Применение подобных карт как стандарт де факто.
Другие существующие решения очень примитивны и сводятся к увеличению избыточности данных и сшиванию по одному осевому меридиану дополнительных листов карт, при этом на борту очень ограниченные вычислительные ресурсы и ресурсы памяти. Поэтому данный метод в этой сфере очень полезен.
Статья не претендует на особую научность. Цель данной статьи рассказать о проблемах, которые были поставлены перед нами и о способе их решения.
Вы даже не представляете какие абсурдные требования существуют в этой сфере и насколько все отстает от переднего края технологий.
Прошу прощения за ссылки на википедию, просто последние ваши комментарии походили на некий троллинг.
Если все, кто решает абсурдные задачи, будут писать об этом на хабр, то энтропию мы никогда не победим.
Ага. Карбоновая труба к паровозу.
Ошибки на уровне постановки. Какой уж тут троллинг…
Ошибки на уровне постановки. Какой уж тут троллинг…
Я не вижу ничего плохого в том, чтобы описать метод для решения специфической задачи. Если вы не используете подобные проекции в вашей деятельности, это еще не значит, что другим это не потребуется. Тем более это моя первая статья тут.
Не задачи абсурдные, а требования к ним.
У нас получился не особо полезный диалог. Учту, что хабр не любит статей про не популярные проекции :)
Не задачи абсурдные, а требования к ним.
У нас получился не особо полезный диалог. Учту, что хабр не любит статей про не популярные проекции :)
Опять мимо. Уважаемый, ну возьмите себя в руки, почитайте хотя бы пару статей про проекции и одну про геоинформационное ПО. Черт побери, да возьмите, наконец, Картографию Берлянта (я вам подарю!), отличная книга, почти научпоп.
Проекции не бывают популярными или нет. Разные проекции подходят под разные задачи. Проекция Гаусса-Крюгера, как и UTM, используется для топографических карт. Для полетных карт большого протяжения используется проекция Меркатора. Не любите Ленинку, сходите во ФГУП ЦАИ, поинтересуйтесь у них о полетных картах. Откройте для себя многообразие карт и проекций, раз уж решили поговорить с картографами и ГИС-специалистами.
Проекции не бывают популярными или нет. Разные проекции подходят под разные задачи. Проекция Гаусса-Крюгера, как и UTM, используется для топографических карт. Для полетных карт большого протяжения используется проекция Меркатора. Не любите Ленинку, сходите во ФГУП ЦАИ, поинтересуйтесь у них о полетных картах. Откройте для себя многообразие карт и проекций, раз уж решили поговорить с картографами и ГИС-специалистами.
Разрабатывается не пользовательская универсальная ГИС, а бортовая система, в которой есть четкие требования по используемым проекциям и задан масштабный ряд, и необходимые пересчеты между проекциями.
В качестве исходных данных как раз и используются топографические карты мелкого масштаба. Поскольку данные карты содержат множество необходимой семантической информации. Для обзорных карт (1:5М) используется проекция Меркатора.
Я не понимаю в чем вы меня пытаетесь убедить?
Вы меня спросили про применение описанного метода, я вам ответил. Вы же обвиняете меня в некомпетентности. Я не претендую на звание эксперта в гис, но по работе в этой теме мне приходится общаться и с летчиками и с картографами и с ГИС-специалистами.
Повторюсь еще раз. Для данной задачи выбрано использование именно этих проекций, и выбрано не дилетантами, а как раз специалистами. Про абсурдные требования — я имел ввиду не требования к проекциями и т.д, а требования с самой системе, при том что аппаратное обеспечение оставляет желать лучшего, но это не тема данной дискуссии.
И на счет взятия себя в руки. Это не баттхерт, а просто желание понять, что же вы хотите сказать вашими комментариями? Я действительно хочу услышать компетентное мнение, но я пока слышу лишь обвинение в некомпетентности. Если вы так считаете, то зачем тратите время на ответы?
В качестве исходных данных как раз и используются топографические карты мелкого масштаба. Поскольку данные карты содержат множество необходимой семантической информации. Для обзорных карт (1:5М) используется проекция Меркатора.
Я не понимаю в чем вы меня пытаетесь убедить?
Вы меня спросили про применение описанного метода, я вам ответил. Вы же обвиняете меня в некомпетентности. Я не претендую на звание эксперта в гис, но по работе в этой теме мне приходится общаться и с летчиками и с картографами и с ГИС-специалистами.
Повторюсь еще раз. Для данной задачи выбрано использование именно этих проекций, и выбрано не дилетантами, а как раз специалистами. Про абсурдные требования — я имел ввиду не требования к проекциями и т.д, а требования с самой системе, при том что аппаратное обеспечение оставляет желать лучшего, но это не тема данной дискуссии.
И на счет взятия себя в руки. Это не баттхерт, а просто желание понять, что же вы хотите сказать вашими комментариями? Я действительно хочу услышать компетентное мнение, но я пока слышу лишь обвинение в некомпетентности. Если вы так считаете, то зачем тратите время на ответы?
Вы, дорогой мой, не пытаетесь и даже не хотите слушать, что вам тут говорят. Это очень печально. То, что «специалисты» пишут такое ТЗ, говорит лишь об их крайне низком уровне компетентности. К вам лично претензий нет. Сказали копать — вы копаете. А мы посмеялись, уж извините.
Ну почему же. Я отлично понимаю, что существует множество других проекций и что подобные задачи можно гораздо удобнее решать. И не спорю с этим. Но вы поймите, что существуют проекты в которых приходиться использовать подобные вещи, без вариантов.
Вы спрашивали про задачу, в которой я применял метод, описанной в статье. Я ответил. И ответил почему мне приходится его применять.
Надеюсь, ваши вопросы исчерпаны?
Мне просто уже больше нечего добавить.
Вы спрашивали про задачу, в которой я применял метод, описанной в статье. Я ответил. И ответил почему мне приходится его применять.
Надеюсь, ваши вопросы исчерпаны?
Мне просто уже больше нечего добавить.
21 век на дворе. Почему исходные данные нельзя переварить в нормальный де-факто стандартный EPSG:4326 и визуализировать в любой из proj4-проекций? Исходный формат и рабочий формат — вещи немного разные.
Или вам по техзаданию ещё и рамки с разметкой от SXF-недокарт оставлять надобно? :3
Или вам по техзаданию ещё и рамки с разметкой от SXF-недокарт оставлять надобно? :3
Рабочий формат у нас не SXF, а свой «модный» формат, который конвертируется из SXF с исправлением этих рамок и разбиением карты на фрагменты. У нас задана по техзаданию именно проекция отображения и масштабный ряд. Координаты ЛА на элипсоиде могут приходить в различных системах (СК-42, СК-95, WGS-84, ПЗ-90), а вот визуализивать двухмерное картографическое изображение местности и рельефа земной поверхности мы должны именно в ГК и Меркаторе. Вот и приходиться выкручиваться подобными методами. У нас, к сожалению, 21 первый век только наступает.
А параметры проекции Меркатора заданы-то? Их много разных. И в ней ваша задача решается на порядок проще — зон нет, стыковать ничего не надо. И углы сохраняются.
Параметры проекции Меркатора для 1:5М берутся из заголовка sxf.
В данной задаче мы не можем использовать проекцию, отличную от ГК, на других масштабах.
На крупном масштабе у нас и не возникало подобных проблем.
В данной задаче мы не можем использовать проекцию, отличную от ГК, на других масштабах.
На крупном масштабе у нас и не возникало подобных проблем.
Почему не можете-то? Вы полиграфию печатаете или бортовой навигатор делаете?
Возникают дурацкие подозрения, вроде того, что карту вы храните растром, потому что не осилили сконвертировать SXF во что-то человеческое векторное (формат сам по себе мозговзрывающий, и альтернативных реализаций его, поэтому, практически в природе не встречается).
Возникают дурацкие подозрения, вроде того, что карту вы храните растром, потому что не осилили сконвертировать SXF во что-то человеческое векторное (формат сам по себе мозговзрывающий, и альтернативных реализаций его, поэтому, практически в природе не встречается).
Требования строгие. То есть вплоть до цвета отдельных объектов. Не то что проекция.
То есть карта на экране должна быть похожа на карту на бумаге.
Нет, карта полностью векторная со всей семантикой из sxf. А то что формат ужасен — я согласен.
То есть карта на экране должна быть похожа на карту на бумаге.
Нет, карта полностью векторная со всей семантикой из sxf. А то что формат ужасен — я согласен.
Вы цифровую карту или цифровую модель бумажной карты делаете, в конце концов?
Цвет — требование понятное и правильное (и то с поправкой на RGB/CMYK), в отличие от сохранения проекции.
Спорьте с авторами ТЗ, начальных аргументов вам насыпано достаточно.
Цвет — требование понятное и правильное (и то с поправкой на RGB/CMYK), в отличие от сохранения проекции.
Спорьте с авторами ТЗ, начальных аргументов вам насыпано достаточно.
Сложный вопрос :) Смысл в максимальной схожести с бумажными аналогами.
С авторами ТЗ такого уровня спорить не особо получиться. И тем более эти ТЗ уже приняты, согласованы, подписаны.
Вообщем спасибо за комментарии. Очень интересно послушать мнение других людей по поводу ГИС.
Я постараюсь расширить применяемые методы в будущих проектах. Я же и сам не в восторге от всего этого.
С авторами ТЗ такого уровня спорить не особо получиться. И тем более эти ТЗ уже приняты, согласованы, подписаны.
Вообщем спасибо за комментарии. Очень интересно послушать мнение других людей по поводу ГИС.
Я постараюсь расширить применяемые методы в будущих проектах. Я же и сам не в восторге от всего этого.
Вообще говоря, с этой панорамой вечно беда. Недавно приходилось выстраивать цепочку SXF — Esri GDB 10.0 — Esri GDB 9.3 — DGN. Веселый и поучительный опыт.
На самом деле, эта картинка должна была быть тут уже давно.
Sign up to leave a comment.
Метод формирования изображения в проекции Гаусса-Крюгера