Skip to content
Gridlad

GWSDAT and This Site: Two Free Ways to Map Groundwater Data

Both of these are free, both draw contoured groundwater figures, and they are not the same tool. GWSDAT is a spatiotemporal analysis package with a plume-behaviour model in it; this is a figure-making tool for a set of standard monitoring maps. This page is about which question each of them answers, written by one of the two — which is a reason to read it carefully, and the reason the rules it is written under are printed on it.

The rules this page is written under

This comparison is published by one of the two things being compared, which is a reason to read it carefully. So the constraints are stated rather than implied, and each one is enforced by a test rather than by good intentions.

  1. What GWSDAT is for and is good at comes first, in its own terms, before anything about this site.
  2. Nothing about their software is described as a fault. Every difference below is a consequence of a design decision, and each one is stated as such.
  3. Every factual claim about GWSDAT is narrow, is sourced to something you can open, and is dated — because their software changes and this page will not notice.
  4. No claim about speed, ease or quality appears anywhere on this page in either direction. Nobody has measured any of it.
  5. What GWSDAT does that this site does not is a list, near the top, and it is not hedged.

What GWSDAT is, and what it is good at

Made by
Shell Global Solutions, released as open source
Licence
GPL-3
Version described here
3.3.0, published on CRAN on 6 February 2026

GWSDAT is a decision-support tool for the analysis and reporting of groundwater monitoring data, built at Shell Global Solutions and released as open source under GPL-3. It is an R package with a Shiny interface: you can install it and run it on your own machine, or open the hosted instance in a browser. It has been developed and maintained for over a decade, it is described in the peer-reviewed literature, and it is one of the packages ITRC writes up in its groundwater statistics guidance.

The thing at the centre of it is a spatiotemporal smoother: rather than contouring one round in isolation, it fits a model across space and time together, so that the behaviour of a plume over years informs what is drawn at any one date. That is a real statistical idea with published work behind it, and it is not something this site does or is trying to do. On top of it sit the things a monitoring programme actually asks about a plume — trend analysis per well, and plume diagnostics such as mass and average concentration tracked through time — with reporting output built in.

It also reads a site basemap from a GIS shapefile, animates a record through time, and handles NAPL thickness as well as solute concentration and groundwater elevation. If your question is about how a plume is behaving over a monitoring record rather than what one round looks like on a sheet, GWSDAT is answering your question and this site is not.

What GWSDAT does that this site does not

  • Spatiotemporal modelling. GWSDAT fits a smoother across space and time together; every map here is fitted to one round in isolation, with no memory of the round before it.
  • Plume diagnostics. Tracking plume mass and average concentration through a monitoring record is a named output of theirs and is not built here at all.
  • NAPL thickness. It is carried as a first-class quantity in their data model. Nothing here knows what NAPL is.
  • A real basemap from a shapefile. They read one; here a background is an image you supply and georeference by clicking two points, and there is no shapefile reader.
  • A published record. Two peer-reviewed papers, a decade of maintenance, a write-up in ITRC guidance and a named institutional author. This site has an automated test suite and a page listing what it checks, which is a different kind of evidence and a much younger one.
  • Animation through time. Playing a record back is theirs; there is no time playback here.
  • It runs offline as a desktop application once installed, with no page to load.

The checkable bits

Version 3.3.0, published 6 February 2026, licensed GPL-3.
Source: The GWSDAT package page on CRAN (cran.r-project.org/package=GWSDAT).
Maintained by Wayne Jones at Shell, and described on CRAN as a Shiny application for analysing groundwater monitoring data.
Source: The same CRAN package page.
Runs as an R package launched locally, is deployable on a Shiny server, and has a hosted instance published on shinyapps.io.
Source: The project’s own repository README (github.com/WayneGitShell/GWSDAT).
Written up by ITRC in the software appendix of its Groundwater Statistics and Monitoring Compliance guidance.
Source: ITRC’s guidance document, Appendix D, section D.7.
Described in the peer-reviewed literature, including a 2014 paper in Environmental Modelling & Software and a 2022 paper in Groundwater Monitoring & Remediation.
Source: Jones et al. (2014), Environmental Modelling & Software 55:242–249; Jones et al. (2022), Groundwater Monitoring & Remediation 42:14–22.
Imports a site basemap in GIS shapefile format.
Source: The package description on CRAN.

