|
Notes |
|
|
(0012321)
|
|
Garl
|
|
09-08-2013 12:35
|
|
есть вариант получения GPS данных от GPS трекеров, они шлют своё местоположение на IP:Порт
было бы очень интересно и практично иметь вариант отображение этих данных прямо в Планете :) |
|
|
|
|
|
Это к отображению своего положения почти не имеет никакого отношения. Для этого лучше всего делать отдельный слой для отображения других объектов и слой этот не будет никак завязан на существующую подсистему GPS. |
|
|
|
|
>было бы очень интересно и практично
Вообще-то хоть сейчас можно сделать, чтобы метки по экрану ездили. Даже если оставаться только в рамках оригинального репо, достаточно слушать порт и кидать в сас сообщения типа WM_COPYDATA. Ввиду тривиальности и нужности 0.1% людей лично я даже не вижу смысла это в сас пихать. Что-то мне подсказывает, что Виктор примерно того же мнения. А в SACS же есть возможность слушать порт в скрипте и аналогично двигать метки.
>делать отдельный слой для отображения других объектов
Ну, как только метки будут неудобны, недостаточны или ещё что-нибудь прочее - всегда можно сделать аналог, хранить только в памяти,... - но пока и с двиганием меток вполне удобно выходит.
>не будет никак завязан на существующую подсистему GPS
Несомненно.
>Это должно быть два отдельных поставщика данных
Не совсем так. По сути это разделение данных и их качества.
Пока что все источники данных о местоположении передают как данные, так и их качество. Даже у locationsensor это просто соседняя проца у интерфейса. В NMEA и у Garmin это просто в одном сообщении прилетает. То есть поставщик один *).
А вот что реально имеет смысл разделить - так это обработку изменения данных (PVT) и обработку изменения их качества (xDOP+sats). Робкая попытка сделать это имеется в абстрактном классе, там нотификация сделана по отдельности, но потом оно собирается в объект целиком, и портит всю малину (((
зы. PVT = position-velocity-time = данные.
-------------
*) рассуждать о реальности подключения нескольких приёмников, и чтобы с одного брать PVT, а с другого рисовать спутники и оценивать HDOP, я не берусь )))) |
|
|
|
|
>А вот что реально имеет смысл разделить - так это обработку изменения данных (PVT) и обработку изменения их качества (xDOP+sats). Робкая попытка сделать это имеется в абстрактном классе, там нотификация сделана по отдельности, но потом оно собирается в объект целиком, и портит всю малину (((
Ну я в основном это и подразумеваю, но еще думаю о такой особенности - у нас есть рисунок спутникового созвездия, но тот же locationsensor этого не предоставляет.
И вообще я склонен двигаться к чему-то похожему на интерфейсы ILatLongReport и тд. А информацию о положении спутников отдельным интерфейсом, которые конкретный модуль может и не поддерживать. |
|
|
|
|
Хотя должен признать, что есть сценарий, когда можно использовать данные полученные от трекера по сети:
У нас есть устройство с GPS и WiFi, которое умеет отсылать по TCP/IP данные с GPS.
И есть ноутбук с SAS.Планетой.
Поднимаем на одном из устройств виртуальную точку доступа и коннектимся вторым.
Хотим видеть свое положение на ноутбуке, где нет GPS.
|
|
|
|
|
>рисунок спутникового созвездия
Это да, это необязательные вкусняшки. Собственно с ними тоже всё просто: нет данных для созвездия - не рисуем его )))
Сейчас прилетают разные данные, в зависимости от того, nmea или garmin используется, и момент обновления данных разный, для garmin например практически всё в одной команде, а для nmea раскидано и даже дублируется. Для location sensor будет видимо другой канал, откуда будут прилетать данные другого типа (возможно, сразу интерфейсики), и соответственно данные будут прилетать только доступные. Так что в контексте нотификаций об изменениях - событие изменения созвездия просто никогда не наступит ))). |
|
|
|
|
>Хотим видеть свое положение на ноутбуке, где нет GPS
Значит, мы хотим видеть НЕ СВОЁ положение, а положение чего-то другого (возможно, соседней точки доступа). И вообще говоря, таких гпс-вафлЕй может быть больше одной, и в этом и есть принципиальное отличие от того, что положение собственно саса определяется по подключенному _к_сасу_ приёмнику, и приёмнику _одному_, ибо положение-то одно. |
|
|
|
|
|
Нет. Именно свое. Мы с трекером в одной машине, например, едем и разница в пол метра для нас не существенно. Я сам так использую, только для проброски NMEA пользуюсь GPSGate на обоих девайсах. Так что это именно случай отображения моего положения. |
|
|
|
|
>разница в пол метра для нас не существенно
Я совсем о другом. О том, что нельзя путать 1 и 2.
1. Своё положение сас показывает по подсистеме позиционирования (gps). Делает это на основании маркера положения (стрелочка). Своё положение только одно. За ним можно следить и перемещать карту (например, привязка к центру экрана).
2. Чужое положение сас не показывает по подсистеме позиционирования. Для этого неверно использовать маркер положения, так как это задача слежения за сторонними объектами (коих много, а маркер один и положение саса одно). Даже если в качестве стороннего объекта выступают raw-данные с трекера.
Разница определяется целью, а не форматом данных и не расстоянием от нас до точки геопозиционирования. И даже парсер может быть один на оба варианта. Но цели - разные.
Также разница определяется алгоритмом взаимодействия. Если сас подключается к endpoint - обязанность выдавать согласованные данные возлагается на endpoint. И даже если подключить к компу 100500+ обычных приёмников nmea и garmin, остальные никак не нагадят данным, которые летят с одного, выбранного для работы. Если же сас поднимает публичный endpoint и ловит всё что туда прилетает, обязанность обеспечения корректности данных необходимо возлагать на сас. Любой залетевший пакет, даже возможно правильный от второго трекера, неизвестно откуда взявшегося, приведёт к малопредсказуемым последствиям в подсистеме gps, как минимум это цирковые представления маркера положения, а в случае трансляции nmea это могут быть и разорванные пакеты. |
|