ERDDAP   Easier access to scientific data

Brought to you by NOAA NMFS SFSC ERD

ERDDAP is an all-open source, all-Java (servlet), web application that runs in a web application server (for example, Tomcat).
This web page is mostly for people ("ERDDAP administrators") who want to set up their own ERDDAP installation at their own web site.

How To Do the Initial Setup of ERDDAP on Your Server

1. Type "java -version" from your server's command line to make sure you have Java version 1.5 update 11 (or higher) or version 1.6 update 1 (or higher) installed.
2. Set up Tomcat (or some other application server) on your server.
   Below, the Tomcat directory will be referred to as <tomcat> .
   • Add "export JAVA_HOME=YourJavaDirectory" to the top of <tomcat>/bin/startup.sh .
   • Add "export JAVA_OPTS='-Djava.awt.headless=true -Xmx1500M' " to the top of <tomcat>/bin/startup.sh .
     If there will be many simultaneous requests, ERDDAP can run out of memory.
     So the more memory in the server the better: 4+ GB is really good (extra is used for swap space, which is useful), 2 GB is okay, less is not recommended.
     Even with abundant physical memory, Tomcat/Java have problems if you try to set -Xmx much above 1500M.
     If your server has less than 2GB of memory, reduce the -Xmx value (in 'M'egaBytes) to 1/2 of the physical memory.
   • Optional fonts for images: Download BitstreamVeraSans.zip and unzip it into <JAVA_HOME>/jre/lib/fonts so Java can find the fonts.
     This isn't essential, but we prefer these free fonts to the standard Linux/Java fonts.
   • Troubles with the Tomcat installation?
     See the Tomcat web site or search the web for help,
     but please let us know the problems you had and the solutions you found.
3. If Tomcat is running in Apache, you need to modify the /etc/httpd/conf/httpd.conf file to allow HTTP traffic to/from ERDDAP:
   To the "VirtualHost" tag, add the lines:
      ProxyPass /erddap <YourServer'sURL>:8080/erddap
      ProxyPassReverse /erddap <YourServer'sURL>:8080/erddap
4. Download erddapContent.zip and unzip it into <tomcat>, creating <tomcat>/content/erddap .
   • Read the comments in <tomcat>/content/erddap/setup.xml and make the requested changes.
   • Read the comments in Working with the datasets.xml File,
     then modify the XML in <tomcat>/content/erddap/datasets.xml to describe the datasets you want ERDDAP to serve.
   After you edit the .xml files, it is a good idea to verify that the result is well-formed XML by pasting the XML text into an XML checker like RUWF.
5. Download erddap.war into <tomcat>/webapps . Restart Tomcat.
   Or, if you use the Tomcat Web Application Manager:
   * Download erddap.war into a temporary directory on your computer.
   * Use "Select WAR file to upload" to pick the erddap.war file.
   * Click on "Deploy".
   The .war file is big because it contains high resolution coastline, boundary, and elevation data needed to create maps.
6. Hopefully, you can now use a browser to view <YourServer'sURL>/erddap/ and see ERDDAP immediately.
   ERDDAP starts up immediately, but without any datasets loaded. Datasets are loaded in a background thread and so become available one-by-one.

How To Do an Update of ERDDAP on Your Server

1. Download erddapContent.zip and unzip it into a temporary directory.
   • If you made changes to your previous copy of messages.xml, make the same changes to the new messages.xml in the temporary directory.
   • Move messages.xml from the temporary directory into <tomcat>/content/erddap .
   • Keep using your current setup.xml and datasets.xml.
2. Make the changes recommended in List of Changes below.
3. Download erddap.war into a temporary directory.
4. In Tomcat Manager, "Undeploy" ERDDAP.
5. In Tomcat Manager, "Deploy" the erddap.war file.

Things You Need To Know

• log.txt - When you are first installing ERDDAP, it is very useful to see diagnostic messages.
  ERDDAP always puts diagnostic messages in the log.txt file in <bigParentDirectory> as specified in setup.xml.
  You can control the level of messages by setting <logLevel> (info or all) in setup.xml.
   
