Skip to content

The Satellite Passes ​

Each time the Surface Water and Ocean Topography (SWOT) satellite passes over the Gulf of Maine, it measures the height of the sea across two wide swaths either side of its track, and wherever a swath reaches a gauge, the pass is a second reading of the water that gauge records. Where The Gauge Series follows the gauge's side of the comparison, this page follows the satellite's, from the archives publishing each pass, through the fetch and the files a clone keeps, to the one table of the samples near the gauges.

The Passes Kept ​

The passes come from PO.DAAC's SWOT Level 2 KaRIn Low Rate Sea Surface Height product, Version D⁠1⁠, and the fetch reads two of the four files the archive publishes for each pass. The Expert file, on a 2 km grid, carries every variable of the Basic and WindWave files beside the terms of each correction, whereas the Unsmoothed file, on a grid of about 250 meters, keeps the heights KaRIn measures before they are smoothed onto the coarser grid. Beside them, the fetch reads AVISO's Level 3 Unsmoothed product, which AVISO builds from the same Level 2 heights.

The Expert file takes every pass, from the first the archive holds to the newest, whose footprint crosses a box drawn around the 50 km reach of every gauge in the station catalog, a retired gauge included, so a retirement never changes which passes are kept. That reach is the setting reach-m, and the two products on the 250 meter grid keep their samples within the same 50 km under unsmoothed-reach-m, both chosen from the radii The Moving Water reports. That grid holds 64 times as many samples as the 2 km one over the same water, so a 50 km reach keeps about 211,000 Unsmoothed samples of a pass on cycle 52 and a table of more than 100 million rows over the mission, which the fetch keeps in one file per pass. The search radius radius-m can be no wider than either reach.

ProductServed ByGridReachA Part
Level 2 ExpertPO.DAAC's OPeNDAP service2 km50 kmAbout 0.2 MB
Level 2 UnsmoothedPO.DAAC's OPeNDAP service250 m50 kmAbout 3.7 MB
Level 3 UnsmoothedAVISO's DAP2 service250 m50 kmAbout 2.2 MB

The passes up to 2023-07-10 follow the daily orbit SWOT flew in its first months, only one of whose tracks reaches the gauges, and those from 2023-07-28 on follow the 21-day orbit The Satellite’s Reading describes. Each orbit numbers its passes on its own scheme, so a pass number names a track only beside its orbit, and the mission's user handbook tells the two apart by cycle, the 21-day orbit running from cycle 1 to 399 and the daily orbit from 400 to 578.

One File per Pass ​

The archive can list several files for one pass, since it leaves the earlier file listed whenever it reprocesses the mission's data or produces a file again, so the fetch keeps one under the rules of the SWOT Science Data Products User Handbook and the release note for Version D:

  1. The file of the latest major version of the product
  2. The reprocessed file over the one forward processing made shortly after the pass, where both exist
  3. The file of the latest minor version
  4. The file made most recently, which the handbook numbers with its product counter

The Part Kept ​

A pass is half an orbit, running from the far south of the satellite's track to the far north or back, so only a sliver of it lies near Maine. The fetch asks PO.DAAC's OPeNDAP service for that sliver alone, meaning the variables the samples table and The Pass Schedule read and a few the table leaves out, on the run of lines crossing the box and the run of pixels of each swath within reach of a gauge, with each value exactly as the product stores it, so the part reads back to the same numbers as the whole pass. An Expert part runs to about 0.2 MB, against about 34 MB for the whole pass.

Finding the Window ​

  • The lines crossing the box and the pixels within reach are found once per track, meaning one pass number on one orbit, from one pass along it, first from the latitude and longitude of the middle pixel of every line and then from those of every pixel on the run of lines the middle pixel finds, since a swath crosses the box's edges at a slant. Every pass along a track crosses the box on the same lines, because the product samples each pass on a geographically fixed grid bounded by the reference orbit's track, as the handbook describes.
  • The Unsmoothed file's grid is not fixed, since JPL D-56407 ties it to KaRIn's timing and the spacecraft's ephemeris, which vary from pass to pass, and leaves out the gaps at a granule's ends, so the line crossing one place shifts from cycle to cycle, by a few lines on most tracks and by 247 lines, about 62 km, between cycles 52 and 53 of pass 285. Its window is therefore found for each pass, from the latitude and longitude of the middle pixel of each half swath on every eighth line, and then of every eighth pixel on the run of lines that pixel finds, 2 km apart as on the coarser grid, reaching one stride of eight before the first line and pixel within 52 km of a gauge and one past the last, so no sample within reach falls between two positions read.
  • A line joins that run wherever its middle pixel lies within the reach widened by those 2 km and by 75 km, the widest cross_track_distance JPL D-56407 declares valid, which reaches past the 70 km either side of the reference track the 2 km grid spans and the roughly 64 km from nadir each Unsmoothed half swath reaches, so the run holds every line the positions across the whole pass would find. The positions read to find an Unsmoothed window then come to about 0.2 MB a pass, against about 2.3 MB across the whole pass.
  • An Unsmoothed window holds only the lines with a sample within reach, whereas an Expert part keeps every line crossing the box, since the pass schedule reads the nadir track across the whole box from the Expert file. The Unsmoothed file holds each half swath in its own group, left and right, and a request slices each group's lines and pixels before naming any variable, the one order the service accepts.