Every fact above was read from those sources on the date at the foot of this page, and software changes. Before you weigh any of it, open the sources — they are named specifically so you can. If something here is out of date, the thing that is wrong is this page.

Where the two differ

Where the computation happens

GWSDAT
GWSDAT is an R application, so the arithmetic runs in an R process. Two ways to get one: install the package and launch it on your own machine, where the process is yours and nothing goes anywhere; or open the hosted instance, which is a Shiny deployment on a public hosting service, where the file you open is processed by R on that server. That is not a property of GWSDAT, it is what a hosted Shiny app is — and the local install is the answer they already ship for anybody who needs one.
Gridlad
Everything here runs in the browser tab. The parser, the interpolation, the contouring and the export are code that arrived with the page, there is no endpoint to send a file to, and the content security policy restricts network connections to this site’s own origin. Load the page, disconnect the network, and keep working.
Who each suits
If you can install R, the local GWSDAT install and this site are equally private, and this axis is not a reason to choose between them. The difference bites on a laptop where you cannot install software: their route is then the hosted instance and this one is a browser tab, and only one of those keeps a litigation-hold file on your own machine. It bites the other way too — their local install is a real desktop tool that keeps working with no page to load, and there is no equivalent here.

What you have to give it before anything is drawn

GWSDAT
GWSDAT works from a structured input. There are two tables — one of well coordinates, one of the monitoring record — prepared in its own Excel template, with groundwater level and NAPL thickness carried as named rows beside the solute results. That shape is a design decision and it pays for itself. A model fitted across space and time has to know that these six rows are one well on six dates, and a template that settles it up front is worth more to the model than a file that was convenient to export.
Gridlad
Here you drop the file you already have. Wide or long, comma, tab, semicolon or pipe, a pasted block or an .xlsx, with the separator, the decimal mark, the encoding and the column roles all inferred and shown to you in a table you can correct one click at a time. A top-of-casing elevation and a depth to water are subtracted for you, with the subtraction printed in your own header spellings.
Who each suits
These suit different jobs rather than different skill levels. If the same site comes round every quarter and its data already lives in a shape somebody maintains, preparing a template once is not a cost worth avoiding, and it buys the model. If the file changes shape every time because it came from a different laboratory or a different colleague, inference is worth more than structure.

What each one is actually for

GWSDAT
GWSDAT is built around modelling how a plume behaves through time. The spatiotemporal smoother, the plume diagnostics, the animation of a record, the trend analysis per well: all of it is aimed at the question of what a monitoring record shows over years. Contoured figures come out of that model as one of its outputs.
Gridlad
This is a figure-making tool. Eight named maps — a potentiometric surface, a plume, a well location map, a generic contour map, a change between two rounds, Stiff diagrams placed at their wells, a Mann-Kendall arrow per well, and the gradient worked as a number — each drawn on an 11×17 sheet with a title block, a scale bar, a north arrow and the interpolation method printed on the figure, and each exporting to SVG, PNG, DXF and GeoJSON.
Who each suits
This is the axis where the two least overlap, and it is why using both is a sensible answer rather than a diplomatic one. A question about plume behaviour over a decade is theirs. A numbered figure due in a report on Friday, in the same style as the last eleven, is this one. Neither is a substitute for the other and the overlap — a contoured picture of one round — is the shallow end of both.