• Viewing Diagnostic Messages - When first installing ERDDAP, we recommend that you set <displayDiagnosticInfo> to true in setup.xml so that diagnostic messages are also displayed at the bottom of ERDDAP web pages.
  Then, if you 1) restart ERDDAP, 2) request a web page (like the ERDDAP home page) to start ERDDAP and the dataset loader thread, 3) wait 20(?) seconds, 4) request the home page again, you can view the diagnostic messages resulting from ERDDAP's attempts to load the datasets.
   
• Adding/Changing Datasets - ERDDAP usually rereads datasets.xml every <loadDatasetsMinMinutes> (specified in setup.xml). So you can make changes to datasets.xml any time, even while ERDDAP is running. A new dataset will be detected soon, usually within <loadDatasetsMinMinutes>. A changed dataset will be reloaded when it is <reloadEveryNMinutes> old (as specified in datasets.xml).
   
• Force Dataset Reloading - If you want to force ERDDAP to reload a dataset as soon as possible (before the dataset's <reloadEveryNMinutes> would cause it to be reloaded), put a file in <bigParentDirectory>/flag (as specified in setup.xml) that has the same name as the datasetID (as specified in datasets.xml). The contents of the flag file are irrelevant. The next time ERDDAP considers whether to reload that dataset, ERDDAP will: see the flag file, delete it, and reload the dataset.
   
• Force Dataset Removal - If a dataset is already failing to instantiate and so is already not available in ERDDAP, just remove the dataset's description from the datasets.xml file.

  If you want to force ERDDAP to remove an active dataset as soon as possible, make its description in datasets.xml invalid (e.g., by entering an incorrect sourceURL) and put a flag file in <bigParentDirectory>/flag (as specified in setup.xml) that has the same name as the datasetID (as specified in datasets.xml). The contents of the flag file are irrelevant. The next time ERDDAP considers whether to reload that dataset (usually every <loadDatasetsMinMinutes>), ERDDAP will: see the flag file, delete it, try to reload the dataset, fail, and remove the dataset from the list of active datasets.

• Cached Dataset Information - A few types of datasets (notably EDDGridFromXxxFiles and EDDTableFromXxxFiles) cache (store) some information about the dataset that is reused the next time the dataset is loaded. This greatly speeds the reloading process. It shouldn't ever be necessary to delete these cache files because the datasets verify the cache's information when they reload. But if you ever do need to delete these files (to force re-caching), they are stored in <bigParentDirectory>/datasetInfo.
   
• Heavy Loads - With heavy use, ERDDAP will be constrained (from most to least likely) by:
  1. Bandwidth - Unless you have a very high bandwidth internet connection, ERDDAP's responses will be constrained by how fast ERDDAP can get data from the data sources and how fast ERDDAP can return data to the clients. The only solution is to get a faster internet connection.
  2. Memory - If there will be many simultaneous requests, ERDDAP can run out of memory.
     So the more memory in the server the better: 4+ GB is really good, 2 GB is okay, less is not recommended.
     See the -Xmx setting for ERDDAP/Tomcat above.
     Thus the current absolute maximum setting of approximately -Xmx1500M is probably the biggest unfixable limitation.
     In setup.xml, see the <partialRequestMaxBytes> and <partialRequestMaxCells> .
  3. Too many files in the cache - ERDDAP caches all graphs, but only caches the data for certain types of data requests.
     It is possible for the cache to have a large number of files temporarily.
     This will slow down requests to see if a file is in the cache (really!).
     <cacheMinutes> in setup.xml lets you set how long a file can be in the cache before it is deleted.
     Setting a smaller number would minimize this problem.
  4. CPU - Making graphs is the only thing that takes much CPU time (roughly 1 second per graph).
     So if there were many simultaneous unique requests for graphs, there could be a CPU limitation.
     On a multi-core server, it would take a lot of requests before this became a problem.
      
• Email Notification of Updates - If you want to receive an email whenever a new version of ERDDAP is available, send an email to bob dot simons at noaa dot gov requesting this.
   

Things You Don't Need To Know

• Setting Up a Second ERDDAP for Testing/Development
  If you want to do this, there are two approaches:
  1. (Best) Install Tomcat and ERDDAP on a computer other than the computer that has your public ERDDAP.
     If you use your personal computer,
     • Do the installation one step at a time. Get Tomcat up and running first.
     • When Tomcat is running, the Tomcat Manager should be at http://127.0.0.1:8080/manager/html/
     • In ERDDAP's setup.xml, set baseUrl to http://127.0.0.1:8080
     • ERDDAP will be at http://127.0.0.1:8080/erddap
  2. (Second Best) Install another Tomcat on the same computer as your public ERDDAP.
     1. Set the new Tomcat's port to 8081 (see these directions, but use port 8081 instead of 8080 or 80).
     2. Install ERDDAP in the new Tomcat.
        In the new ERDDAP's setup.xml, set baseUrl to http://www.your.site.name:8081
        You can then access the new ERDDAP via http://www.your.site.name:8081/erddap .
         
• partialResults Exception - In unusual circumstances, a user may get an error message like "java.lang.Exception: GridDataAccessor.increment: partialResults[0] was not as expected. The other primitiveArray has a different value." The explanation is: For each EDDGrid dataset, ERDDAP keeps the axis variable values in memory. They are used, for example, to convert requested axis values that use the "()" format into index numbers. For example, if the axis values are "10, 15, 20, 25", a request for (20) will be interpreted as a request for index #2 (0-based indices). When ERDDAP gets a request for data and gets the data from the source, it verifies that the axis values that it got from the source match the axis values in memory. Normally, they do. But sometimes the data source has changed in a significant way: for example, index values from the beginning of the axis variable may have been removed (e.g., "10, 15, 20, 25" may have become "20, 25, 30"). If that happens, it is clear that ERDDAP's interpretation of the request (e.g., "(20)" is index #2) is now wrong. So ERDDAP throws an exception and marks the dataset as needing to be reloaded. ERDDAP will update the dataset soon (usually within 15 minutes).
   

Programmer's Guide

• Source Code - The source code for ERDDAP is in the erddap.war file.
  ERDDAP has a very liberal, open-source license, so you can use the code for any purpose.
   
• Use the Code for Other Projects
  While you are welcome to use parts of the ERDDAP code for other projects, be warned that the code can and will change.
  We don't promise to support other uses of our code.
  Our main goal is to make a web application that people can download and use, as is, to distribute data.

  For many situations where you might be tempted to use parts of ERDDAP in your project,
  we think you will find it much easier to install and use ERDDAP as is,
  and then write other services which use ERDDAP's services.
  You can set up your own ERDDAP installation crudely in an hour or two.
  You can set up your own ERDDAP installation in a polished way in a few days
  (depending on the number and complexity of your datasets).
  But hacking out parts of ERDDAP for your own project is likely to take weeks (and months to catch subtleties).
  We (obviously) think there are many benefits to using ERDDAP as is and making your ERDDAP installation publicly accessible.
  However, in some circumstances, you might not want to make your ERDDAP installation publicly accessible.
  Then, your service can access and use your private ERDDAP and your clients needn't know about ERDDAP.

  Half Way - Or, there is another approach which you may find useful
  which is half way between delving into ERDDAP's code and using ERDDAP as a stand-alone web service:
  In the dataset.EDD class, there is a static method which lets you make an instance of a dataset (based on the specification in datasets.xml): oneFromDatasetXml(String tDatasetID)
  It returns an instance of an EDDTable or EDDGrid dataset.
  Given than instance, you can call
  makeNewFileForDapQuery(String userDapQuery, String dir, String fileName, String fileTypeName)
  to tell the instance to make a data file, of a specific fileType, with the results from a user query.
  Thus, this is a simple way to use ERDDAP's methods to request data and get a file in response,
  just as a client would use the ERDDAP web application.
  But this approach works within your Java program and bypasses the need for an application server like Tomcat.
  We use this approach for many of the unit tests of EDDTable and EDDGrid subclasses,
  so you can see examples of this in the source code for all of those classes.

• Development Environment
  • Directory Structure
    • If you are installing ERDDAP in a Tomcat (whether or not you will actually use it that way),
      follow the instruction above.
    • If you aren't installing ERDDAP in a Tomcat, you still need to make a Tomcat-like directory structure,
      so that ERDDAP can find the setup files in [tomcat]/content/erddap .
      • Make a directory somewhere called "tomcat" (it can be something else, but this is easier to explain).
      • As indicated above, unzip erddapContent.zip into <tomcat>, creating <tomcat>/content/erddap .
        Follow the instructions above to modify setup.xml and datasets.xml.
      • Make a [tomcat]/webapps/erddap dirctory.
      • .war files are just .zip files that follow a few additional conventions.
        So you can use an unzip program to unzip erddap.war into [tomcat]/webapps/erddap .
        That has all of ERDDAP's .java classes and many other files.
  • Our development environment is just a programmer's editor (EditPlus -- not an endorsement since that isn't allowed, just a statement of fact).
  • We use a batch file which deletes all of the .class files in the source tree.
  • We currently use javac 1.5 to compile gov.noaa.pfel.coastwatch.TestAll and java 1.5 to run it.
    • When we run javac or java, the current directory is [tomcat]/webapps/erddap/WEB-INF .
      (Actually, for us, for historical reasons, it is "/cwexperimental/", instead of "/erddap/".)
    • Our javac and java classpath (including some unnecessary items) is currently
      [tomcat]\common\lib\servlet-api.jar;[tomcat]\common\lib\postgresql-8.3-603.jdbc3.jar;lib\slf4j-jdk14.jar;lib\netcdf-latest.jar;classes;lib\itext-1.3.1.jar;lib\mail.jar;lib\activation.jar;lib\commons-httpclient-3.0.1.jar;lib\commons-codec-1.3.jar;lib\commons-logging-1.1.jar;lib\saaj.jar;lib\axis.jar;lib\commons-discovery-0.2.jar;lib/jaxrpc.jar;lib/wsdl4j-1.5.1.jar;lib\janino.jar;lib\joda-time-1.4.jar
    • So your javac command line will be something like
      javac -cp (classpath above) classes/gov/noaa/pfel/coastwatch/TestAll.java
    • And your java command line will be something like
      java -cp (classpath above) -Xmx1500M classes/gov/noaa/pfel/coastwatch/TestAll
    • If TestAll compiles, everything ERDDAP needs has been compiled.
      Lots of classes are compiled that aren't needed for ERDDAP.
      If compiling TestAll succeeds but doesn't compile some class, that class isn't needed.
      (There are some unfinished/unused classes.)
  • We use some 3rd party source code instead of .jar files (notably for SSHTools and Dods)
    and have modified them slightly to avoid problems compiling with Java 1.5.
    We have often made other slight modifications (notably to Dods) for other reasons.
  • Most classes have test methods. We run lots of tests via TestAll.
    Unfortunately, many of the tests are specific to our set up. (Sorry.)
     
