obs data overlay doesn't match lat/lon values

[lizadams]

If you run the script in verdi titled verdi_script_4km_obs_test.launch it will load the datasets
CCTM_combine.2008031.dave.nc.1 and verdiObs.4km_from_xorig_yorig.txt.
Contents of the verdiObs.4km_from_xorig_yorig.txt file:
Timestamp(UTC) LONGITUDE(deg) LATITUDE(deg) STATION(-) ozone(ppm)
2006-07-03T00:00:00-0000 -121.029 32.2 111993 0.04
I also loaded an ioapi obs file with the same data.
To create this ioapi file with different lat/lon values use the following commands.
ncdump paveObs.nc > paveObs.nc.txt
change Lat/Lon values in paveObs.nc.txt using text editor
ncgen -o NEW_paveObs.nc paveObs.nc.txt
Here is the contents of the file:
tail paveObs4.txt
LAT =
32.2 ;
LON =
-121.029 ;
CO =
100 ;
}
With the lat/lon values the same for both observational datasets, the sun and the circle should be on top of one another - but they are not. In addition, the lat/lon value provided by VERDI using Controls>Show Lat/Lon and hovering over the points gives very different values:
Lat = 32.02217N, Lon =121.01291W

[lizadams]

Using pave, I can create a similar plot - using the script:
/nas02/home/l/i/lizadams/VERDI_1.5.0/data/test.csh
but the data in the obs dataset now matches the lat/lon value obtained using VERDI>Controls>Show Lat/Lon
LAT =
32.02159 ;

LON =
-121.0254 ;
CO =
100 ;

Based on this, I think that there is something wrong with VERDI's plotting of the observational overlay data or with the lat/lon values that it provides. Not sure which.

[lizadams]

I used google maps to find the lat/lon location for the intersection of Arizona, Colorado, Utah and New Mexico. The value from google maps was 36,999293, -109.045419. I created a txt file with that lat/lon value and loaded it into VERDI along with the new dataset for the West36 km grid. The observational dataset lines up with the state borders for Az, CO, Ut, NM, actually I noticed that the triangle symbol lines up with the state borders, but the circle symbol for the observational values are offset to the right. However, the Control> Show Lat/Lon value does not match, and is reported to be: 36.81004N, 109.04436W. This is similar to the above case, where the LAT value reported by VERDI is .1-.2 degrees lower than the value in the obs file.

[lizadams]

using VERDI_2.0_beta_linux64_20190623.tar.gz
testing with the following script

#!/bin/csh -f

#script for testing command line options
echo 'running verdi_script.csh'

foreach species ( O3 )
./verdi.sh \
         -f $cwd/data/model/CCTM_ACONC_v5.3.b1_intel17.0_2016_CONUS_M3Dry_Bidi_OCoating_20160320.nc \
         -f  $cwd/data/obs/verdiObs.4km_from_xorig_yorig.txt \
         -f $cwd/data/obs/paveObs.nc \
         -s "${species}[1]" \
         -g tile \
         # -quit
 end

ncdump ./data/obs/paveObs.nc | more

gives the following output