When to go and use GWSDAT instead

  • Your question is about how the plume has behaved over the monitoring record, rather than what this round looks like on a sheet.
  • You want plume mass or average concentration tracked through time.
  • Your site data includes NAPL thickness and you need it treated as data rather than as a column nobody asked about.
  • You have a shapefile basemap and want it read directly.
  • You need to hand a reviewer a method with peer-reviewed papers and an ITRC write-up behind it. That is a real answer to a real question and this site cannot give it.
  • You are comfortable in R, in which case the local install costs you one command and removes the hosting question entirely.

Using both, which is the arrangement that makes sense

These fit together in an obvious order, and the order is not a diplomatic construction. The analysis question — is this plume shrinking, what does the record show over eight years, how much mass is left — is answered by a model fitted across the whole record, and that is what GWSDAT is. The figure question — the numbered potentiometric surface for this quarter’s report, in the same style as the last eleven, with the method printed on it — is answered by a sheet, and that is what this is.

Nothing here reads their input template and nothing there reads a file prepared for this. Both take a spreadsheet, and the same monitoring record can feed both without either knowing about the other.

What this page is not claiming

That the numbers here are closer to the truth than theirs. The interpolation used here is inverse distance weighting or ordinary kriging fitted to one round; theirs is a spatiotemporal smoother across a record. Those are different estimators answering different questions, nobody has run a comparison of their output, and a page declaring a winner would be inventing a result.

That anything here takes less effort to use. Nobody has watched a hydrogeologist use both and timed them, so there is no measurement to quote, and a claim about ease with nothing behind it is a claim about the author’s taste.

That this site is validated in the sense their published work is. What exists here is a page listing every automated check the arithmetic is held to, the bound each one enforces and what is not checked at all — including that no hydrogeologist has reviewed any of it. That is worth reading and it is not a journal article.

What is stated here without a test behind it

These pages describe other people’s file formats and other people’s software as well as this site’s own behaviour, and the boundary between "there is a test for this" and "this is what the documentation says" is invisible to a reader unless somebody draws it. This is where it is drawn.

  • The description of GWSDAT’s hosted instance is a statement about how a hosted Shiny application works — R runs on the server, so a file opened there is processed there — rather than a quotation from their documentation. Their own deployment terms are theirs to state, and if confidentiality is your reason for asking, ask them.
  • Nobody here has run GWSDAT on a real site and compared the output with a figure from this site. Everything above is about what each tool is for and how each is put together, not about what either produces on your data.
  • The list of what GWSDAT does is taken from its own published description and from the papers named above. It is not exhaustive, it does not track their development, and a feature added since the date at the foot of this page will not be on it.

Common questions

Is this a fork of GWSDAT, or does it use any of their code?
No. There is no shared code and no shared lineage. This is written from scratch in TypeScript and runs in a browser; GWSDAT is R and runs in an R process. Their licence is GPL-3 and nothing here is derived from anything of theirs.
Can I move my data from one to the other?
Both read a spreadsheet, so the same monitoring record can feed both — but the shapes differ. Theirs wants its two-table template; this reads whatever shape your file is already in, wide or long. Neither imports the other’s project file.
Which one should I use for a regulatory submittal?
That is a question for the guidance governing your submittal and for your own professional judgement, and neither this page nor either tool can answer it for you. What is worth knowing is that GWSDAT has peer-reviewed papers and an ITRC write-up behind its methods, and that every figure made here prints its interpolation method, its settings and its well count on the sheet.
Why is this comparison here at all?
Because somebody weighing two free tools should be able to find out how they differ without installing both, and because the honest version of that page is more useful than the version that pretends there is only one answer. The rules it is written under are listed at the top, and every one of them is enforced by a test in this site’s own suite.

In short

GWSDAT is not replaced by anything here. It is a spatiotemporal analysis package with published methods behind it and several capabilities this site does not have at all; this is a figure-making tool that reads the file you already have and draws a standard set of monitoring maps in a browser tab. The overlap between them is one contoured picture of one round, which is the shallow end of both.

Where to go next

Written 2026-08-15.