ProbesRunWindow

The middle pixel of every eighth line

Every eighth pixel, only where a probe counted

One stride past the last pixel within reach

Still readingof about 2.3 MB, the whole pass

Pass 285 on the real coast and gauges, every length to one scale.

Commit47945eaDataschedule.jsonUnreleased1.2.0

The Parts on Disk ​

  • Each part is the NetCDF-4 file the service writes for the window, holding each variable the fetch requests that the pass's DAP4 metadata response names and every global attribute of the whole pass, beside a history the service extends with a line naming the request and a few attributes it adds, such as history_json, each variable compressed by deflate. The service answers one run of lines and one of pixels per group in a request, so a part holds each run from its first line or pixel to its last.
  • A pass whose record names no address on the service, or that the service answers with a 404, downloads whole from PO.DAAC's archive instead and is cut to the same window and variables, so a part of either kind reads to the same samples. With any of the three logins, the fetch reads the pass from archive.swot.podaac.earthdata.nasa.gov through one redirect, which the Authorization header does not survive and need not, since only the first request authorizes.
  • A pass listed over the box on a track with no line crossing it is kept as a file holding no line, cut from the pass's first line, so the next fetch skips it.
  • The passes land in a directory under data/swot/ named for their level and their file, l2/expert, l2/unsmoothed, or l3/unsmoothed, one file per pass under the archive's name for it, with a manifest.json recording the version, the reach, the box, and the variables each part keeps, beside the collection and the file for a Level 2 directory. Those variables include a few the samples table leaves out, such as the flags of rain and ice, so every part a release carries still matches the manifest. A gauge the catalog gains inside the box leaves that manifest as it was, so the next fetch requests nothing and reads every pass's samples again with the new gauge's. A gauge outside the box widens it, which empties the directory once the fetch starts, as a change of reach or a table reading another variable does, so the next fetch requests every pass again.
  • A pass with a newer file in the archive loses the part kept from its older one, so no pass is read twice, and the fetch records the newer file in place of the older one, as The Weekly Release sets out.

Fetching the Passes ​

mise run data:fetch:swot lists the Expert and the Unsmoothed passes through NASA Earthdata, requests each pass either directory lacks from the OPeNDAP service, every pass of both files at once, checks or cuts each on its own processor core as it lands, and then brings the samples table up to date, reading on its own processor core each pass whose samples file is missing or out of date, so no process holds more than one pass's samples in memory and a fetch that finds nothing new reads no pass. mise run data:fetch:swot l3 fetches the Level 3 passes alone, and mise run data:fetch:swot l2 l3 fetches all three at once, under one bar counting every pass. A SWOT fetch reads the coastline as it fills the samples table, so mise run data:fetch:coast runs ahead of it.

The fetch logs in from any of the three places Save the Earthdata Login names. Each request goes through its thread's session, which sends the login's token as a bearer token and keeps the cookies the service sets once it has checked the token, and the OPeNDAP service accepts that token without a redirect, as OPeNDAP's guide to authenticating with an Earthdata Login token sets out.

  • A rerun requests only the passes published since and any whose request failed, then reads the samples of those passes and of any other pass whose samples file is out of date.
  • An option of tidemark fetch swot seeds nothing and requests every pass of each file again, replacing every part held.
  • A pass that fails leaves the others in place, and a response still cut short once the service is asked again, or holding another number of lines than the request named, fails its pass and leaves no part behind.
  • A request either service never answers, or answers with a 429, 502, 503, or 504, is sent again once that service reopens, at the pace its refusals set, as The CO-OPS Throttle sets out for every source, whereas the 500 PO.DAAC's service answers a refused login with fails its pass at once. A pass downloaded whole from PO.DAAC's archive goes through earthaccess, which tries each file up to three times itself.