• Important Classes - If you want to look at the source code and try to figure out how ERDDAP works, please do.
  • The code has JavaDoc comments, but the JavaDocs haven't been generated. Feel free to generate them.
  • The most important classes (including the ones mentioned below) are within gov/noaa/pfel/erddap.
  • The Erddap class has the highest level methods. It extends HttpServlet.
  • Erddap passes requests to instances of subclasses of dataset.EDDGrid or dataset.EDDTable, which represent individual datasets.
  • EDDGrid and EDDTable subclasses parse the request, get data from subclass-specific methods, then format the data for the response.
  • EDDGrid subclasses push data into dataset.GridDataAccessor (the internal data container for gridded data).
  • EDDTable subclasses push data into dataset.TableWriter subclasses, which write data to a specific file type on-the-fly.
     
• Code Contributions - If you have written some code which would be a nice addition to ERDDAP,
  please contact bob dot simons at noaa dot gov. We'll work out the details.
  The two situations that are most likely are:
  1. You want to write another subclass of EDDGrid or EDDTable to handle another data source type.
     If so, we recommend that you find the closest existing subclass and use that code as a starting point.
  2. You want to write another saveAsFileType method.
     If so, we recommend that you find the closest existing saveAsFileType method in EDDGrid or EDDTable and use that code as a starting point.
  Both of these situations have the advantage that the code you write is self-contained.
  You won't need to know all the details of ERDDAP's internals.
  And it will be easy for us to incorporate your code in ERDDAP.
  Note that if you do submit code, the license will need to be as liberal as the ERDDAP license
  (although you can hold the copyright to your code and we'll list your contribution in the credits).
  Yes, we are considering using SourceForge or some similar system, but haven't set it up yet.
   

List of Changes

• Changes in version 1.12 (released 2008-10-31)
  • EDDTableFromSOS once again works with NDBC SOS and works with the new NOS SOS.
  • EDDTableFromBMDE now requires ERDDAP admin to specify dataVariables.
  • EDDGrid no longer requires that lat and lon be evenly spaced for .transparentPng or .kml. Thanks to Todd Spindler.
  • A few small changes.
• Changes in version 1.10 (released 2008-10-14)
  • New "colorBar" metadata for data variables in datasets.xml defines the default color bar settings for graphs and maps. See more information. This is important because it greatly improves the appearance of the default graphs and maps produced by Make A Graph and because the default graphs and maps now have a consistent color bar even when the client changes the requested time or geographic range. Also, this was necessary for WMS.
  • ERDDAP now serves most grid data via a WMS service. This is important because it shows that, in addition to getting data from many types of data servers, ERDDAP can distribute data via different protocols (DAP, WMS, ... more in future). See the client documentation. Or the documentation for administrators. Or try it out.
  • New support for longitude values >180 in .kml files.
  • New cdm_data_type: Other .
  • ERDDAP now supports "boolean" source dataType. See more information This will become useful for the future EDDTableFromDatabase.
  • New EDDTableFromBMDE supports DiGIR/BMDE data sources.
  • EDVGridAxis now allows descending sorted values. The pmelOscar datasets needed this.
  • ERDDAP now returns HTTP errors (e.g., "404 for resource/page not found") in more situations, instead of HTML pages with error messages.
  • Lots of changes/additions to the ERDDAP documentation.
  • Lots of small changes.
  • Some bug fixes.
  • Things ERDDAP administrators should do to upgrade to this version:
    • In datasets.xml, for any EDDTableFromSOS datasets, change "observedProperty" metadata to "sourceObservedProperty".
    • The rules for an axisVariable or dataVariable's destinationName are now stricter.
      You need to check that your variable names are valid.
      Either check them by hand, or run ERDDAP and look at the error messages in the report that is emailed to the administrator.
    • In datasets.xml, if you want a grid data variable to be accessible via WMS, you need to add colorBar metadata. At least, for example,
        <att name="colorBarMinimum" type="double">0</att>
        <att name="colorBarMaximum" type="double">32</att>
      See more information.
    • Add the following to your setup.xml (but customize with your information):

      
      <!-- drawLand specifies the default Make A Graph setting for whether the 
      landmask should be drawn "over" (the default) or "under" surface data on maps. 
      "over" is recommended for primarily oceanographic data 
      (so that grid data over land is obscured by the landmask).
      "under" is recommended for all other data.
      -->
      <drawLand>over</drawLand>  
      
      <!-- Information about the ERDDAP administrator is used for the SOS and WMS servers. 
      You MUST CHANGE these to describe your installation. 
      -->
      <adminInstitution>NOAA Environmental Research Division</adminInstitution>
      <adminIndividualName>Your Name</adminIndividualName>
      <adminPosition>Webmaster</adminPosition>
      <adminPhone>your-phone-number</adminPhone>
      <adminAddress>1352 Lighthouse Ave.</adminAddress>
      <adminCity>Pacific Grove</adminCity>
      <adminStateOrProvince>CA</adminStateOrProvince>
      <adminPostalCode>93950</adminPostalCode>
      <adminCountry>USA</adminCountry>
      <adminEmail>yourName@yourSite</adminEmail>
      
      <!-- Information about the ERDDAP administrator is used for ERDDAP's SOS server. 
      You MUST CHANGE these to describe your installation. 
      -->
      <sosTitle>NOAA Environmental Research Division SOS</sosTitle>
      <sosAbstract>NOAA Environmental Research Division's ERDDAP makes data from multiple sources available via the SOS protocol.</sosAbstract>
      <sosKeywords>Weather, Ocean Currents, Temperature, Salinity</sosKeywords>
      <sosAccessConstraints>NONE</sosAccessConstraints>
      <sosFees>NONE</sosFees>
      
      <!-- Information about the ERDDAP administrator is used for ERDDAP's WMS server. 
      You MUST CHANGE these to describe your installation. 
      -->
      <wmsTitle>NOAA Environmental Research Division WMS</wmsTitle>
      <wmsAbstract>NOAA Environmental Research Division's ERDDAP makes data from multiple sources available via the WMS protocol.</wmsAbstract>
      <wmsKeywords>Weather, Ocean Currents, Temperature, Salinity</wmsKeywords> 
      <wmsAccessConstraints>NONE</wmsAccessConstraints>
      <wmsFees>NONE</wmsFees>
      <!-- For the wms examples, pick one of your grid datasets that has longitude and latitude axes.
      The sample variable must be a variable in the sample grid dataset.
      The bounding box values are minx,miny,maxx,maxy.
      -->
      <wmsSampleDatasetID>erdBAssta5day</wmsSampleDatasetID>
      <wmsSampleVariable>sst</wmsSampleVariable>
      <wmsSampleBBox>0,-75,180,75</wmsSampleBBox>
      
      

• Changes in version 1.08 (released 2008-07-13)
  • A new web service in ERDDAP, generateDatasetsXml, assists ERDDAP administrators by creating a rough draft of the XML needed to describe a dataset in datasets.xml
  • Some changes/bug fixes related to allowing griddap to be seen by netcdf-java as an opendap server, including: global metadata is now labeled "NC_GLOBAL" (instead of "GLOBAL").
  • The EDDGrid and EDDTable Data Access Forms now utilize query information in the URL. So, for example, if a user goes from a Make A Graph form to a Data Access Form, the constraints are now properly transferred.
  • tabledap's Make A Graph now allows constraints on String variables.
  • EDDTable's Make A Graph now allows NaN constraints. Thanks to Steve Hankin.
  • Bug fix: EDDTable saveAsImage didn't properly recognize the .colorbar min and max values. Thanks to Steve Hankin
  • Many improvements to setupDatasetsXml. Thanks to Ellyn Montgomery.
  • Griddap requests now allow ()-style requests slighly outside of the actual axis range. This is appropriate since ()-values are rounded to the nearest actual value. Thanks to Cindy Bessey
  • I made the FloatArray and DoubleArray test of isEvenlySpaced more sophisticated. It will always be imperfect (because the test would need to be customized for each dataset), but it should be better. Thanks to Ellyn Montgomery.
  • I moved setup.html and setupDatasetsXml.html erddap's /download directory and hard coded all links to them. Now, I can make changes and update the setup information immediately.
  • Many small changes. A few small bug fixes.
  • Things ERDDAP administrators should do to upgrade to this version:
    • Move <theShortDescriptionHtml> from your messages.xml to your setup.xml. It specifies the text that appears in the middle of the left side of the ERDDAP home page.
      Also, add <h1>ERDDAP</h1> (or some other headline) to the top of it.
      Or, copy <theShortDescriptionHtml> in the new setup.xml (from the new erddapContent.zip) into your setup.xml.
• Changes in version 1.06 (released 2008-06-20)
  • New support for IOOS DIF SOS data sources.
  • Many small changes. A few small bug fixes.
• Changes in version 1.04 (released 2008-06-10)
  • New Slide Sorter feature.
  • New Google Gadgets page and examples.
  • Bug fix in EDDGrid.saveAsNc for variable with scale and addOffset.
• Changes in version 1.02 (released 2008-05-26)
  • New EDDGridSideBySide allows for different axisVariables[0] sourceValues.
  • All of the currents and winds datasets were merged into EDDGridSideBySide datasets.
  • Images from image requests are now cached for 1 hour.
• Changes in version 1.00 (released 2008-05-06)
  • Make A Graph web pages and graphics commands in URLs.
  • Support for flag files to force reloading a dataset.
  • New dataset type: EDDTableFrom4DFiles (the first subclass of EDDTableFromFiles).

Credits

• ERDDAP is a Java Servlet program. At ERD, it runs inside of a Tomcat application server (license: Apache), with an Apache web server (license: Apache), running on a computer using the Red Hat Linux operating system (license: GPL).
• The data sets are from various sources. See the metadata (in particular the "institution") for each dataset.
• Data from OPeNDAP servers are read with Java DAP 1.1.7 (license: LGPL).
• NetCDF files (.nc) and GMT-style NetCDF files (.grd) are read and written with code in the NetCDF Java Library (license: LGPL) from Unidata.
• The NetCDF Java Library requires a logger facade (we chose slf4j-jdk14.jar) from the Simple Logging Facade for Java project (license: MIT/X).
• The NetCDF Java Library uses code from several .jar files from the Apache project: commons-httpclient-3.0.1, commons-codec-1.3, and commons-logging-1.1 (license: Apache).
• The NetCDF Java Library uses XML processing code from JDOM (license: Apache).
• The graphs and maps are created on-the-fly with a modified version of NOAA's SGT version 3 (a Java-based Scientific Graphics Toolkit written by Donald Denbo at NOAA PMEL) (license: copyrighted open source).
• Big, HTML tooltips on ERDDAP's HTML pages are created with Walter Zorn's wz_tooltip.js (license: LGPL).
• The drag and drop feature of the Slide Sorter is created with Walter Zorn's wz_dragdrop.js (license: LGPL).
• The .pdf files are created with iText version 1.3.1 (license: Mozilla), a free Java-PDF library by Bruno Lowagie and Paulo Soares.
• The shoreline data for the landmask is from GSHHS - A Global Self-consistent, Hierarchical, High-resolution Shoreline Database (license: public domain) from NOAA NGDC and created by Paul Wessel and Walter Smith.
• The political boundary data is from the pscoast program in GMT, which uses data from the CIA World Data Bank II (license: public domain).
• The bathymetry data is the ETOPO2v2g Global 2-Minute Gridded Elevation Data Set (license: public domain), which is distributed for free by NOAA NGDC.
• Emails are sent using code in activation.jar and mail.jar from Sun's JavaMail API (license: copyrighted open source).
• ERDDAP uses code from the CoastWatch Browser project from the NOAA CoastWatch West Coast Regional Node (license: copyrighted open source). That project was initiatiated and managed by Dave Foley, the Coordinator of the NOAA CoastWatch West Coast Regional Node. The CoastWatch Browser code was written by Bob Simons.
• The ERDDAP distribution includes code from the J2SSH project which is distributed by SSHTools (version 0.2.2, which is old (2003) but the most recent available) (license: Apache). It is based on j2ssh/examples/SftpConnect.java (License: LGPL) which is Copyright (C) 2002 Lee David Painter (lee@sshtools.com).
• The ERDDAP distribution includes the Apache Jakarta Commons Logging .jar file (version 1.0.4) (license: Apache).

License

ERDDAP, Copyright 2008, NOAA.

PERMISSION TO USE, COPY, MODIFY, AND DISTRIBUTE THIS SOFTWARE AND ITS DOCUMENTATION FOR ANY PURPOSE AND WITHOUT FEE IS HEREBY GRANTED, PROVIDED THAT THE ABOVE COPYRIGHT NOTICE APPEAR IN ALL COPIES, THAT BOTH THE COPYRIGHT NOTICE AND THIS PERMISSION NOTICE APPEAR IN SUPPORTING DOCUMENTATION, AND THAT REDISTRIBUTIONS OF MODIFIED FORMS OF THE SOURCE OR BINARY CODE CARRY PROMINENT NOTICES STATING THAT THE ORIGINAL CODE WAS CHANGED AND THE DATE OF THE CHANGE. THIS SOFTWARE IS PROVIDED "AS IS" WITHOUT EXPRESS OR IMPLIED WARRANTY.

Disclaimers

DISCLAIMER FOR EXTERNAL LINKS
The appearance of external links on this World Wide Web site does not constitute endorsement by the Department of Commerce/National Oceanic and Atmospheric Administration of external Web sites or the information, products or services contained therein. For other than authorized activities, the Department of Commerce/NOAA does not exercise any editorial control over the information you may find at these locations. These links are provided consistent with the stated purpose of this Department of Commerce/NOAA Web site.

DISCLAIMER OF LIABILITY
Neither the data providers, ERD, CoastWatch, NOAA, nor the United States Government, nor any of their employees or contractors, makes any warranty, express or implied, including warranties of merchantability and fitness for a particular purpose, or assumes any legal liability for the accuracy, completeness, or usefulness, of any information at this site.

Contact