GPS monitoring - analysis of message attributes
In this post, the Hamlet question “To be or not to be” is put to the attribute in the message history. It describes the approach taken in the GPS monitoring system ViaLatM , and argues in favor of these decisions.
The set of attributes sent by trackers is quite wide. It varies from 2-3 basic ones for personal trackers and beacons, to dozens (including information from connected sensors and CAN buses), coming from telematics devices installed on vehicles.
Here we will discuss some of the basic attributes that are sent by most types of devices: speed, direction of motion, validity of coordinates, DOP factors and the number of satellites.
')
Less than a year ago, we posted on our website two small articles on the speed and attributes of geolocation, in which we briefly touched upon the issues raised in this post.
By reducing the number of attributes stored in the history of messages, we optimize the amount of disk space and increase the speed of generating reports (traffic, parking, visiting geozones, ...) and displaying tracks at certain time intervals.
In this case, for the last message received from the device, all message attributes are stored and available for display and processing.
The graphics are quite similar. For the user, the average speed gives much more useful information. If the tracker's transmission interval of messages when moving is long enough (for example, 10 minutes), then the instantaneous speed may not display the real picture. Assume that the instantaneous speed at the entrance and exit of the “traffic jam” is 60 km / h, and the distance between two points is 1 km. Then the average speed for the moment of departure from the traffic jam will be 6 km / h and this is more appropriate for the actual situation.
Statistical studies have shown that the smaller the time interval between messages on moving objects, the smaller the deviations between the average and instantaneous speed. In most trackers, when moving, messages are transmitted more often than in parking states.
In this case, the control and the formation of notifications of violation of the speed limit is based on the instantaneous speed. In these cases, the instantaneous speed is stored in the violation notification settings.
Purple broken line is a device trace (device track in the last 10 minutes, but not more than 20 points). In the current version, we maintain the accuracy of determining the coordinates for all events. But maybe it does not need to do for moving.
Regarding the instantaneous speed, as noted above, it is close to the calculated average speed, which, in our opinion, is more informative. There is a problem here. If the device did not set the maximum permissible speed (accordingly, no alert notifications about the speed limit violation were generated), then generating a report on speeding takes more time than if the instantaneous speed was maintained. Statistics of user access to reports showed that this report is requested to an order of magnitude less often than reports on traffic, parking, visiting geozones and alarm events. The choice was made in favor of accelerating the formation of more frequently requested reports.
In the ViaLatM system, the device can be transferred to a test mode in which all message attributes are saved. This mode is used at the stage of connecting new types of devices or testing devices, the correct operation of which is in doubt. Messages of this kind are not stored in the standard archive of events, but in a separate archive (it is possible to export events from this archive to the standard one).
In the ViaLatM system we adhere to the principles:
Each of the principles should be approached carefully.
If some attribute (from potentially calculated) is often used in reports and its calculation requires significant resources, then you should think about its permanent storage.
The question of what information is useful for the user is unlikely to have an unambiguous definite answer. When the GSM signal level attribute was constantly stored and displayed in reports in our system, we polled 10 users. All amicably answered that the attribute is needed (let it be, it does not interfere). When we removed this attribute from persistent storage and display in reports, only one of the surveyed users noticed its disappearance. But the question of how he uses it, he did not give a clear answer, and it was not difficult for us to convince him that he did not need him. This is a question of psychology. People will not refuse additional functions because they do not want to waste time thinking about how much they really need them (“Maybe it’s useful” and you have nothing to break your head). But one of the most important tasks of developers is to remove all unnecessary.
We will be grateful to habravchanam for expressing ideas and criticizing our approaches.
The set of attributes sent by trackers is quite wide. It varies from 2-3 basic ones for personal trackers and beacons, to dozens (including information from connected sensors and CAN buses), coming from telematics devices installed on vehicles.
Here we will discuss some of the basic attributes that are sent by most types of devices: speed, direction of motion, validity of coordinates, DOP factors and the number of satellites.
')
Less than a year ago, we posted on our website two small articles on the speed and attributes of geolocation, in which we briefly touched upon the issues raised in this post.
By reducing the number of attributes stored in the history of messages, we optimize the amount of disk space and increase the speed of generating reports (traffic, parking, visiting geozones, ...) and displaying tracks at certain time intervals.
In this case, for the last message received from the device, all message attributes are stored and available for display and processing.
Speed
Trackers convey the instantaneous speed of an object. This speed is calculated on the basis of determining the coordinates by satellite and therefore has an error. In ViaLatM, we do not maintain instantaneous speed in message history. It is displayed for the last event, and in reports the average speed is used instead, which can be calculated based on the distance and time interval between two adjacent points. Below on the graph the red line corresponds to the instantaneous speed, the blue - to the average speed. The graphics are quite similar. For the user, the average speed gives much more useful information. If the tracker's transmission interval of messages when moving is long enough (for example, 10 minutes), then the instantaneous speed may not display the real picture. Assume that the instantaneous speed at the entrance and exit of the “traffic jam” is 60 km / h, and the distance between two points is 1 km. Then the average speed for the moment of departure from the traffic jam will be 6 km / h and this is more appropriate for the actual situation.Statistical studies have shown that the smaller the time interval between messages on moving objects, the smaller the deviations between the average and instantaneous speed. In most trackers, when moving, messages are transmitted more often than in parking states.
In this case, the control and the formation of notifications of violation of the speed limit is based on the instantaneous speed. In these cases, the instantaneous speed is stored in the violation notification settings.
Direction of travel
When working with a message archive, we did not find the use of this attribute. Yes, and when observing an object in real time, perhaps the only possible benefit from it is when the message came at a fork in two roads, and the user can understand which way the object will continue to move.Sign of location validity
Most device types return a sign of correct location. The attribute is processed, but not stored. The presence of coordinates in the saved message is a fact of their validity. If a message arrived with a sign of incorrect determination of coordinates, and the coordinates themselves are present, then they are deleted before saving the message in the archive.Number of satellites
The number of satellites for which the location is determined also carries little information. Sometimes with the visibility of 3 satellites, the location can be determined more accurately than with 10, if the latter are located on the line. Coordinates in ViaLatM are not saved if the number of satellites is less than 3.DOP attributes
DOP attributes (HDOP, VDOP, PDOP and TDOP) are factors that impair accuracy, which are transmitted in messages by some types of devices. For ordinary users, it is more obvious to calculate and display the accuracy of determining coordinates on the basis of their values. The green circle in the figure shows the accuracy of the coordinates for the last event. Purple broken line is a device trace (device track in the last 10 minutes, but not more than 20 points). In the current version, we maintain the accuracy of determining the coordinates for all events. But maybe it does not need to do for moving.GSM signal strength
Another attribute with which it is not clear what to do to the ordinary user. According to its meaning, it is possible to make a conclusion about how well a cellular communication works in one place or another. For monitoring this concerns the issue of data transmission over GPRS. But what conclusions can be made on the basis of the attribute value is not clear to us."What we do not store, calculating crying"
Parameters that are not saved cannot be restored (direction of movement, validity of determination of coordinates, number of satellites and GSM signal level), but so far we have not encountered a case when a working tracker would need to get at least one of these parameters.Regarding the instantaneous speed, as noted above, it is close to the calculated average speed, which, in our opinion, is more informative. There is a problem here. If the device did not set the maximum permissible speed (accordingly, no alert notifications about the speed limit violation were generated), then generating a report on speeding takes more time than if the instantaneous speed was maintained. Statistics of user access to reports showed that this report is requested to an order of magnitude less often than reports on traffic, parking, visiting geozones and alarm events. The choice was made in favor of accelerating the formation of more frequently requested reports.
In the ViaLatM system, the device can be transferred to a test mode in which all message attributes are saved. This mode is used at the stage of connecting new types of devices or testing devices, the correct operation of which is in doubt. Messages of this kind are not stored in the standard archive of events, but in a separate archive (it is possible to export events from this archive to the standard one).
Conclusion
In the ViaLatM system we adhere to the principles:
- Save only what is used and cannot be calculated
- Display only what is useful information for the user.
Each of the principles should be approached carefully.
If some attribute (from potentially calculated) is often used in reports and its calculation requires significant resources, then you should think about its permanent storage.
The question of what information is useful for the user is unlikely to have an unambiguous definite answer. When the GSM signal level attribute was constantly stored and displayed in reports in our system, we polled 10 users. All amicably answered that the attribute is needed (let it be, it does not interfere). When we removed this attribute from persistent storage and display in reports, only one of the surveyed users noticed its disappearance. But the question of how he uses it, he did not give a clear answer, and it was not difficult for us to convince him that he did not need him. This is a question of psychology. People will not refuse additional functions because they do not want to waste time thinking about how much they really need them (“Maybe it’s useful” and you have nothing to break your head). But one of the most important tasks of developers is to remove all unnecessary.
We will be grateful to habravchanam for expressing ideas and criticizing our approaches.
Source: https://habr.com/ru/post/239051/
All Articles