Seeding From a Release ​

Each weekly release carries one tar of each file's directory, the two Level 2 files and the Level 3 file, holding its passes and its manifest.json, whereas no tar carries the samples table, which every fetch fills again from the passes, as The Weekly Release sets out. Nearly all of their size is the two Unsmoothed tars, each of which travels in pieces.

  • Where a file's directory holds nothing yet or records the same fetch and lacks a pass that began before the newest release carrying that file's tar was published, among the releases no later than the package's version, the fetch first moves in the part that file's tar holds of it, so a fresh clone requests only the passes the release lacks.
  • The seed downloads the tar, or each of its pieces once the one before is read, checks each against the SHA-256 digest GitHub lists for it, and names how many passes it seeded from which release.
  • The seed reads the parts from whichever directory of the tar holds its manifest.json, so a tar whose directory carries the collection's name, such as SWOT_L2_LR_SSH_D/Expert, seeds l2/expert all the same.
  • Under --release, the fetch seeds from the one release a tag or a day names, lists and fetches nothing, and then fails on any part parts.json records that the store still lacks or holds under another SHA-256. A tar recording another manifest, as the Level 3 tars of releases 1.0.0 and 1.1.0 do, takes the place of the directory whole at the path this code reads and takes no such check, whereas a replay keeps each file at the path its release packed it under. A release gh cannot read, or a name matching no published release, fails once, naming it, before any part is read.
  • The Level 3 seed reads the release alone and needs no AVISO+ login, so a clone holding none still takes every Level 3 pass the release carries, whereas a pass the release lacks takes the login Fetching Level 3 Passes names.

Fetching Level 3 Passes ​

AVISO serves the Level 3 product from its THREDDS server, whose catalog lists every file without a login, and mise run data:fetch:swot l3 lists from it every pass of the 21-day orbit on a track whose swath covers a gauge in The Pass Schedule, reading the catalog of every cycle at once. Where the catalog holds a pass under forward as well as reproc, the fetch takes the reproc file, since the handbook calibrates the reprocessed file from the delayed-time nadir products. It reads each pass's description from the server's DAP2 service, then the position of the middle pixel on every eighth line, and of every eighth pixel on the run of lines that pixel finds, the 2 km stride a Level 2 Unsmoothed window reads, and in a last request every variable the table reads and ssha_unedited on the lines and pixels within reach of a gauge, reaching one stride past the positions within reach widened by 2 km, so no sample within reach is left out.

  • The server delivers in proportion to the requests in flight, from 0.23 MB a second for one to 7.7 MB for 64, so the fetch requests every pass at once unless an option of tidemark fetch swot caps the count, under the login mise run data:login:aviso saves.
  • Every request goes through a session the fetch holds over HTTPS alone, with pydap reading each answer, since pydap's own client retries a failed connection over plain HTTP, which would send the login unencrypted.
  • While many passes are in flight, the server cuts some answers short before all their data arrives. The fetch decodes each answer carrying data in the attempt that requests it, so an answer cut short counts as a refusal, as a 503 or a dropped connection does. The request is then sent again once the server reopens, at the pace its refusals set, as The CO-OPS Throttle sets out for every source.
  • Each part keeps the variables the samples table reads as the product stores them, compressed with deflate as the product's own files are, and is written under .partial before it lands in l3/unsmoothed, so a fetch stopped partway leaves nothing behind.
  • A part whose file the catalog no longer lists is removed, as a Level 2 part is once the archive makes a newer file of its pass.
  • Each part keeps the temporality its file carries, reproc or forward, which the samples table reads into a column of its own. A part reading forward is requested again once the catalog lists its pass under reproc, since a file's name carries no directory, and the fetch records the replacement, as The Weekly Release sets out. The Level 3 file's manifest.json records the global attributes each part keeps beside its variables, so a directory of parts kept without temporality is emptied once the fetch starts and fetched again, and a release whose parts lack it seeds nothing.

The AVISO License ​

