ERDDAP Easier access to scientific data

Brought to you by NOAA NMFS SWFSC ERD

ERDDAP > tabledap > Documentation

Using tabledap to Request Data and Graphs from Tabular Datasets

The URL specifies what you want: the dataset, a description of the graph or the subset of the data, and the file
type for the response.

• (easy) You can get data by using the dataset's Data Access Form or Subset form.
  They make the URL for you.
• (easy) You can make a graph or map by using the dataset's Make A Graph form. It makes the URL for you.
• (not hard) You can bypass the forms and get the data or make a graph or map by generating the URL by
  hand or with a computer program or script.

Tabledap request URLs must be in the form
   http://edac-dap2.northerngulfinstitute.org/erddap/tabledap/datasetID.fileType{?query}
For example,
   http://edac-dap2.northerngulfinstitute.org/erddap/tabledap/pmelTao.htmlTable?longitude,latitude,time,sea_surface_temperature&longitude>180&longitude<180.2&latitude>0&latitude<0.2&time>2007-06-01T00:00:00Z
Thus, the query is often a comma-separated list of desired variable names, followed by a collection of
constraints (e.g., variable<value) each separated by '&' (which is interpreted as "AND").

Details:

• Requests must not have any internal spaces.
• Requests are case sensitive.
• {} is notation to denote an optional part of the request.
   
• datasetID identifies the name that ERDDAP assigned to the source web site and dataset
  (for example, pmelTao). You can see a list of datasetID options available via tabledap.
   
