The gps-osmand-tracker is a Java Software to simulate a standard hardware device that collects GPS locations, optionally buffer and send them to a server asap. Reporting should be configurable for time- and distance intervals, change of direction etc.

Tracker Components

Note

Note that we are citing original texts from GPS Tracking with Java EE Components

What exactly is a tracking device and what is its core functionality?
A tracker hardware is basically a combination of a GPS (processing) unit and a (GSM) communication unit. The GPS receives the location via satellite and the communication unit sends tracking messages to a server.

In the end every tracker should be able to send Coordinates, preferably WGS84 latitude and longitude and universal time, which the Server can use to localize the device.
— GPS Tracking with Java EE Components
Chapter 8.1

The main components are the GPS receiver and GSM transmitter chips for receiving and sending locations. Since both chips have to deal with a lot of information and technical challenges they are synchronized on a Controller Board. A Message Buffer serves as a local database to keep the best location results and wait for a good connection to transmit them to the Tracking System.

The fourth component, the Energy Source is vital for the hardware Tracker. And similar to a mobile phone the battery is the most space consuming component, but luckily is not needed for the software simulation.

JeeTS Tracker
A tracking hardware combines a GPS- and GSM unit on a Controller Board. The Controller evaluates sensor data to create event messages in the protocol format. NMEA data is constantly validated to provide the best position available. The messages can be sent whenever appropriate.
— GPS Tracking with Java EE Components
Figure 8.1

GPS receiver

A GPS chip (with antenna) acquires signals from orbiting satellites to calculate the location on Earth - a highly mathematical, trigonomic number cruncher. The location is continuously calculated by trilateration from (the best available) three satelites. Note that a fourth satelite is required to provide the precise time.

It is useful to understand that a GPS unit is primarily concerned to deliver latitude, longitude and time. The altitude is more of a side effect and not as reliable due to geometric reasons.

This implies that the GPS unit primarily provides point information. speed and bearing can be provided, but most Tracking Systems calculate them from the previous to the current positon.

GSM transmitter

The GSM or any other network technology is basically the entry point of GPS data to the internet. It can send the locations over the connected network (if available) and can communicate via TCP and UDP low level protocols and higher protocols, like http/s, on top. This unit is also working all the time to get a good connection over the air and transmitting whenever possible.

Message Buffer

As both GPS- and GSM units are busy all the time the Message Buffer can collect all valid and accurate locations from the GPS, while independantly pushing them to the server.

Communication Protocol

It is important to realize that a Tracking Device is not an application client and the data transmission has nothing to do with the REST API. It is simply some thing (Internet of Things, IoT) that sends information, very often via proprietary protocols. A protocol is subdivided into sentences to report different concerns. The most primitive GPS Protocol is NMEA 0183 which actually describes the primitives of GPS acquisition, like the satelite constellation. The protocol is described in more detail in The ROAF, Part II - Chapter 4.5 NAVSTAR GPS, 4.5.1 NMEA 0183

From the Tracker perspective the server is not the Traccar Platform, but simply a port to a Device Communication Server (DCS) which does the ETL work. The DCS is implemented with Netty Pipelines and the Decoder does the actual parsing targeting Traccar.

OsmAnd Protocol

Message Sentences combine a number of values that belong together. A complete protocol defines the available attributes for an entire system - or scenario. We chose the OsmAnd protocol because it is very simple and it is implemented on the Traccar Server (for the Traccar Client App). Or more general the Traccar Server offers a DCS for this protocol on a configurable port (default 5055). Technically "The OsmAnd protocol processes HTTP requests with either query parameters or POST parameters." — and the protocol allows to add attributes!

You can find the format (or protocol spec) here and here.

Geo Coordinates

For Global Positioning will use the GeoTools library as our interface to process GPS Positions, for dealing with Digital Maps and Geographic Information Systems - GIS. This way the Software is compatible to almost any geoengineering tool and to components like an embedded h2GIS server. usefull!

Yet, in geographic processing the most important performance aspect is mathematical.
Imagine you need to compare thousands of distances to operate in a scenario.
To calculate the exact distance on the globe we have to use a projection system. We will look at the performances differences by comparing the formulas for a geographical versus a cartesian distance below.

The GeoTools library is tightly coupled with the Java Topology Suite (JTS) library. The Coordinate is a core class from the GeoTools / JTS library, which is the standard geometry model GeoTools is built on. Note that the Java Topology Suite is actually not working with geocoordinates and optimized for trigonometric performance.

