Data & API Requests

I am sending the link to the data portal download to the SAR detections dataset. It's the most updated dataset but it appears as seventh or eight in the list (and the download does not seem to follow any particular order). If the most recent dataset updated were first that would be great. Also, it would be great if the datasets from papers like Paolo et al. 2024 and the datasets that don't (the ones that are more regularly updated) were tagged differently.

They wish to utilize it for cost computation. Presently, they rely on events, assuming a direct trajectory between each event. They experimented with 10 vessel tracks and found speed to be beneficial. If access to the track is unavailable, publishing the total kilometers traveled and average speed for a specific period per vessel would still prove valuable.

Currently the loitering table in pipe3 (it is the same in pipe 2.5) includes the ssvid associated with each event, but doesn't have vessel_id . Encounters... a related table only has vessel_id s for each vessel involved in the events and does not include the ssvid s. It seems like it be helpful from a user perspective if these tables were consistent using using vessel_id or ssvid . Loitering table: world-fishing-827.pipe_ais_v3_alpha_published.loitering Encounters table: world-fishing-827.pipe_ais_v3_alpha_published.encounters

Loitering events do not currently have a unique ID world-fishing-827.pipe_ais_v3_alpha_published.loitering . We should add a unique ID (using similar methodology for other events) to these events.

Regarding filtering dates in the Events API: it would be useful to be able to specify whether the function uses hard bounds or not. For example I am looping over several months trying to extract the fishing events. To make sure I get them all it would be great is the function returned every event that began in each month, even if it didn't end in it, but I also don't want to double count events that began in January and ended in February. So at least for that purpose it would be useful to specify a "hard" start bound and a "soft" end bound.

Currently it looks like the encounters table has 3 broad vessel classes (fishing, carrier,other- non-fishing). I understand the need to aggregate vessel classes here but I think having gear here would be really useful so that we can easily identify fishing_vessel - gear interactions.

I have reviewed your API guides. I was able to get them working with a few tweaks in python. Do you have any guides on how to directly integrate with ARCGIS Pro. I played around a bit with adding your data sources as data paths but no luck.

Many coastal states regulate transhipment to take place within their port limits as an MCS control mechanism. This is often paired with regulations that prohibit at-sea transhipment. Currently GFW tools do not show transhipment activity within 10km of the coast because of the noisy data from many vessels transiting in coastal areas, and vessels being in proximity to many other vessels within both anchorages and ports which all lead to lots of encounters being generated (both true and false). It is important to be able to evaluate this in-port activity as it is the primary vector of fish movement in many coastal states and the current configuration of GFW tools does not identify in port-transhipments for MCS users to investigate.

with the events endpoint is it possible to pull port events for specific ports rather than having to pull the entire global dataset and filter it to a specific location? We have a user that is requesting port visits to specific ports and they'd rather not pull all the data and apply that filter afterwards.