The AVISO License lets anyone use and share the product and what is made from it, provided the source is credited, but forbids sharing the original, unmodified files through a platform meant for onward mass distribution, such as a web portal, a public API, or a cloud store, without the written authorization of CNES, a condition that does not reach a product modified from them (§3.2).

  • Each part release 1.2.0 and each one after it carries is a Value-Added Product, modified from the product while keeping its data structure (§1c). It holds the lines and the pixels of a pass within reach of a gauge and the variables the table reads beside ssha_unedited, each as AVISO stores it, and tidemark pack adds to it correction, the sum of the terms a height restores, height, the height ahead of taking out the load tide, gauge_distance, and coastline_distance.
  • mise run gha:roll therefore packs the parts into each weekly release beneath a CREDITS.md naming AVISO as the producer and CNES as the licensor, the product's citation and DOI, the license, and each modification (§3.1), beside §3.2 itself and the Open Database License over coastline_distance, and the pack fails on a tar holding a part lacking those additions.
  • mise run data:downloads prints how many times GitHub has served the tar each release carries, the record of usage a share at scale keeps (§7.3).
  • A figure or a statistic computed from the Level 3 parts is published citing the product's entry in docs/references.bib⁠2⁠, with the license and the statement that the project modified the data set out once in Credits on the Data overview, implying no endorsement by either (§2.6).

The Local Machine ​

  • The fetch lists every file before it requests any pass, and where the passes still missing come to a gigabyte or more, it names each file's passes, their size, and the time they take before asking whether to go on, which an option of tidemark fetch swot answers ahead of time for a fetch with no terminal to ask at. Apart from the passes the seed moves in, nothing under data/ changes before the answer, so an answer of no leaves in place a directory a change of reach would empty. A fetch of all three from nothing downloads about 9.4 GB, about 0.2 GB of Expert passes, 2.9 GB of Unsmoothed ones, and 6.3 GB of Level 3 ones, estimated from every Expert pass's window and the bytes a sample of each response takes, and holds about 9 GB under data/ once the samples table is filled.
  • The fetch refuses to write into a folder a file provider such as iCloud Drive syncs, as ~/Documents and ~/Desktop are on a Mac that syncs them, since the sync would upload every pass. macOS marks such a folder with the attribute com.apple.file-provider-domain-id, and the fetch writes once a folder between it and data/ carries com.apple.fileprovider.ignore#P, the attribute leaving a folder out of the sync, which xattr -w com.apple.fileprovider.ignore#P 1 <clone>/data sets on the data folder.
  • Each request, to PO.DAAC's service or AVISO's, holds a connection and the file it writes, beside the fewer than 128 files the rest of the fetch holds, so the fetch raises its own limit on open files to fit every request it sends, past the 256 a stock macOS lets a process hold open, as far as the system's hard limit allows. An option of tidemark fetch swot caps the requests in flight instead, such as to measure a service at one count.

The Samples Table ​

One row per

SWOT sample within reach of a gauge

cycle_numberpass_number

Shares cycle_number with 3 and pass_number with 4 other tables.

32columns

Commit47945eaDatastations.jsonUnreleased1.2.0

The samples table holds one row per sample within reach of a gauge across every pass of the three files, kept in data/swot/samples/ as one Parquet file per part, named for the part, and tidemark run reads every file of the folder as one table through a single scan. Each row names its level and its file, l2 or l3 beside Expert or Unsmoothed, and the analysis reads the Level 3 and the Level 2 Unsmoothed rows for their heights and the Expert rows for the load tide each Level 3 sample takes. The folder is brought up to date before anything reads it, by tidemark fetch swot once it has fetched each file, by tidemark run in its samples step, ahead of the steps reading the samples near each gauge, and by tidemark excerpt, each reading on its own processor core every part whose file is missing or out of date and starting no process where none is. Each part's samples take their coastline_distance as the part is read, from the coastline mise run data:fetch:coast keeps in data/coast/, and a read where that directory holds none stops on an error naming the task. The distance takes about 15 microseconds of one processor core per sample, measured over 9.8 million Level 2 Unsmoothed samples, which makes it the longest part of reading a part, so a change to any module the manifest records reads every part again at that cost.

  • The folder's manifest.json records what every file is read with, meaning each fetch's manifest, the digest of the coastline each sample is measured from, the position of every gauge, the SHA-256 digest of the source of each tidemark module the read runs or takes a record from, and the versions of polars, xarray, netCDF4, numpy, pandera, and scipy, so a change to any of them empties the folder and every part is read again.
  • Each file records in its Parquet metadata the SHA-256 digest of the part it was read from and, for an Unsmoothed part, that of the Expert part its corrections come from, so a part holding other bytes under the same name, such as a Level 3 file AVISO has processed again, or whose Expert part changed, is read again. The time a file was written plays no part, since a part seeded from a release carries the tar's fixed time.
  • A file whose part is gone is removed, as the part is once the archive makes a newer file of its pass, and the samples and the empty passes a fetch counts are read from each file's count of rows.