It is distinct from Point, which is a subclass of Geometry. Unlike objects of type Point (which contain additional information such as an envelope, a precision model, and spatial reference system information), a Coordinate only contains ordinate values and accessor methods.
— JTS Coordinate javadoc

Since the cartesian method is much faster we want to be able to ignore projection systems.
Therefore we are using the Coordinate to store the latitude, longitude and altitude with double precision.
It has many useful features like the usage 2d or 3d coordinate:

// 2D Koordinate (JTS)
Coordinate coord2D = new Coordinate(10.0, 20.0);
Coordinate coord3D = new Coordinate(10.0, 20.0, 500.0); // x, y, z

The GeneralDirectPosition is constructed the same way

// GeoTools Position (3D)
GeneralDirectPosition pos3D = new GeneralDirectPosition(10.0, 20.0, 500.0);

but belongs to the more complex GeoTools Referencing-Framework and carries metadata of coordinate systems etc.

We can always transform the JTS coordinates to geocoordinates (at a cost). With the GeoTools library you can tune the PrecisionModel and the built-in GeodeticCalculator does not require geodetic expertise.

At this point it doesn’t seam like a big deal, because we simply storing three double values in one Coordinate.
Let’s have a look at the formulas to get a sense when to use which.

Haversine Distance

The geographically calculation has to consider the globe’s radius, the curvature etc.
The Haversine Formula determines the great-circle distance between two points on a sphere:

\[a = \sin^2\left(\frac{\Delta\phi}{2}\right) + \cos(\phi_1) \cdot \cos(\phi_2) \cdot \sin^2\left(\frac{\Delta\lambda}{2}\right)\]
\[c = 2 \cdot \operatorname{atan2}\left(\sqrt{a}, \sqrt{1-a}\right)\]
\[d = R \cdot c\]
  • d is the distance between the two points.

  • \(\phi\) is latitude, \(\lambda\) is longitude.

  • \(\Delta\phi = \phi_2 - \phi_1\)

  • \(\Delta\lambda = \lambda_2 - \lambda_1\)

  • \(R\) is the radius of the sphere (Earth’s mean radius is approx. 6,371 km).

Tip

Most programming languages provide trigonometric functions that require input in radians.
To convert degrees to radians, use the formula: radians = degrees * pi /180.

When comparing distances their precise value does not matter, only relativity counts.
To calculate a distance in a cartesian plane we can also apply Pythagoras:

Pythagorean Distance

The Pythagorean Theorem is a fundamental principle in Euclidean geometry relating the three sides of a right triangle. The theorem states that in a right-angled triangle, the area of the square whose side is the hypotenuse (the side opposite the right angle) is equal to the sum of the areas of the squares on the other two sides.

\[a^2 + b^2 = c^2\]

Or simply speaking a and b are the orthogonal deltas of lat and lon and c is the distance, i.e. length of the hypotenuse. Calculating a comparable distance c is as simple as

\[distance = \sqrt{\Delta lat^2 + \Delta lon^2}\]

By simply comparing this with the Haversine Formula you can sense the differences in performance. While the distance is simply calculating a length the real number crunching takes place when overlapping Geofences come into play. Note that geofence has many edges and each one has to be taken into account, yet should not slow down the real time scenario.

The bm Geodesy Standard

We don’t want to be distracted by reference systems.

The most conservative way to deal with the definition of a CoordinateReferenceSystem is not to.
Instead make use of an authority that provides complete definitions defined by a simple code.
— docs.geotools.org/latest/userguide/library/referencing/crs.html

Throughout this bm repository we will use identical geodetic formulas.
Then the distances from location 1 to location 2
and from location 2 to location 1 are guaranteed to be identical.
This is very important for synchronicity.

Check out the JTS feature list to get an idea of geometric operations.

Distance Example

With the GeoTools GeodeticCalculator we calculate the geodesic distance in meters between two (lat,lon) GPS points in the standard WGS84 (EPSG:4326) system:

  CoordinateReferenceSystem wgs84 = CRS.decode("EPSG:4326");     // (1)

  GeodeticCalculator calculator = new GeodeticCalculator(wgs84); // (2)

  calculator.setStartingGeographicPoint   (lon1, lat1);          // (3)
  calculator.setDestinationGeographicPoint(lon2, lat2);

  return calculator.getOrthodromicDistance();                    // (4)
  1. Define the Coordinate Reference System

  2. Initialize the Geodetic Calculator

  3. Set start- and end coordinates

  4. Get the orthodromic distance (distance along the ellipsoid surface)