Прошу прощения, включен в данном конкретном случае, на счет всех не знаю. Смысл в том, что если у вас это включено и вы это используете в своем аккаунте, при входе в чужой аккаунт, этот аккаунт получает такие же возможности управления телефоном. В большинстве случаев, конечно, входить в чужой аккаунт никому не нужно…
Есть один серьезный недостаток или можно сказать уязвимость, который когда я заметил — был, мягко говоря, в недоумении: Если залогиниться с какого-нибудь устройства в аккаунт, но это устройство будет доступно с этого аккаунта и его потом невозможно удалить.
У нас в группе есть так называемая «общая почта» группы, на которую приходят сообщения от учебной части (так было удобнее), так вот на этой почте 10 устройств, и можно позванивать любое, а так же определить их местоположения, устанавливать и удалять приложения.
Сложный вопрос :) Смысл в максимальной схожести с бумажными аналогами.
С авторами ТЗ такого уровня спорить не особо получиться. И тем более эти ТЗ уже приняты, согласованы, подписаны.
Вообщем спасибо за комментарии. Очень интересно послушать мнение других людей по поводу ГИС.
Я постараюсь расширить применяемые методы в будущих проектах. Я же и сам не в восторге от всего этого.
По мимо задачи формирования изображения одной лишь векторной карты присутствует задача формирования рельефа, задача формирования подписей объектов, точечных объектов, искусственный препятствий, аэронавигационных данных и тп. Это только визуальные задачи.
Помимо визуальных задач, если еще расчетные и задачи по выдачи потребителям.
И все это, по сути, работает на одном процессоре.
Требования же к скорости формирования изображения не менее 25фпс.
Пересчет всех точек. Чтобы произвести пересчет точек вида масштаб+поворот достаточно просто умножить их на матрицу преобразования. Средствами OpenGL это делается аппаратно, но не всегда у нас есть вообще что-то кроме fb.
Для того чтобы преобразовать координаты из СК-42 необходимо использовать монстроуозные формулы из ГОСТ Р51794-2008. А если брать пересчет МГС-84 в ГК, то нужен промежуточный пересчет в СК-42.
Затраты на формирования параметров GKZone много меньше, чем просто затраты на формирование изображения.
Выбирать фрагменты и известными индексами гораздо быстрее, чем выбирать объекты из непрерывной карты. То есть мы сразу знаем какие фрагменты и откуда необходимо прочитать исходя из матриц в GKZone. При движении карты не приходиться формировать листы и текстуры для уже подгруженных фрагментов. Работать с фрагментами проще и понятнее чем с непрерывным массивом («окном» ) объектов. Я бы мог написать статью как раз про подход к формированию карт и к ее визуализации.
Вы не сможете читать с диска все объекты из одного места. Фрагмент же читается целиком.
Я, конечно, могу ошибаться и ваш подход быстрее.
Если у вас есть опыт работы с встраиваемыми ГИС, то не могли бы вы поделиться ссылками на какую-нибудь литературу по этому поводу, описание форматов, алгоритмов, опенсорс проекты и т.п.
Уточню. Речь идет про летательные аппараты, и соответственно требования к аппаратной части совершенно другие, которая, мягко говоря, не блещет производительностью и емкостью накопителей. Я, разумеется, не могу вдаваться в технические подробности.
Понятное дело, что на PC или на том же смартфоне(sic!) можно реализовать более сложные алгоритмы.
Проблема состоит в том, что необходимо отображать карту именно в проекции ГК для масштабов (1:100k — 1:1M) и в проекции Меркатора(1:5M). Это требование прописано в ТЗ. У нас, конечно не один проект, но требования к проекциям и масштабам везде примерно одинаковое.
Уточню — карта полностью векторная и хранить ее необходимо именно в векторном формате. Если хранить карту в геоцентрической WGS84 потребуется произвести пересчет на борту всех точек всех объектов после выборки этого куска из базы, проще хранить уже в целевой проекции. Объектов очень много. Тут опять же производительность.
То есть наилучшее решение которое у нас получилось — хранить карту, разбитую на фрагменты в необходимой проекции.
Подытожу: Мешает явное указание проекций в Т.З. и низкая производительность.
Ну почему же. Я отлично понимаю, что существует множество других проекций и что подобные задачи можно гораздо удобнее решать. И не спорю с этим. Но вы поймите, что существуют проекты в которых приходиться использовать подобные вещи, без вариантов.
Вы спрашивали про задачу, в которой я применял метод, описанной в статье. Я ответил. И ответил почему мне приходится его применять.
Надеюсь, ваши вопросы исчерпаны?
Мне просто уже больше нечего добавить.
Параметры проекции Меркатора для 1:5М берутся из заголовка sxf.
В данной задаче мы не можем использовать проекцию, отличную от ГК, на других масштабах.
На крупном масштабе у нас и не возникало подобных проблем.
Рабочий формат у нас не SXF, а свой «модный» формат, который конвертируется из SXF с исправлением этих рамок и разбиением карты на фрагменты. У нас задана по техзаданию именно проекция отображения и масштабный ряд. Координаты ЛА на элипсоиде могут приходить в различных системах (СК-42, СК-95, WGS-84, ПЗ-90), а вот визуализивать двухмерное картографическое изображение местности и рельефа земной поверхности мы должны именно в ГК и Меркаторе. Вот и приходиться выкручиваться подобными методами. У нас, к сожалению, 21 первый век только наступает.
Разрабатывается не пользовательская универсальная ГИС, а бортовая система, в которой есть четкие требования по используемым проекциям и задан масштабный ряд, и необходимые пересчеты между проекциями.
В качестве исходных данных как раз и используются топографические карты мелкого масштаба. Поскольку данные карты содержат множество необходимой семантической информации. Для обзорных карт (1:5М) используется проекция Меркатора.
Я не понимаю в чем вы меня пытаетесь убедить?
Вы меня спросили про применение описанного метода, я вам ответил. Вы же обвиняете меня в некомпетентности. Я не претендую на звание эксперта в гис, но по работе в этой теме мне приходится общаться и с летчиками и с картографами и с ГИС-специалистами.
Повторюсь еще раз. Для данной задачи выбрано использование именно этих проекций, и выбрано не дилетантами, а как раз специалистами. Про абсурдные требования — я имел ввиду не требования к проекциями и т.д, а требования с самой системе, при том что аппаратное обеспечение оставляет желать лучшего, но это не тема данной дискуссии.
И на счет взятия себя в руки. Это не баттхерт, а просто желание понять, что же вы хотите сказать вашими комментариями? Я действительно хочу услышать компетентное мнение, но я пока слышу лишь обвинение в некомпетентности. Если вы так считаете, то зачем тратите время на ответы?
Я имею ввиду, что кулинарные рецепты, это не то, для чего можно использовать такой потенциал.
Экспертные системы в медицине — вот куда надо направлять его. Лучше эта система спасет жизни людей, чем сделает мой бутерброд еще вкуснее.
Я не вижу ничего плохого в том, чтобы описать метод для решения специфической задачи. Если вы не используете подобные проекции в вашей деятельности, это еще не значит, что другим это не потребуется. Тем более это моя первая статья тут.
Не задачи абсурдные, а требования к ним.
У нас получился не особо полезный диалог. Учту, что хабр не любит статей про не популярные проекции :)
В той сфере, в которой мне приходиться работать, в качестве исходных данных используются листы SXF в проекции Гаусса-Крюгера для карт малого масштаба и проекция Меркатора для крупномасштабных(обзорных) карт. В техническом задании на большинство проектов, с которыми мне приходиться работать, четко прописано использования этих данных в качестве исходных. Так же существуют задачи по выдаче геоинформационных данных бортовым потребителям в заданной проекции. А так же требования по соответствию цифровых изображений бумажным аналогам этих листов.
Здесь есть четкие требования, которые принимаются не нами. Применение подобных карт как стандарт де факто.
Другие существующие решения очень примитивны и сводятся к увеличению избыточности данных и сшиванию по одному осевому меридиану дополнительных листов карт, при этом на борту очень ограниченные вычислительные ресурсы и ресурсы памяти. Поэтому данный метод в этой сфере очень полезен.
Статья не претендует на особую научность. Цель данной статьи рассказать о проблемах, которые были поставлены перед нами и о способе их решения.
Вы даже не представляете какие абсурдные требования существуют в этой сфере и насколько все отстает от переднего края технологий.
Прошу прощения за ссылки на википедию, просто последние ваши комментарии походили на некий троллинг.
У нас в группе есть так называемая «общая почта» группы, на которую приходят сообщения от учебной части (так было удобнее), так вот на этой почте 10 устройств, и можно позванивать любое, а так же определить их местоположения, устанавливать и удалять приложения.
Жанр: Simulation
Разработчик: NovaLogic
Издатель: NovaLogic
Год выхода: 1997
Платформа: Windows
С авторами ТЗ такого уровня спорить не особо получиться. И тем более эти ТЗ уже приняты, согласованы, подписаны.
Вообщем спасибо за комментарии. Очень интересно послушать мнение других людей по поводу ГИС.
Я постараюсь расширить применяемые методы в будущих проектах. Я же и сам не в восторге от всего этого.
Помимо визуальных задач, если еще расчетные и задачи по выдачи потребителям.
И все это, по сути, работает на одном процессоре.
Требования же к скорости формирования изображения не менее 25фпс.
Пересчет всех точек. Чтобы произвести пересчет точек вида масштаб+поворот достаточно просто умножить их на матрицу преобразования. Средствами OpenGL это делается аппаратно, но не всегда у нас есть вообще что-то кроме fb.
Для того чтобы преобразовать координаты из СК-42 необходимо использовать монстроуозные формулы из ГОСТ Р51794-2008. А если брать пересчет МГС-84 в ГК, то нужен промежуточный пересчет в СК-42.
Затраты на формирования параметров GKZone много меньше, чем просто затраты на формирование изображения.
Выбирать фрагменты и известными индексами гораздо быстрее, чем выбирать объекты из непрерывной карты. То есть мы сразу знаем какие фрагменты и откуда необходимо прочитать исходя из матриц в GKZone. При движении карты не приходиться формировать листы и текстуры для уже подгруженных фрагментов. Работать с фрагментами проще и понятнее чем с непрерывным массивом («окном» ) объектов. Я бы мог написать статью как раз про подход к формированию карт и к ее визуализации.
Вы не сможете читать с диска все объекты из одного места. Фрагмент же читается целиком.
Я, конечно, могу ошибаться и ваш подход быстрее.
Если у вас есть опыт работы с встраиваемыми ГИС, то не могли бы вы поделиться ссылками на какую-нибудь литературу по этому поводу, описание форматов, алгоритмов, опенсорс проекты и т.п.
То есть карта на экране должна быть похожа на карту на бумаге.
Нет, карта полностью векторная со всей семантикой из sxf. А то что формат ужасен — я согласен.
Понятное дело, что на PC или на том же смартфоне(sic!) можно реализовать более сложные алгоритмы.
Проблема состоит в том, что необходимо отображать карту именно в проекции ГК для масштабов (1:100k — 1:1M) и в проекции Меркатора(1:5M). Это требование прописано в ТЗ. У нас, конечно не один проект, но требования к проекциям и масштабам везде примерно одинаковое.
Уточню — карта полностью векторная и хранить ее необходимо именно в векторном формате. Если хранить карту в геоцентрической WGS84 потребуется произвести пересчет на борту всех точек всех объектов после выборки этого куска из базы, проще хранить уже в целевой проекции. Объектов очень много. Тут опять же производительность.
То есть наилучшее решение которое у нас получилось — хранить карту, разбитую на фрагменты в необходимой проекции.
Подытожу: Мешает явное указание проекций в Т.З. и низкая производительность.
Вы спрашивали про задачу, в которой я применял метод, описанной в статье. Я ответил. И ответил почему мне приходится его применять.
Надеюсь, ваши вопросы исчерпаны?
Мне просто уже больше нечего добавить.
В данной задаче мы не можем использовать проекцию, отличную от ГК, на других масштабах.
На крупном масштабе у нас и не возникало подобных проблем.
В качестве исходных данных как раз и используются топографические карты мелкого масштаба. Поскольку данные карты содержат множество необходимой семантической информации. Для обзорных карт (1:5М) используется проекция Меркатора.
Я не понимаю в чем вы меня пытаетесь убедить?
Вы меня спросили про применение описанного метода, я вам ответил. Вы же обвиняете меня в некомпетентности. Я не претендую на звание эксперта в гис, но по работе в этой теме мне приходится общаться и с летчиками и с картографами и с ГИС-специалистами.
Повторюсь еще раз. Для данной задачи выбрано использование именно этих проекций, и выбрано не дилетантами, а как раз специалистами. Про абсурдные требования — я имел ввиду не требования к проекциями и т.д, а требования с самой системе, при том что аппаратное обеспечение оставляет желать лучшего, но это не тема данной дискуссии.
И на счет взятия себя в руки. Это не баттхерт, а просто желание понять, что же вы хотите сказать вашими комментариями? Я действительно хочу услышать компетентное мнение, но я пока слышу лишь обвинение в некомпетентности. Если вы так считаете, то зачем тратите время на ответы?
Экспертные системы в медицине — вот куда надо направлять его. Лучше эта система спасет жизни людей, чем сделает мой бутерброд еще вкуснее.
Не задачи абсурдные, а требования к ним.
У нас получился не особо полезный диалог. Учту, что хабр не любит статей про не популярные проекции :)
Здесь есть четкие требования, которые принимаются не нами. Применение подобных карт как стандарт де факто.
Другие существующие решения очень примитивны и сводятся к увеличению избыточности данных и сшиванию по одному осевому меридиану дополнительных листов карт, при этом на борту очень ограниченные вычислительные ресурсы и ресурсы памяти. Поэтому данный метод в этой сфере очень полезен.
Статья не претендует на особую научность. Цель данной статьи рассказать о проблемах, которые были поставлены перед нами и о способе их решения.
Вы даже не представляете какие абсурдные требования существуют в этой сфере и насколько все отстает от переднего края технологий.
Прошу прощения за ссылки на википедию, просто последние ваши комментарии походили на некий троллинг.