A column takes the name its product gives the variable it holds, as JPL's product description (JPL D-56407) names each Level 2 variable and the DUACS Level 3 handbook each Level 3 one, and stays empty on a row whose level holds nothing for it. A Level 2 row keeps both heights of the sea surface the product gives above the WGS 84 ellipsoid, which differ in how each corrects for the water vapor between the satellite and the sea and for the effect of waves on the radar, and each correction a comparison removes from a height or adds back takes its own column. A Level 3 row keeps ssha_unfiltered beside each term a reader adds back to it, and its cross_track_distance, which the product's files give in kilometers, in meters as every other distance the table holds. A line the product filled with nothing carries neither an instant nor a height, so its samples are left out.

JPL D-56407 gives the Unsmoothed file none of the correction terms, so each Unsmoothed sample takes the ocean, load, pole, and solid Earth tides, dac, the mean sea surface, and distance_to_coast from the Expert sample of the same pass whose 2 km pixel holds it, meaning the one on the Expert line measured nearest in time and, along that line, nearest across the track. On cycle 52, pass 7, the terms the Unsmoothed anomaly removes, each taken this way from the Expert file, add up over open ocean to the file's own ssh_karin_2 less ssha_karin_2 with a median difference of 0.2 cm and an interquartile range of 2.4 cm. Over land and continental water the two differ by about 30 cm, because JPL D-56407 computes the anomaly there against the geoid rather than the mean sea surface, with only the load parts of the ocean and pole tides and neither the internal tide nor dac, whereas the Expert columns hold each term as computed for the ocean.

Each Level 2 height's quality flag is a set of bits naming what lowered the quality rather than the quality itself, so the table keeps the band each flag falls in, such as ssh_karin_quality for ssh_karin_qual, whereas the surface-type flag and Level 3's quality_flag keep the name the product gives each code. mise run docs:render writes each band's flag values below from Quality, where the package declares them as JPL D-56407 reads them.

BandFlag Values
goodA flag of 0, the band the mission's user handbook, JPL D-109532, names as the one a reader would normally use
suspectA flag from 1 up to 2³⁰ − 1, which JPL D-56407 reads as suspect
degradedA flag from 2³⁰ up to 2³¹ − 1, which JPL D-56407 reads as degraded
badA flag of 2³¹ or more, which JPL D-56407 reads as bad

Workarounds in the Studies names which of the two heights and which quality flags the coastal studies kept, and mise run docs:render writes the table's columns below from the schema it is checked against.

  • Level 2 · 21

  • Level 3 · 15

  • Expert source · 7

cycle_number

Which repeat of SWOT's ground track a row comes from

Every value as a table
ColumnHolds
cycle_numberA shared key the tables join on
pass_numberA shared key the tables join on
ancillary_surface_classification_flagThe surface type a map built from MODIS and GlobCover gives the sample
calibrationThe calibration in meters against the nadir altimeters, already applied to ssha_unfiltered, which ssha_unfiltered - calibration undoes
coastline_distanceThe distance in meters to the nearest point of the OpenStreetMap coastline, negative on the land side
cridThe composite release identifier naming the processing software and inputs that produced the pass
cross_track_distanceThe distance in meters from the satellite's nadir track, negative on its left side
dacThe dynamic atmospheric correction in meters, the sea surface's response to air pressure and wind, already removed from ssha_unfiltered
distance_to_coastThe distance in meters along the surface to the nearest coast, which the files sign negative on the land side, although JPL D-56407 describes it as zero over land (§4.1.5)
fileThe file of its level the sample was read from, spelled as the file's own name spells it
height_cor_xoverThe crossover correction in meters, which the product computes and adds to no height
internal_tideThe coherent internal tide in meters, already removed from ssha_unfiltered
latitudeWhere the sample sits in degrees north
levelThe level of SWOT product the sample was read from
load_tide_fesThe load tide in meters, whose short-period part ocean_tide_fes already includes
longitudeWhere the sample sits in degrees east, from -180 to 180
mean_sea_surface_cnesclsThe mean sea surface in meters above the ellipsoid
mssThe mean sea surface in meters above the ellipsoid
ocean_tideThe geocentric ocean tide in meters, the ocean tide and its load tide summed, already removed from ssha_unfiltered
ocean_tide_fesThe ocean tide in meters, including the short-period load tide and the long-period equilibrium tide
pole_tideThe pole tide in meters
product_versionThe version of the Level 3 product the pass was read from
quality_flagThe name the product gives the sample's quality value
solid_earth_tideThe solid Earth tide in meters
ssh_karinThe sea surface height in meters above the ellipsoid, corrected for the wet troposphere by the radiometer and for the sea state bias by the product's first correction
ssh_karin_2The sea surface height in meters above the ellipsoid, corrected for the wet troposphere by a weather model and for the sea state bias by the product's second correction
ssh_karin_2_qualityThe quality band ssh_karin_2_qual falls in
ssh_karin_qualityThe quality band ssh_karin_qual falls in
ssh_karin_uncertThe one-sigma random error in meters of either sea surface height
ssha_unfilteredThe sea surface height anomaly in meters, calibrated and edited and with every correction applied
temporalityThe directory AVISO serves the pass's file from, reproc for a file calibrated from the delayed-time nadir products and forward for one calibrated from the near-real-time ones
timeThe instant the sample was measured at, in UTC

