SASGIS - SAS.Планета
View Issue Details
0002081SAS.ПланетаРефакторингpublic09-08-2013 12:1530-12-2015 12:51
vdemidov 
 
normalminorhave not tried
confirmedopen 
121010 
24xxxx 
0002081: Разделить информацию о положении от информации о спутниках
Добавить property Satellites: IGPSSatellitesInView в интерфейс IGPSPosition было не самой лучшей идеей навеянной ZylGPS. Это должно быть два отдельных поставщика данных, которые могут обновляться независимо.
gps
Issue History
09-08-2013 12:15vdemidovNew Issue
09-08-2013 12:15vdemidovStatusnew => confirmed
09-08-2013 12:35GarlNote Added: 0012321
09-08-2013 12:48vdemidovNote Added: 0012323
09-08-2013 13:29vasketsovNote Added: 0012325
09-08-2013 13:47vdemidovNote Added: 0012326
09-08-2013 14:14vdemidovNote Added: 0012327
09-08-2013 14:14vdemidovNote Edited: 0012327bug_revision_view_page.php?bugnote_id=12327#r5595
09-08-2013 14:17vasketsovNote Added: 0012328
09-08-2013 14:30vasketsovNote Added: 0012329
09-08-2013 14:47vdemidovNote Added: 0012330
09-08-2013 16:01vasketsovNote Added: 0012333
30-12-2015 12:51vdemidovTag Attached: gps

Notes
(0012321)
Garl   
09-08-2013 12:35   
есть вариант получения GPS данных от GPS трекеров, они шлют своё местоположение на IP:Порт
было бы очень интересно и практично иметь вариант отображение этих данных прямо в Планете :)
(0012323)
vdemidov   
09-08-2013 12:48   
Это к отображению своего положения почти не имеет никакого отношения. Для этого лучше всего делать отдельный слой для отображения других объектов и слой этот не будет никак завязан на существующую подсистему GPS.
(0012325)
vasketsov   
09-08-2013 13:29   
>было бы очень интересно и практично
Вообще-то хоть сейчас можно сделать, чтобы метки по экрану ездили. Даже если оставаться только в рамках оригинального репо, достаточно слушать порт и кидать в сас сообщения типа WM_COPYDATA. Ввиду тривиальности и нужности 0.1% людей лично я даже не вижу смысла это в сас пихать. Что-то мне подсказывает, что Виктор примерно того же мнения. А в SACS же есть возможность слушать порт в скрипте и аналогично двигать метки.

>делать отдельный слой для отображения других объектов
Ну, как только метки будут неудобны, недостаточны или ещё что-нибудь прочее - всегда можно сделать аналог, хранить только в памяти,... - но пока и с двиганием меток вполне удобно выходит.

>не будет никак завязан на существующую подсистему GPS
Несомненно.

>Это должно быть два отдельных поставщика данных
Не совсем так. По сути это разделение данных и их качества.
Пока что все источники данных о местоположении передают как данные, так и их качество. Даже у locationsensor это просто соседняя проца у интерфейса. В NMEA и у Garmin это просто в одном сообщении прилетает. То есть поставщик один *).
А вот что реально имеет смысл разделить - так это обработку изменения данных (PVT) и обработку изменения их качества (xDOP+sats). Робкая попытка сделать это имеется в абстрактном классе, там нотификация сделана по отдельности, но потом оно собирается в объект целиком, и портит всю малину (((

зы. PVT = position-velocity-time = данные.
-------------
*) рассуждать о реальности подключения нескольких приёмников, и чтобы с одного брать PVT, а с другого рисовать спутники и оценивать HDOP, я не берусь ))))
(0012326)
vdemidov   
09-08-2013 13:47   
>А вот что реально имеет смысл разделить - так это обработку изменения данных (PVT) и обработку изменения их качества (xDOP+sats). Робкая попытка сделать это имеется в абстрактном классе, там нотификация сделана по отдельности, но потом оно собирается в объект целиком, и портит всю малину (((
Ну я в основном это и подразумеваю, но еще думаю о такой особенности - у нас есть рисунок спутникового созвездия, но тот же locationsensor этого не предоставляет.
И вообще я склонен двигаться к чему-то похожему на интерфейсы ILatLongReport и тд. А информацию о положении спутников отдельным интерфейсом, которые конкретный модуль может и не поддерживать.
(0012327)
vdemidov   
09-08-2013 14:14   
Хотя должен признать, что есть сценарий, когда можно использовать данные полученные от трекера по сети:
У нас есть устройство с GPS и WiFi, которое умеет отсылать по TCP/IP данные с GPS.
И есть ноутбук с SAS.Планетой.
Поднимаем на одном из устройств виртуальную точку доступа и коннектимся вторым.
Хотим видеть свое положение на ноутбуке, где нет GPS.

(0012328)
vasketsov   
09-08-2013 14:17   
>рисунок спутникового созвездия
Это да, это необязательные вкусняшки. Собственно с ними тоже всё просто: нет данных для созвездия - не рисуем его )))

Сейчас прилетают разные данные, в зависимости от того, nmea или garmin используется, и момент обновления данных разный, для garmin например практически всё в одной команде, а для nmea раскидано и даже дублируется. Для location sensor будет видимо другой канал, откуда будут прилетать данные другого типа (возможно, сразу интерфейсики), и соответственно данные будут прилетать только доступные. Так что в контексте нотификаций об изменениях - событие изменения созвездия просто никогда не наступит ))).
(0012329)
vasketsov   
09-08-2013 14:30   
>Хотим видеть свое положение на ноутбуке, где нет GPS
Значит, мы хотим видеть НЕ СВОЁ положение, а положение чего-то другого (возможно, соседней точки доступа). И вообще говоря, таких гпс-вафлЕй может быть больше одной, и в этом и есть принципиальное отличие от того, что положение собственно саса определяется по подключенному _к_сасу_ приёмнику, и приёмнику _одному_, ибо положение-то одно.
(0012330)
vdemidov   
09-08-2013 14:47   
Нет. Именно свое. Мы с трекером в одной машине, например, едем и разница в пол метра для нас не существенно. Я сам так использую, только для проброски NMEA пользуюсь GPSGate на обоих девайсах. Так что это именно случай отображения моего положения.
(0012333)
vasketsov   
09-08-2013 16:01   
>разница в пол метра для нас не существенно
Я совсем о другом. О том, что нельзя путать 1 и 2.

1. Своё положение сас показывает по подсистеме позиционирования (gps). Делает это на основании маркера положения (стрелочка). Своё положение только одно. За ним можно следить и перемещать карту (например, привязка к центру экрана).

2. Чужое положение сас не показывает по подсистеме позиционирования. Для этого неверно использовать маркер положения, так как это задача слежения за сторонними объектами (коих много, а маркер один и положение саса одно). Даже если в качестве стороннего объекта выступают raw-данные с трекера.

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

Также разница определяется алгоритмом взаимодействия. Если сас подключается к endpoint - обязанность выдавать согласованные данные возлагается на endpoint. И даже если подключить к компу 100500+ обычных приёмников nmea и garmin, остальные никак не нагадят данным, которые летят с одного, выбранного для работы. Если же сас поднимает публичный endpoint и ловит всё что туда прилетает, обязанность обеспечения корректности данных необходимо возлагать на сас. Любой залетевший пакет, даже возможно правильный от второго трекера, неизвестно откуда взявшегося, приведёт к малопредсказуемым последствиям в подсистеме gps, как минимум это цирковые представления маркера положения, а в случае трансляции nmea это могут быть и разорванные пакеты.