AIS data sources
Spire satellites spend most of their time over open ocean listening for AIS messages. These messages are published shortly after our satellites pass over a Spire ground station to download them. Given this, satellite-received AIS (S-AIS) messages are often published in “bursts”. The primary advantage of S-AIS is global coverage.
Terrestrial AIS message (T-AIS) collection generally occurs near coastlines and takes place after a ship transmits them. Given that, terrestrially-received AIS messages are immediately made available to you. The primary advantage of T-AIS is extremely low latency.
Dynamic AIS™ addresses the growing problem of gaps in AIS data, which directly impact ship safety, trading, revenue, and insurance claims. It delivers more unique MMSIs (up to ten thousand per day) with near-real-time latency, and up to six million additional AIS messages per day.
D-AIS™ leverages thousands of satellite-enabled AIS receivers traveling throughout the busiest shipping lanes in the world, and provides an unprecedented frequency of position updates in areas that are out of the reach of terrestrial collection and overwhelm other satellite AIS providers, particularly in High Traffic Zones such as the South China Sea.
These 2860+ satellite-enabled AIS receivers track vessels and the traffic within 60 nautical miles, sending this data to communication satellites at least every 15 minutes. Approximately 15 receivers a month are added to the network.
View a Dynamic AIS™ demo
Without Dynamic data to improve position update frequency in high traffic zones, the risk of acting on stale or inaccurate data is ever present. Watch the demo to understand the positive impact of D-AIS™:
AIS message downsampling
Due to the sheer number of Terrestrial AIS (T-AIS) messages Spire receives, we do not by default provide all of Terrestrial AIS messages within the Messages API or TCP Stream. T-AIS messages are downsampled within 5-minute periods based on MMSI and message type. For example, if we receive 2 position messages with a particular MMSI 3 minutes apart from terrestrial sources, only the first of the two position messages would get published. If these messages were 7 minutes apart, both would get published.
Note: There is an option for clients to receive full (non-downsampled) Terrestrial AIS data.
As an example of data volumes 2021-06-22. A client receiving Spire Satellite AIS and downsampled Terrestrial AIS would receive up to about 80 million AIS messages per day. If they were to receive full (non-downsampled) Terrestrial AIS then the number would jump to over 300 million AIS messages per day.
Neither Satellite AIS nor Dynamic AIS™ messages are downsampled.
Virtual Downsampling through Maritime 2.0 and legacy Vessels API
If a client wishes to receives updates at a different frequency, perhaps every 10 or 15 minutes, hourly or even daily, then this can be achieved using the
vessels root query of Maritime 2.0, or the legacy Vessels API, and calling it at the required frequency for updates, i.e. calling the API hourly will give you the latest updates at an hourly interval. This is virtual downsampling controlled by the client.
AIS messages download priority
Combined Satellite & Terrestrial Feeds
Given that Terrestrial AIS is published immediately and there’s often some delay between the collection and download of a Satellite AIS message, it will often be the case that AIS messages are published within our services out of timestamp order. (We don’t store our AIS messages in a buffer and sort them before publishing them.) This is to give you access to our AIS messages as soon as they’re downloaded.
Satellite AIS Message Download Priority
Spire has many satellites in a variety of orbits and a number of global ground stations to collect and download AIS data. It’s not always realistic for us to get all of the AIS messages off of a satellite on the initial pass of a ground station.
In order to get the most important data down first, we prioritize the most recent message for each MMSI and get all of those down first before moving on to the older messages either during that same contact or during subsequent ones with other ground stations.
What that means in terms of how we push data to our AIS production services is that you’ll get the “freshest” data for an MMSI from each satellite quickly but then in some cases get the “backfill” a little bit later.
Different classes of AIS
AIS on board vessels can be classified as Class A and Class B.
AIS class A
AIS is included in the International Convention for the Safety of Life at Sea (SOLAS) convention for:
- vessels of 300 gross tonnage and upwards engaged on international voyages
- vessels of 500 gross tonnage and upwards not engaged on international voyages
- passenger ships irrespective of size.
The AIS referred to in the SOLAS convention is often defined as ‘AIS Class A’.
AIS class B
AIS Class B is intended for use on non-SOLAS vessels. These can include domestic commercial vessels and pleasure craft.
Static and Voyage information difference between Class A and B AIS
In regards to voyage information, AIS class A vessels reports
eta more as compared to AIS Class B vessels.
When looking at global AIS, it is commonplace that Class B vessels and small Class A vessels do not report voyage data.
24-hour count of vessels reporting destination and eta by AIS Class
|Ship Type||AIS Vessel Class|
AIS channel access methods
Class A transceivers reserve their time slots for AIS transmission via Self Organized Time Division Multiple Access (SOTDMA). They first perform a scan of the area to ascertain which slots have been taken by other vessels and reserve an empty slot. Any transmissions in the newly reserved slot will contain information notifying other nearby AIS devices that the transceiver intends to continue using this slot.
Class B transceivers are permitted to transmit via Carrier Sense Time Division Multiple Access (CSTDMA). Unlike SOTDMA, slots are not reserved. They instead simply scan for available space and transmit when a free one is determined to be available.
AIS channel access priority
Transmission priority is given to Class A transceivers which use SOTDMA since they reserve time slots. The timing of Class B transmissions via CSTDMA must work around the time slots reserved by Class A transceivers. If a Class B transceiver is unable to find an empty space, their transmissions are delayed.
AIS message latency
Latency is the amount of time it takes for a transmitted AIS message to get ingested into Spire Maritime’s systems. In other words, latency is the difference in time between the
timestamp fields in Messages API.
The average latency for AIS messages collected from a Terrestrial AIS source is significantly lower than the average latency for AIS messages collected from a satellite, since there are fewer opportunities for a satellite to download AIS messages while over open ocean. In comparison, once a terrestrial source collects an AIS message, it’s ingested immediately.
AIS Message Types
AIS position messages mostly broadcast information about a vessel’s physical location and motion.
This includes a vessel’s MMSI number, longitude, latitude, rate of turn, speed, true heading, and other parameters.
Spire offers the following position messages to customers:
- Messages 1, 2, and 3 from Class A vessels
- Message 4 from base stations
- Message 18 from Class B vessels
- Message 27 from Class A or B vessels (for long-range applications)
The Nominal Reporting Interval for Class A and B vessels traveling at most 3 knots and 2 knots respectively, or when Anchored/Moored, is a broadcast every 3 minutes.
AIS static messages mostly broadcast information about vessel characteristics that should remain (relatively) static over the during of their voyage.
This includes a vessel’s MMSI number, AIS version number, IMO number, call sign, name, type of ship/cargo, ship dimensions, destination, and other parameters.
Spire offers the following static messages to customers:
- Message 5 from Class A vessels
- Message 24 from Class B vessels
The Nominal Reporting Interval for both Class A and B vessels is a broadcast static message every 6 minutes, when an information change has been made, or upon request.
Spire offers Message 19 from Class B vessels, which contains some parameters from Messages 18, 24A, and 24B.
We also offer the following AIS messages in an encoded fashion along with their
- Message 6
- Addressed binary Message
- Message 7
- Binary acknowledge
- Message 8
- Binary broadcast Message
- Message 9
- Standard search and rescue aircraft position report
- Message 10
- Coordinated universal time and date inquiry
- Message 11
- Coordinated universal time/date response
- Message 12
- Addressed safety related Message
- Message 14
- Safety related broadcast Message
- Message 15
- Message 16
- Assigned mode command
- Message 17
- Global navigation-satellite system broadcast binary Message
- Message 20
- Data link management Message
- Message 21
- Aids-to-navigation report
AIS data cleansing methods
Often times raw AIS messages can contain errors, empty or default values, and points over land due to GPS issues or spoofing.
In our API data delivery, we do our best to clean out some of these errors. Below is a list of some of the steps that we take to clean the data:
- Check values against the AIS standard.
- Remove position data with unavailable coordinates (91 / 181).
- Filter out messages with invalid MMSI numbers. (Ships should report 9-digit MMSIs. Base stations should report 7-digit MMSIs.)
- Filter out messages with IMO numbers more than 7 digits. Note 7 digit IMO numbers still returned even when not matching the IMO checksum calculation.
- Positions reported over land. (Note. feature enabled in data from 2019-08-27)
By default, Messages API implements the above data cleaning rules. If you prefer to receive the full feed, including possible errors, simply attach a
cleansed=false parameter within your calls to the API.
We do not perform cleansing for:
- Ships reporting an unintelligible name or destination field
- Ships reporting inappropriate dimensions or speeds.
- Other data errors.
If you need a raw AIS feed which does not include data cleansing, please refer to our TCP stream v2.
Example of AIS reported positions which are excluded by Spire Maritime’s land filter:
Vessel flag codes
Vessel flag codes are derived from AIS, more specifically from the uniquely assigned 9 digit MMSI (Maritime Mobile Service Identity) number to the vessel. The first 3 digits of a vessel’s MMSI, also known as MID (Maritime Identification Digits), specify the Vessel’s flag and country.
Full list of MIDs and country codes
|MID||Country Name||Country Code|
|341||St Kitts Nevis||KN|
|361||St Pierre Miquelon||PM|
|364||Turks Caicos Is||TC|
|375||St Vincent Grenadines||VC|
|376||St Vincent Grenadines||VC|
|377||St Vincent Grenadines||VC|
|378||British Virgin Is||VG|
|379||US Virgin Is||VI|
|478||Bosnia and Herzegovina||BA|
|536||N Mariana Is||MP|
|553||Papua New Guinea||PG|
|578||Wallis Futuna Is||WF|
|607||St Paul Amsterdam Is||TF|
|612||Cen Afr Rep||CF|
|668||Sao Tome Principe||ST|
The first digit of the MID represents the assigned region, and can have a value of 2 to 7:
- (e.g., Italy has MID 247; Denmark has MIDs 219 and 220)
3North and Central America and Caribbean
- (e.g., Canada, 316; Greenland, 331; Panama, 351 through 357, plus 370 through 373; United States, 303(Alaska), 338(domestic), plus 366 through 369)
4Asia (not the southeast)
- ( Maldives, 455; Japan, 431)
5Oceania, and Southeast Asia
- (Australia, 503; New Zealand, 512; Philippines, 548; Indonesia, 525)
- (Eritrea, 625)
- (Peru, 760)
Understanding AIS performance in High-Traffic Zones
Ship activity in some global regions is significantly more dense than average. These regions are called high traffic zones (HTZs).
High traffic zones generally occur near areas with major ports, like the South China Sea or the Mediterranean Sea.
Terrestrial AIS Performance within High Traffic Zones
AIS was originally designed for ground-to-ground reception, so terrestrial stations don’t experience any significant performance degradation in HTZs within their estimated 80-kilometer radius.
Satellite AIS Performance over High Traffic Zones
As compared to terrestrial stations, our satellites are listening to ships within a 2000-kilometer radius, making them prone to AIS message collisioning – an effect that impacts all satellite AIS providers.
When a satellite passes over a HTZ, it becomes difficult for the satellite to differentiate between the higher number of AIS messages being transmitted at the same time. The end result is actually fewer than usual AIS messages being decoded.
As an analogy, this is similar to the effect of listening to one conversation, as compared to 20 simultaneous conversations. Understanding a single conversation is significantly easier than attempting to follow 20.
Spire has and continues to develop methods of reducing the impact of AIS message collisioning on its satellites.
Rate of turn (rot)
Class A vessels periodically report the rate at which they are rotating (if at all) within AIS Messages 1, 2 & 3. This parameter is called the rate-of-turn of the vessel. Vessels reporting this parameter generally have an external “rate-of-turn indicator” (TI) onboard that feeds the measured value from the sensor into the AIS transceiver, where it then gets converted into the “raw” value stored in the AIS messages.
How to convert the decoded “rate-of-turn” (rot) value into degrees per minute
The formula is as follows:
ROT_ais = 4.733 * √(ROT_sensor)
- “raw” rate-of-turn value stored in the AIS message
- rate-of-turn in °/min as reported by the TI onboard the vessel
For instance, a value of
ROT_ais translates into a value of
+708 °/min for
Note: Be aware that without special handling, converting a negative
ROT_ais value to the
ROT_sensor value will cause it to lose its negative (
-) sign in the process. This means that the vessel’s rotation would get reported as turning right/clockwise when it is actually turning left/anti-clockwise.
Range of Possible Values
- Vessel is turning right/clockwise at up to
708 °/minor higher
- Vessel is turning left/anti-clockwise at up to
708 °/minor higher
- Vessel is turning right/clockwise at more than 5° per 30 sec; TI is unavailable
- Vessel is turning left/anti-clockwise at more than 5° per 30 sec; TI is unavailable
- No turning information is available from the vessel
Ship Type mappings
The table below maps some common AIS shipType codes to the corresponding ship type used with the
shipType filter in Maritime 2.0 (both
shipSubType values are available as query output as well).
|20||Wing in ground (WIG), all ships of this type||OTHER|
|21||Wing in ground (WIG), Hazardous category A||OTHER|
|22||Wing in ground (WIG), Hazardous category B||OTHER|
|23||Wing in ground (WIG), Hazardous category C||OTHER|
|24||Wing in ground (WIG), Hazardous category D||OTHER|
|25||Wing in ground (WIG), Reserved for future use||OTHER|
|26||Wing in ground (WIG), Reserved for future use||OTHER|
|27||Wing in ground (WIG), Reserved for future use||OTHER|
|28||Wing in ground (WIG), Reserved for future use||OTHER|
|29||Wing in ground (WIG), Reserved for future use||OTHER|
|33||Dredging or underwater ops||DREDGER (was OTHER up to 2022-08-30)|
|34||Diving ops||DIVE_VESSEL (was OTHER up to 2022-08-30)|
|35||Military Ops||MILITARY_OPS (was OTHER up to 2022-08-30)|
|36||Sailing||SAILING (was OTHER up to 2022-08-30)|
|37||Pleasure Craft||PLEASURE_CRAFT (was OTHER up to 2022-08-30)|
|40||High speed craft (HSC), all ships of this type||HIGH_SPEED_CRAFT (was OTHER up to 2022-08-30)|
|41||High speed craft (HSC), Hazardous category A||HIGH_SPEED_CRAFT (was OTHER up to 2022-08-30)|
|42||High speed craft (HSC), Hazardous category B||HIGH_SPEED_CRAFT (was OTHER up to 2022-08-30)|
|43||High speed craft (HSC), Hazardous category C||HIGH_SPEED_CRAFT (was OTHER up to 2022-08-30)|
|44||High speed craft (HSC), Hazardous category D||HIGH_SPEED_CRAFT (was OTHER up to 2022-08-30)|
|45||High speed craft (HSC), Reserved for future use||HIGH_SPEED_CRAFT (was OTHER up to 2022-08-30)|
|46||High speed craft (HSC), Reserved for future use||HIGH_SPEED_CRAFT (was OTHER up to 2022-08-30)|
|47||High speed craft (HSC), Reserved for future use||HIGH_SPEED_CRAFT (was OTHER up to 2022-08-30)|
|48||High speed craft (HSC), Reserved for future use||HIGH_SPEED_CRAFT (was OTHER up to 2022-08-30)|
|49||High speed craft (HSC), No additional information||HIGH_SPEED_CRAFT (was OTHER up to 2022-08-30)|
|50||Pilot Vessel||PILOT_VESSEL (was OTHER up to 2022-08-30)|
|51||Search and Rescue vessel||SEARCH_AND_RESCUE (was OTHER up to 2022-08-30)|
|53||Port Tender||PORT_TENDER (was OTHER up to 2022-08-30)|
|54||Anti-pollution equipment||ANTI_POLLUTION (was OTHER up to 2022-08-30)|
|55||Law Enforcement||LAW_ENFORCEMENT (was OTHER up to 2022-08-30)|
|56||Spare – Local Vessel||OTHER|
|57||Spare – Local Vessel||OTHER|
|58||Medical Transport||MEDICAL_TRANS (was OTHER up to 2022-08-30)|
|59||Noncombatant ship according to RR Resolution No. 18||SPECIAL_CRAFT (was OTHER up to 2022-08-30)|
|60||Passenger, all ships of this type||PASSENGER (was VEHICLE_PASSENGER up to 2022-08-30)|
|61||Passenger, Hazardous category A||PASSENGER (was VEHICLE_PASSENGER up to 2022-08-30)|
|62||Passenger, Hazardous category B||PASSENGER (was VEHICLE_PASSENGER up to 2022-08-30)|
|63||Passenger, Hazardous category C||PASSENGER (was VEHICLE_PASSENGER up to 2022-08-30)|
|64||Passenger, Hazardous category D||PASSENGER (was VEHICLE_PASSENGER up to 2022-08-30)|
|65||Passenger, Reserved for future use||PASSENGER (was VEHICLE_PASSENGER up to 2022-08-30)|
|66||Passenger, Reserved for future use||PASSENGER (was VEHICLE_PASSENGER up to 2022-08-30)|
|67||Passenger, Reserved for future use||PASSENGER (was VEHICLE_PASSENGER up to 2022-08-30)|
|68||Passenger, Reserved for future use||PASSENGER (was VEHICLE_PASSENGER up to 2022-08-30)|
|69||Passenger, No additional information||PASSENGER (was VEHICLE_PASSENGER up to 2022-08-30)|
|70||Cargo, all ships of this type||GENERAL_CARGO|
|71||Cargo, Hazardous category A||GENERAL_CARGO|
|72||Cargo, Hazardous category B||GENERAL_CARGO|
|73||Cargo, Hazardous category C||GENERAL_CARGO|
|74||Cargo, Hazardous category D||GENERAL_CARGO|
|75||Cargo, Reserved for future use||GENERAL_CARGO|
|76||Cargo, Reserved for future use||GENERAL_CARGO|
|77||Cargo, Reserved for future use||GENERAL_CARGO|
|78||Cargo, Reserved for future use||GENERAL_CARGO|
|79||Cargo, No additional information||GENERAL_CARGO|
|80||Tanker, all ships of this type||GENERAL_TANKER|
|81||Tanker, Hazardous category A||GENERAL_TANKER|
|82||Tanker, Hazardous category B||GENERAL_TANKER|
|83||Tanker, Hazardous category C||GENERAL_TANKER|
|84||Tanker, Hazardous category D||GENERAL_TANKER|
|85||Tanker, Reserved for future use||GENERAL_TANKER|
|86||Tanker, Reserved for future use||GENERAL_TANKER|
|87||Tanker, Reserved for future use||GENERAL_TANKER|
|88||Tanker, Reserved for future use||GENERAL_TANKER|
|89||Tanker, No additional information||GENERAL_TANKER|
|90||Other Type, all ships of this type||OTHER|
|91||Other Type, Hazardous category A||OTHER|
|92||Other Type, Hazardous category B||OTHER|
|93||Other Type, Hazardous category C||OTHER|
|94||Other Type, Hazardous category D||OTHER|
|95||Other Type, Reserved for future use||OTHER|
|96||Other Type, Reserved for future use||OTHER|
|97||Other Type, Reserved for future use||OTHER|
|98||Other Type, Reserved for future use||OTHER|
|99||Other Type, no additional information||OTHER|
Speed over ground (sog) rules
The AIS specification for
sog (Speed over ground) shows that 102.3 knots is reported when the vessel speed is unavailable. So for some reason the vessel is not transmitting its speed in its AIS messages. This could be a technical issue on the vessel.
Speed over ground in 1/10 knot steps (0-102.2 knots)
1 023 = not available, 1 022 = 102.2 knots or higher
In the Vessels and Messages APIs we return the values as received. We have reports that some other AIS providers take the decision to report the unknown speed value of 102.3 as zero.
Technically this is wrong and while appearing correct when the vessel is in port, would not be correct when the vessel is moving or at sea.
For clarity to customers we have changed our reporting slightly in Vessels 2.0;
sog values of 102.3 are reported as
null because several users experienced confusion from the reported value.
"collectionType": "TERRESTRIAL", "heading": 358, "speed": null, "timestamp": "2021-08-19T09:36:21.582Z"
Legacy Vessels API
"speed": 102.3, "rot": -1.0, "collection_type": "terrestrial", "timestamp": "2021-08-19T09:30:24+00:00"
Tokens & API keys
Each authorization token is unique
For the TCP feed, if your company uses multiple clients to simultaneously access the Spire Maritime platform, one particular authorization token should not be shared among several users. An exception can be made if you only have one TCP client active at a time. Otherwise, doing so could result in all clients only receiving a subset of available AIS messages.
This restriction does not apply to the Maritime 2.0 API, Messages API or Vessels APIs – multiple API clients can use the same token (provided the rate of API calls remains below below about 30 calls per minute for legacy platforms and rate limiting policies are respected).
If multiple people at your company are interested in simultaneous data access, notify the Customer Experience team so multiple tokens can be created.
What happens when my token expires?
When the agreed upon end date of your access is reached, our services will automatically disable your authorization token. You should receive an error response to an API call such as this one (applicable for Vessels API or Messages API):
13 Permission Denied Connection closed by foreign host.
If you suspect this has happened in error, please notify the Customer Experience team.
Are multiple tokens necessary to access multiple Spire Sense APIs?
One token can be used to access all Maritime 2.0 root queries, and so is the case for Spire Maritime’s REST APIs, but they are not interchangeable between platforms (this also includes Geospatial Web Services). If you are interested in trying additional APIs, notify the Customer Experience team.
I suspect my authorization token has been compromised
If you unintentionally shared your authorization token with others, notify the Customer Experience team so a new authorization token can be issued. No loss in data should occur as you transition to the new token.
While using AIS data, there is a chance that you may have encountered the duplicate vessel challenge.
AIS does not enforce data integrity, so there are many vessels globally that, in their AIS messages, are transmitting the same MMSI and/or IMO number as other vessels.
AIS data alone does not allow identification of which vessel is correctly using an MMSI or IMO number and which is not. Because of this challenge, in legacy Vessels API, you may have seen instances of:
- 2+ vessels reporting the same MMSI number (different IMO)
- 2+ vessels transmitting only the same IMO number (different MMSI)
- 2+ vessels transmitting the same IMO and MMSI number
With Maritime 2.0, we have improved a logic for vessel identification that helps combat this issue.
In Vessels API, an update would only be made if the same value for a vessel was seen at least three times for static values and at least two times for voyage related fields.
In Maritime 2.0, all static messages will be considered after just two occurrences. The criteria for updating is now based on identity variables to match and create vessels. All position messages are considered for possible update after one occurrence based on two criteria: feasibility criterion on positions and selection of most plausible vessel in case of duplicated MMSIs.
In tests, we have seen a great reduction in duplicate IMO and MMSI positions. Here is a data visualization that illustrates Maritime 2.0’s improvement over the Vessels API:
Handling vessel MMSI changes
Unique vessel identifiers are a complex topic in AIS. From a technical perspective, vessels transmit AIS messages using an MMSI (Maritime Mobile Service Identity) number as their identifier; this is especially true in position messages, where no other identifier is present.
However, when a vessel changes its flag, its MMSI number changes as well. It will thereafter transmit all AIS messages with its new MMSI number, never again including its old MMSI number.
In static voyage messages, however, more vessel information is available alongside the MMSI, such as:
- the IMO number, the only consistent identifier of large vessels (never changes)
- the Name of the vessel (can change)
- the vessel’s Dimensions, distances from the AIS transmitter to both sides, stern, and bow of the vessel (though mainly static can be adjusted by reassessment or physical changes)
- the Callsign, a radio communication identifier linked to the flag registration (changes along with the MMSI number when a vessel changes flag)
Considering that 85% of AIS messages are either static or position messages, and that the MMSI number is the only identifier in position messages, the MMSI is always used to link position messages to static voyage messages; however, in order to track vessels consistently and reliably, it is important to understand its relation to the IMO number, which is a more consistent unique identifier for larger vessels.
Here is an aggregation of AIS static data values received for a vessel which changed MMSI number:
|538009951||9150406||SMILEY LADY||V7A5382||183.0||25.0||70||2022-04-11 09:26:02 UTC||2022-04-11 15:08:035 UTC||104|
|311000889||9150406||SMILEY LADY||C6EG6||183.0||25.0||70||2022-03-13 00:02:00 UTC||2022-04-11 08:56:00 UTC||10408|
This vessel, with IMO
9150406, stopped transmitting AIS messages using the MMSI
22-04-11 08:56:00 UTC; from then on, it transmitted AIS messages using the MMSI
538009951, with the first AIS static message using that MMSI being received at
2022-04-11 09:26:02 UTC. All subsequent AIS messages from this vessel use that MMSI number.
When a vessel changes MMSI number like this, the old version of the vessel remains in the system and a new vessel is created that reports the new MMSI and IMO combination. This is true for both the Maritime 2.0 and the legacy Vessels API platform.
This means that querying based on the
name fields (two identifiers which stayed the same in both the old and new
mmsi versions) will return both the old and new version of the vessel, whereas querying by the
mmsi field, using the old or new values, will only return the corresponding entries. Likewise, querying on time-based, recent updates using the
lastPositionUpdated filter will only return the new vessel.