The coastline this page reads is a derivative database under the Open Database License, and tidemark fetch coast makes a free copy of the cut.

Level 3's Differences ​

AVISO builds its Level 3 product from the same Level 2 low rate product, applying the corrections to one sea surface height anomaly, calibrating each pass against the nadir altimeters, and reducing each pixel's flags to a single value, so a Level 3 row of the samples table differs from a Level 2 row in the ways below. Each difference comes from the DUACS Level 3 handbook for version 3.0 of the product, which also lists the product's known limitations near a coast.

DifferenceIn the Level 2 RowsIn the Level 3 Files
The correctionsEach a column of its own beside the two heights above the ellipsoidApplied to ssha_unfiltered, with the ocean tide, dac, and the internal tide each kept as a variable a reader adds back
The ocean tideocean_tide_fes, which already includes the short-period load tide and the long-period equilibrium tide, beside load_tide_fesocean_tide, the geocentric sum of the ocean tide and its load tide, with the equilibrium and non-equilibrium long-period tides included
The water vaporThe radiometer's in ssh_karin, a weather model's in ssh_karin_2A weather model's, the only one applied
The mean sea surfacemean_sea_surface_cnesclsmss, a beta of the CNES_CLS_2025 surface, which the handbook states is not optimized for coastal areas
The systematic errorheight_cor_xover, added to no heightcalibration, the phase screen and the cross-calibration against the nadir altimeters, already applied to the anomaly
The qualityThe band each height's bits fall in, such as ssh_karin_2_qualityquality_flag, one value per pixel that is 0 where the pixel is valid, 3 on an eclipse transition the edited anomaly keeps, and otherwise names why it was rejected, where the handbook recommends keeping 0 through 3
The Level 2 processingVersion D for every passVersion C up to cycle 32, pass 223, and Version D after it

The Nadir Tracks ​

One row per

line of each pass

cycle_numberpass_number

Shares cycle_number with 3 and pass_number with 4 other tables.

7columns

Commit47945eaDatastations.jsonUnreleased1.2.0

Every Expert pass also carries, for each line across its swaths, the point directly beneath the satellite, the direction it was flying, and the instant the line was measured. The analysis's tracks step reads that track out of every Expert part the fetch kept, again whenever a part or a setting the fetch's request records changes, and Distance Across the Swath measures how far each gauge sits from it. The pass schedule also ships each pass's ground track near a gauge as ground_tracks.parquet. mise run docs:render writes the track's columns below from TrackSchema.

ColumnHolds
cycle_numberA shared key the tables join on
pass_numberA shared key the tables join on
latitude_nadirWhere the point beneath the satellite sat in degrees north
longitude_nadirWhere the point beneath the satellite sat in degrees east, from -180 to 180
timeThe instant the line was measured at, in UTC
time_coverage_startThe instant the pass's granule begins, in UTC, which is the instant the pass began wherever the granule holds the whole pass
velocity_headingThe direction the satellite flew over the ground, in degrees clockwise from true north

  1. 1SWOT 2025. "SWOT Level 2 KaRIn Low Rate Sea Surface Height Data Product." Version D. NASA Physical Oceanography Distributed Active Archive Center. https://doi.org/10.5067/SWOT-SSH-D.↩︎

  2. 2AVISO/DUACS 2024. "SWOT Level-3 SSH Unsmoothed." Version 3. CNES. https://doi.org/10.24400/527896/A01-2024.003.↩︎