• fileType specifies the type of table data file that you want to download (for example, .htmlTable).
  The actual extension of the resulting file may be slightly different than the fileType (for example,
  .smallPdf returns a small .pdf file).
  The fileType options for downloading tabular data are:
   

  Data fileTypes	Description	Info	Example
  .asc	View an OPeNDAP-style comma-separated ASCII text file.	info	example
  .csv	Download a comma-separated ASCII text table (line 1: names; line 2: units; ISO 8601 times).	info	example
  .csvp	Download a .csv file with line 1: name (units). Times are ISO 8601 strings.	info	example
  .das	View the data's metadata via an OPeNDAP Dataset Attribute Structure (DAS).	info	example
  .dds	View the data's structure via an OPeNDAP Dataset Descriptor Structure (DDS).	info	example
  .dods	OPeNDAP clients use this to download the data in the DODS binary format.	info	example
  .esriCsv	Download a .csv file for ESRI's ArcGIS (line 1: names; separate date and time columns).	info	example
  .geoJson	Download longitude,latitude,otherColumns data as a GeoJSON .json file.	info	example
  .graph	View a Make A Graph web page.	info	example
  .help	View a web page with a description of tabledap.	info	example
  .html	View an OPeNDAP-style HTML Data Access Form.	info	example
  .htmlTable	View a .html web page with the data in a table. Times are ISO 8601 strings.	info	example
  .json	Download a JSON table (missing value = 'null'; times are ISO 8601 strings).	info	example
  .mat	Download a MATLAB binary file.	info	example
  .nc	Download a NetCDF binary file with COARDS/CF/THREDDS metadata.	info	example
  .ncHeader	View the header (the metadata) for the NetCDF file.	info	example
  .odvTxt	Download longitude,latitude,time,otherColumns as an ODV Generic Spreadsheet File (.txt).	info	example
  .subset	View an HTML form which simplifies picking subsets of the data.		example
  .tsv	Download a tab-separated ASCII text table (line 1: names; line 2: units; ISO 8601 times).	info	example
  .tsvp	Download a .tsv file with line 1: name (units). Times are ISO 8601 strings.	info	example
  .xhtml	View an XHTML (XML) file with the data in a table. Times are ISO 8601 strings.	info	example

  
  For example, here is a complete request to download data formatted as an HTML table:
    http://edac-dap2.northerngulfinstitute.org/erddap/tabledap/pmelTao.htmlTable?longitude,latitude,time,sea_surface_temperature&longitude>180&longitude<180.2&latitude>0&latitude<0.2&time>2007-06-01T00:00:00Z

  ArcGIS is a family of Geographical Information Systems (GIS) products from ESRI:
  ArcView, ArcEditor, and ArcInfo. To get data from ERDDAP into your ArcGIS program:

  1. In ERDDAP, save some data (which must include longitude and latitude) in an .esriCsv file
     (which will have the extension .csv) in the directory where you usually store ArcGIS data files.
     In the file:
     • Column names have been changed to be 10 characters or less
       (sometimes with A, B, C, ... at the end to make them unique).
     • longitude is renamed X. latitude is renamed Y to make them the default
       coordinate fields.
     • Missing numeric values are written as -9999.
     • Double quotes in strings are double quoted.
     • Timestamp columns are separated into date (ISO 8601) and time (am/pm) columns.
  2. In ArcMap, navigate to Tools : Add XY Data and select the file.
  3. Click on Edit to open the Spatial Reference Properties dialog box.
  4. Click on Select to select a coordinate system.
  5. Open the World folder and select WGS_1984.prj.
  6. Click a Add, Apply and OK on the Spatial Reference Properties dialog box.
  7. Click OK on the Add XY Data dialog box.
  8. Optional: save the data as a shapefile or into a geodatabase by right clicking
     on the data set and choosing Data : Export Data ...
  
  The points will be drawn as an Event theme in ArcMap.
  (These instructions are a modified version of ESRI's instructions.)

  JSONP - Requests for .json and .geoJson files may include an optional jsonp request by
  adding &.jsonp=functionName to the end of the query.
  Basically, this just tells ERDDAP to add functionName( to the beginning of the response
  and ")" to the end of the response.
  If originally there was no query, leave off the "&" in your query.

  MATLAB users can use griddap's .mat file type to download data from within MATLAB.
  Here is a one line example:

  load(urlwrite('http://edac-dap2.northerngulfinstitute.org/erddap/tabledap/pmelTao.mat?longitude,latitude,time,sea_surface_temperature&longitude>180&longitude<180.2&latitude>0&latitude<0.2&time>2007-06-01T00:00:00Z', 'test.mat'));

  The data will be in a MATLAB structure. The structure's name will be the datasetID
  (for example, pmelTao).
  The structure's internal variables will be column vectors with the same names
  as in ERDDAP (for example, use fieldnames(pmelTao)).
  You can then make a scatterplot of any two columns. For example:

  plot(pmelTao.time, pmelTao.sea_surface_temperature)

  Ocean Data View (ODV) users can download data in the ODV Generic Spreadsheet Format
  .txt file by requesting tabledap's .odvTxt fileType.
  The selected data MUST include longitude, latitude, and time variables.
  Any longitude vales are fine.
  After saving the resulting file (with the extension .txt) in your computer:

  1. Open ODV.
  2. Use File : Open.
     • Change Files of type to Data Files (*.txt *.csv *.jos *.o4x).
     • Browse to select the .txt file you created in ERDDAP and click on Open.
       The data should now be visible on a map in ODV.
  3. See ODV's Help menu for more help using ODV.

  Making an Image File with a Graph or Map of Tabular Data
  If a tabledap request URL specifies a subset of data which is suitable for making a graph or
  a map, and the fileType is an image fileType, tabledap will return an image with a graph or map.
  tabledap request URLs can include optional graphics commands which let you
  customize the graph or map.
  As with other tabledap request URLs, you can create these URLs by hand or have a computer
  program do it.
  Or, you can use the Make A Graph web pages, which simplify creating these URLs (see the
  "graph" links in the table of tabledap datasets).

  The fileType options for downloading images of graphs and maps of table data are:

  Image fileTypes	Description	Info	Example
  .kml	View a .kml file, suitable for Google Earth.	info	example
  .smallPdf	View a small .pdf image file with a graph or map.	info	example
  .pdf	View a standard, medium-sized .pdf image file with a graph or map.	info	example
  .largePdf	View a large .pdf image file with a graph or map.	info	example
  .smallPng	View a small .png image file with a graph or map.	info	example
  .png	View a standard, medium-sized .png image file with a graph or map.	info	example
  .largePng	View a large .png image file with a graph or map.	info	example

  Incompatibilities
  Some results file types have restrictions. For example, Google Earth .kml is only
  appropriate for results with longitude and latitude values. If a given request is
  incompatible with the requested file type, tabledap throws an error.
   

• query is the part of the request after the "?". It specifies the subset of data that you want to receive.
  In tabledap, it is an OPeNDAP DAP constraint query in the form: {resultsVariables}{constraints} .
  For example,
  longitude,latitude,time,sea_surface_temperature&longitude>264&latitude>0&time>=2007-08-01&time<=2007-08-08T00:00:00Z
  • resultsVariables is an optional comma-separated list of variables (for example,
    longitude,latitude,time,sea_surface_temperature).
    For each variable in resultsVariables, there will be a column in the
    results table, in the same order.
    If you don't specify any results variables, the results table will include
    columns for all of the variables in the dataset.
  • constraints is an optional &-separated list of constraints (for example,
    &longitude>264&latitude>0&time>=2007-08-01&time<=2007-08-08T00:00:00Z).
    • The constraints determine which rows of data from the original table
      table are included in the results table.
      The constraints are applied to each row of the original table.
      If all the constraints evaluate to true for a given row,
      that row is included in the results table.
      Thus, "&" can be roughly interpreted as "and".
    • If you don't specify any constraints, all rows from the original table
      will be included in the results table.
      For the fileTypes that return information about the dataset (notably,
      .das, .dds, and .html), but don't return actual data, it is fine not
      to specify constraints. For example,
      http://edac-dap2.northerngulfinstitute.org/erddap/tabledap/pmelTao.dds
      For the fileTypes that do return data, not specifying any constraints
      may result in a very large results table.
    • tabledap constraints are consistent with OPeNDAP DAP constraint queries,
      but with a few additional features.
    • Each constraint is in the form <variable><operator><value>
      (for example, latitude>45).
    • The valid operators are =, != (not equals), =~ (a regular expression test), <, <=, >, and >= .
    • tabledap extends the OPeNDAP standard to allow any operator to be used with any data type.
      (Standard OPeNDAP constraints don't allow <, <=, >, or >= to be used with string variables
      and don't allow =~ to be used with numeric variables.)
      • For String variables, the <, <=, >, and >= operators act in a case-insensitive manner.
      • For String variables, queries for ="" and !="" should work correctly for almost all
        datasets.
      • WARNING: Numeric queries involving =, !=, <=, or >= may not work as desired with
        floating point numbers. For example, a search for longitude=220.2 may
        fail if the value is stored as 220.20000000000001. This problem arises because
        floating point numbers are not represented exactly within computers.
        When ERDDAP performs these tests, it allows for minor variations and
        avoids the problem. But it is possible that some datasets will still
        have problems with these queries and return unexpected and incorrect results.
      • For numeric variables, you can test <variable>=NaN (Not-a-Number)
        and <variable>!=NaN, but not <, <=, >, or >=NaN.
        WARNING: numeric queries with =NaN and !=NaN may not work as desired
        since many data sources don't offer native support for these queries and
        ERDDAP can't always work around this problem.
        For some datasets, queries with =NaN or !=NaN may fail with an error message
        (insufficient memory or timeout) or erroneously report
        Your query produced no matching results.
      • variable=~regularExpression tests if the value from the variable on the left matches the
        regular expression on the right.
        • tabledap uses the same regular expression syntax (tutorial) as is used by Java.
        • For numeric variables, the =~ test is performed on the String representation
          of the variable's value.
        • WARNING: queries with =~ may not work as desired since many data sources
          don't offer native support for these queries and ERDDAP can't always work
          around this problem.
          ERDDAP sometimes has to get the entire dataset to do the test itself.
          For some datasets, queries with =~ may fail with an error message
          (insufficient memory or timeout) or erroneously report
          Your query produced no matching results.
          .
    • tabledap extends the OPeNDAP standard to allow constraints to be applied to any variable
      in the dataset. The constraint variables don't have to be included in the resultsVariables.
      (Standard OPeNDAP implementations usually only allow constraints to be applied
      to certain variables. The limitations vary with different implementations.)
    • Although tabledap extends the OPeNDAP constraint standard (as noted above),
      these extensions (notably "=~") sometimes aren't practical because tabledap
      may need to download lots of extra data from the source (which takes time)
      in order to test the constraint.
    • tabledap always stores date/time values as numbers (in seconds since 1970-01-01T00:00:00Z).
      Here is an example of a query which includes date/time numbers:
      http://edac-dap2.northerngulfinstitute.org/erddap/tabledap/pmelTao.htmlTable?longitude,latitude,time,sea_surface_temperature&longitude>180&longitude<180.2&latitude>0&latitude<0.2&time>1180656000
      Some fileTypes (notably, .csv, .tsv, .htmlTable, .odvTxt, and .xhtml) display
      date/time values as ISO 8601:2004 "extended" date/time strings
      (e.g., 2002-08-03T12:30:00Z).
    • tabledap extends the OPeNDAP standard to allow you to specify time values in the ISO 8601
      date/time format (YYYY-MM-DDThh:mm:ssZ, where Z is 'Z' or a ±hh:mm offset from UTC).
      If you omit Z (or the ±hh:mm offset), :ssZ, :mm:ssZ, or Thh:mm:ssZ from the ISO date/time
      that you specify, the missing fields are assumed to be 0.
      Here is an example of a query which includes ISO date/time values:
      http://edac-dap2.northerngulfinstitute.org/erddap/tabledap/pmelTao.htmlTable?longitude,latitude,time,sea_surface_temperature&longitude>180&longitude<180.2&latitude>0&latitude<0.2&time>2007-06-01T00:00:00Z .
    • For all constraints of String variables and for regex constraints of numeric variables,
      the right-hand-side value MUST be enclosed in double quotes (e.g., id="NDBC41201")
      and any internal special characters must be backslash encoded: \ into \\, " into \",
      newline into \n, and tab into \t.
    • For all constraints, the <variable><operator><value> MUST be percent encoded.
      If you submit the request via a browser, the browser will do the percent encoding
      for you. If you submit the request via a computer program, then the program
      needs to do the percent encoding.
      In practice, this can be very minimal percent encoding: all you usually
      have to do is convert % into %25, & into %26, ", into %22, + into %2B,
      space into %20 (or +), < into %3C, > into %3E, ~ into %7E, and convert
      all characters above #126 to their %HH form (where HH is the 2-digit hex value).
      Unicode characters above #255 must be UTF-8 encoded and then each byte
      must be converted to %HH form (ask a programmer for help).
  • Filters - tabledap extends the OPeNDAP standard to allow some additional procedures that
    filter the results. Currently, each of the filters takes a table as input and
    returns a table with the same columns in the same order (but the rows may be
    be altered). If you use more than one filter, they will be applied in the order
    that they appear in the request. Most of these options appear near the bottom
    of the Data Access Form and Make A Graph web page for each dataset.
    • &distinct()
      If you add &distinct() to the end of a query, ERDDAP will sort all of the
      rows in the results table (starting with the first requested variable, then using the
      second requested variable if the first variable has a tie, ...), then remove all
      non-unique rows of data.
      For example, the query stationType,stationID&distinct() will return a
      sorted list of stationIDs associated with each stationType.
      In many situations, ERDDAP can return distinct() values quickly and efficiently.
      But in some cases, ERDDAP must look through all rows of the source dataset.
      If the data set isn't local, this may be VERY slow, may return only some of the
      results (without an error), or may throw an error.
    • &orderBy("comma-separated list of variable names")
      If you add this to the end of a query, ERDDAP will sort all of the rows in the results
      table (starting with the first variable, then using the second variable if the first
      variable has a tie, ...).
      Normally, the rows of data in the response table are in the order they arrived from
      the data source.
      orderBy allows you to request that the results table be sorted in a specific way.
      For example, use the query
      stationID,time,temperature&time>2009-04-01&orderBy("stationID,time")
      to get the results sorted by stationID, then time.
      Or use the query
      stationID,time,temperature&time>2009-04-01&orderBy("time,stationID")
      to get the results sorted by time first, then stationID.
      The orderBy variables MUST be included in the list of requested variables in the
      query as well as in the orderBy constraint.
    • &orderByMax("comma-separated list of variable names")
      If you add this to the end of a query, ERDDAP will sort all of the rows in the results
      table (starting with the first variable, then using the second variable if the first
      variable has a tie, ...) and then just keeps the rows where the value of the last
      sort variable is highest (for each combination of other values).
      For example, use the query
      stationID,time,temperature&time>2009-05-21&orderBy("stationID,time")
      to get just the rows of data with each station's maximum time value (for stations
      with data from after 2009-05-21).
      (Without the time constraint, ERDDAP would have to look through all rows of the
      the dataset, which might be VERY slow.)
      The orderByMax variables MUST be included in the list of requested variables in the
      query as well as in the orderByMax constraint.
      This is the closest thing in tabledap to griddap's allowing requests for the [last]
      axis value.
    • &units("value")
      If you add &units("UDUNITS") to the end of a query, the units will be described
      via the UDUNITS standard (for example, degrees_C).
      If you add &units("UCUM") to the end of a query, the units will be described
      via the UCUM standard (for example, Cel).
      On this ERDDAP, the default for most/all datasets is UDUNITS.
      See also ERDDAP's units converter.
  • Graphics Commands - tabledap extends the OPeNDAP standard by allowing graphics commands
    in the query.
    The Make A Graph web pages simplify the creation of URLs with these graphics commands
    (see the "graph" links in the table of tabledap datasets).
    So we recommend using the Make A Graph web pages to generate URLs, and then, when
    needed, using the information here to modify the URLs for special purposes.
    These commands are optional.
    If present, they must occur after the data request part of the query.
    These commands are used by tabledap if you request an image fileType (.png or .pdf)
    and are ignored if you request a data file (e.g., .asc).
    If relevant commands are not included in your request, tabledap uses the defaults and
    tries its best to generate a reasonable graph or map.
    All of the commands are in the form &.commandName=value .
    If the value has sub-values, they are separated by the '|' character.
    The commands are:
    • &.colorBar=palette|continuous|scale|min|max|nSections
      This specifies the settings for a color bar. The sub-values are:
      • palette - All ERDDAP installations support a standard set of palettes:
        BlackBlueWhite, BlackRedWhite, BlackWhite, BlueWhiteRed, LightRainbow,
        Ocean, Rainbow, RedWhiteBlue, ReverseRainbow, Topography, WhiteBlack,
        WhiteBlueBlack, WhiteRedBlack.
        Some ERDDAP installations support additional options.
        See a Make A Graph web page for a complete list.
        The default (no value) varies based on min and max: if -1*min ~= max,
        the default is BlueWhiteRed; otherwise, the default is Rainbow.
      • continuous - must be either no value (the default), 'C' (for Continuous),
        or 'D' (for Discrete). The default is different for different datasets.
      • scale - must be either no value (the default), Linear, or Log.
        The default is different for different datasets.
      • min - The minimum value for the color bar.
        The default is different for different datasets.
      • max - The maximum value for the color bar.
        The default is different for different datasets.
      • nSections - The preferred number of sections (for Log color bars,
        this is a minimum value). The default is different for different datasets.
      If you don't specify one of the sub-values, the default for the sub-value will be used.
    • &.color=value
      This specifies the color for data lines, markers, vectors, etc. The value must
      be specified as an 0xRRGGBB value (e.g., 0xFF0000 is red, 0x00FF00 is green).
      The default is 0x000000 (black).
    • &.draw=value
      This specifies how the data will be drawn, as lines,
      linesAndMarkers, markers (default), sticks, or vectors.
    • &.font=scaleFactor
      This specifies a scale factor for the font
      (e.g., 1.5 would make the font 1.5 times as big as normal).
    • &.land=value
      This specifies whether the landmask should be drawn under or over the
      topography data.
      The default is different for different datasets (under the ERDDAP administrator's
      control via a drawLandMask in datasets.xml, or via the fallback drawLandMask
      setting in setup.xml).
      This is only relevant if the first two results variables are longitude and latitude.
      Terrestrial researchers usually prefer under (showing topography).
      Oceanographers often prefer over (showing just bathymetry).
    • &.legend=value
      This specifies whether the legend on .png images (not .pdf's) should be at the
      Bottom (default), Off, or Only (which returns only the legend).
    • &.marker=markerType|markerSize
      markerType is an integer: 0=None, 1=Plus, 2=X, 3=Dot, 4=Square,
      5=Filled Square (default), 6=Circle, 7=Filled Circle, 8=Up Triangle,
      9=Filled Up Triangle.
      markerSize is an integer from 3 to 50 (default=5)
    • &.size=width|height
      For .png images (not .pdf's), this specifies the desired size of the image, in pixels.
      This allows you to specify sizes other than the predefined sizes of .smallPng, .png, and
      .largePng.
    • &.trim=trimPixels
      For .png images (not .pdf's), this tells ERDDAP to make the image shorter by removing
      all whitespace at the bottom, except for trimPixels.
    • There is no &.vars= command. Instead, the results variables from the main part
      of the query are used.
      The meaning associated with each position varies with the &.draw value:
      • for lines: xAxis,yAxis
      • for linesAndMarkers: xAxis,yAxis,Color
      • for markers: xAxis,yAxis,Color
      • for sticks: xAxis,uComponent,vComponent
      • for vectors: xAxis,yAxis,uComponent,vComponent
      If xAxis=longitude and yAxis=latitude, you get a map; otherwise, you get a graph.
    • &.vec=value
      This specifies the data vector length (in data units) to be scaled to the size
      of the sample vector in the legend. The default varies based on the data.
    • &.xRange=min|max
      This specifies the min|max for the X axis. The default varies based on the data.
    • &.yRange=min|max
      This specifies the min|max for the Y axis. The default varies based on the data.
    
    A sample graph URL is
    http://edac-dap2.northerngulfinstitute.org/erddap/tabledap/pmelTao.png?time,sea_surface_temperature&longitude>180&longitude<180.2&latitude>0&latitude<0.2&time>2008-04-01T00:00:00Z&.draw=linesAndMarkers&.marker=1|3&.color=0xFF9900&.colorBar=|C|Linear|0|32|

    Or, if you change the fileType in the URL from .png to .graph,
    you can see a Make A Graph web page with that request loaded:
    http://edac-dap2.northerngulfinstitute.org/erddap/tabledap/pmelTao.graph?time,sea_surface_temperature&longitude>180&longitude<180.2&latitude>0&latitude<0.2&time>2008-04-01T00:00:00Z&.draw=linesAndMarkers&.marker=1|3&.color=0xFF9900&.colorBar=|C|Linear|0|32|
    That makes it easy for humans to modify an image request to make a
    similar graph or map.

    Or, if you change the fileType in the URL from .png to a data fileType
    (e.g., .htmlTable), you can download the data that was graphed:
    http://edac-dap2.northerngulfinstitute.org/erddap/tabledap/pmelTao.htmlTable?time,sea_surface_temperature&longitude>180&longitude<180.2&latitude>0&latitude<0.2&time>2008-04-01T00:00:00Z&.draw=linesAndMarkers&.marker=1|3&.color=0xFF9900&.colorBar=|C|Linear|0|32|

    A sample map URL is
    http://edac-dap2.northerngulfinstitute.org/erddap/tabledap/pmelTao.png?longitude,latitude,sea_surface_temperature,time&time>=2007-06-01T00:00:00Z&time<2007-06-02T00:00:00Z&.draw=markers&.marker=5|5&.color=0x000000&.colorBar=Rainbow|C|Linear|0|32|

    Or, if you change the fileType in the URL from .png to .graph,
    you can see a Make A Graph web page with that request loaded:
    http://edac-dap2.northerngulfinstitute.org/erddap/tabledap/pmelTao.graph?longitude,latitude,sea_surface_temperature,time&time>=2007-06-01T00:00:00Z&time<2007-06-02T00:00:00Z&.draw=markers&.marker=5|5&.color=0x000000&.colorBar=Rainbow|C|Linear|0|32|

    Or, if you change the fileType in the URL from .png to a data fileType
    (e.g., .htmlTable), you can download the data that was mapped:
    http://edac-dap2.northerngulfinstitute.org/erddap/tabledap/pmelTao.htmlTable?longitude,latitude,sea_surface_temperature,time&time>=2007-06-01T00:00:00Z&time<2007-06-02T00:00:00Z&.draw=markers&.marker=5|5&.color=0x000000&.colorBar=Rainbow|C|Linear|0|32|

• Data Model - Each tabledap dataset can be represented as a table with one
  or more rows and one or more columns of data.
  • Each column is also known as a "data variable" (or just a "variable").
    Each data variable has data of one specific type.
    The supported types are (int8, uint16, int16, int32, int64, float32, float64, and
    String of any length).
    Any cell in the table may have a no value (i.e., a missing value).
    Each data variable has a name composed of a letter (A-Z, a-z) and then 0 or more
    characters (A-Z, a-z, 0-9, _).
    Each data variable has metadata which is a set of Key=Value pairs.
  • Each dataset has global metadata which is a set of Key=Value pairs.
  • Note about metadata: each variable's metadata and the global metadata is a set of 0
    or more Key=Value pairs.
    Each Key is a String consisting of a letter (A-Z, a-z) and then 0 or more other
    characters (A-Z, a-z, 0-9, '_').
    Each Value is either one or more numbers (of one Java type), or one or more Strings
    of any length (using \n as the separator).
     
• Special Variables
  • In tabledap, a longitude variable (if present) always has the name "longitude"
    and the units "degrees_east".
  • In tabledap, a latitude variable (if present) always has the name "latitude"
    and the units "degrees_north".
  • In tabledap, an altitude variable (if present) always has the name "altitude"
    and the units "m" above sea level.
    Locations below sea level have negative altitude values.
  • In tabledap, a time variable (if present) always has the name "time" and
    the units "seconds since 1970-01-01T00:00:00Z".
    If you request data and specify a time constraint, you can specify the time as
    a number (seconds since 1970-01-01T00:00:00Z) or as a
    String value (e.g., "2002-12-25T07:00:00Z" in the UTC/GMT/Zulu time zone).
  • In tabledap, other variables can be timeStamp variables, which act like the time
    variable but have a different name.
  • Because the longitude, latitude, altitude, and time variables are specifically
    recognized, ERDDAP is aware of the spatiotemporal features of each dataset.
    This is useful when making images with maps or time-series, and when saving
    data in geo-referenced file types (e.g., .geoJson and .kml).
     
• Incompatibilities
  • Constraints - Different types of data sources support different types of constraints.
    Most data sources don't support all of the types of constraints that tabledap
    advertises. For example, most data sources can't test variable=~"RegularExpression".
    When a data source doesn't support a given type of constraint, tabledap
    gets extra data from the source, then does that constraint test itself.
    Sometimes, getting the extra data takes a lot of time or causes the remote
    server to throw an error.
  • File Types - Some results file types have restrictions.
    For example, .kml is only appropriate for results with longitude and latitude
    values. If a given request is incompatible with the requested file type,
    tabledap throws an error.
     
• Requesting Compressed Files
  ERDDAP doesn't offer results stored in compressed (e.g., .zip or .gzip) files.
  Instead, ERDDAP looks for accept-encoding in the HTTP GET request header sent
  by the client. If a supported compression type ("gzip", "x-gzip", or "deflate") is found
  in the accept-encoding list, ERDDAP includes "content-encoding" in the HTTP response
  header and compresses the data as it transmits it.
  It is up to the client program to look for "content-encoding" and decompress the data.
  Browsers and OPeNDAP clients do this by default. They request compressed data and
  decompress the returned data automatically.
  Other clients (e.g., Java programs) have to do this explicitly.