netcdf paveObs {
dimensions:
	TSTEP = UNLIMITED ; // (1 currently)
	DATE-TIME = 2 ;
	LAY = 1 ;
	VAR = 4 ;
	COL = 1 ;
variables:
	int TFLAG(TSTEP, VAR, DATE-TIME) ;
		TFLAG:units = "<YYYYDDD,HHMMSS>" ;
		TFLAG:long_name = "TFLAG           " ;
		TFLAG:var_desc = "Timestep-valid flags:  (1) YYYYDDD or (2) HHMMSS                                " 
;
	int AQSID(TSTEP, LAY, COL) ;
		AQSID:long_name = "AQS           " ;
		AQSID:units = "none            " ;
		AQSID:var_desc = "Station id                                                                      " 
;
	float LAT(TSTEP, LAY, COL) ;
		LAT:long_name = "LAT             " ;
		LAT:units = "deg             " ;
		LAT:var_desc = "Latitude for station                                                            " ;
	float LON(TSTEP, LAY, COL) ;
		LON:long_name = "LON             " ;
		LON:units = "deg             " ;
		LON:var_desc = "Longitude for station                                                           " ;
	float CO(TSTEP, LAY, COL) ;
		CO:long_name = "CO              " ;
		CO:units = "ppm             " ;
		CO:var_desc = "CO               ppm                                                            " ;

// global attributes:
		:IOAPI_VERSION = "$Iddnetcdf. @(#) ioapi library version 3.0 OpenMP enabled $                       
     " ;
		:EXEC_ID = "????????????????                                                                " ;
		:FTYPE = -1 ;
		:CDATE = 2013018 ;
		:CTIME = 170313 ;
		:WDATE = 2013018 ;
		:WTIME = 170313 ;
		:SDATE = 2008031 ;
		:STIME = 80000 ;
		:TSTEP = 240000 ;
		:NTHIK = 1 ;
		:NCOLS = 1 ;
		:NROWS = 1 ;
		:NLAYS = 1 ;
		:NVARS = 4 ;
		:GDTYP = 1 ;
		:P_ALP = 0. ;
		:P_BET = 0. ;
		:P_GAM = 0. ;
		:XCENT = 0. ;
		:YCENT = 0. ;
		:XORIG = 0. ;
		:YORIG = 0. ;
		:XCELL = 0. ;
		:YCELL = 0. ;
		:VGTYP = -9999 ;
		:VGTOP = -9.999e+36f ;
		:VGLVLS = 0.f, 0.f ;
		:GDNAM = "LATLON          " ;
		:UPNAM = "Testoverlay " ;
		:VAR-LIST = "AQSID           LAT             LON             CO              " ;
		:FILEDESC = "" ;
		:HISTORY = "" ;
data:

 TFLAG =
  2008031, 0,
  2008031, 0,
  2008031, 0,
  2008031, 0 ;

 AQSID =
  111111111 ;

 LAT =
  31.97396 ;

 LON =
  -121.3532 ;

 CO =
  100 ;
}

When I compared this to what was in the ./data/obs/verdiObs.4km_from_xorig_yorig.txt file, I realized that they do not have the exact same lat lon values.
These are the values that VERDI displays when you ask for the lat/lon values (in the lower right corner) of the GUI
121.08 W 32.2064N
121.38 W 31.97 N

Timestamp(UTC)  LONGITUDE(deg)  LATITUDE(deg)   STATION(-)      ozone(ppm)
2006-07-03T00:00:00-0000        -121.029        32.2    111993  0.04

I edited the ./data/obs/verdiObs.4km_from_xorig_yorig.txt to match what was in the ./data/obs/paveObs.nc

cat .//data/obs/verdiObs.4km_from_xorig_yorig.txt
Timestamp(UTC)	LONGITUDE(deg)	LATITUDE(deg)	STATION(-)	ozone(ppm)
2006-07-03T00:00:00-0000	-121.3532	31.97396 	111993	0.04

The obs data points are much closer to each other now.
I am wondering if VERDI is displaying them purposefully so that they avoid overlaying on top of one another?

This image shows where the cursor was on the map when it is located at the latitude of 32.97 and longitude of -121.35. The cursor location and the obs overlay location are not located in the same place for the same lat/lon value.

[yadongxuEPA]

Retested with VERDI_2.1.3_linux64_20220118.tar.gz, was not able to conclude if the issue has resolved because VERDI could not display observational dataset in tab-delimited text format. Please check.
Datasets used in this test:
/data/model/CCTM_combine.2008031.dave.nc.1
/data/obs/paveObs.nc
/data/obs/verdiObs.4km_from_xorig_yorig.txt (edited the Latitude and Longitude values to match the location in paveObs.nc)

We expect to see two observational points (one in circle and one in square) overlaid exactly at the lower left corner, but it seems that VERDI could not display the observational data in text format(an error message showed up as below).

Here is what we have regarding observational data overlays in VERDI User Manual:

[yadongxuEPA]

Retested with VERDI_2.1.3_linux64_20220210.tar.gz, was able to verify that the issue has resolved.
Datasets used in this test:
/data/model/CCTM_combine.2008031.dave.nc.1
/data/obs/paveObs.nc
/data/obs/verdiObs.4km_from_xorig_yorig.txt (edited the Latitude and Longitude values to match the location in paveObs.nc, also edited the O3 unit from ppm to ppb and its value.).
We can see two observational points (one in circle and one in square) overlaid exactly at the lower left corner (shown as below).