This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Hi Rich- > Wow, talk about a blast from the past! Better late than never. ;-) > As you say, it seems that Steve Cousins changed the longitude values > in his test.nc file to match the values we were previously supplying > in the NcML so that the test.nc file now works fine. > > But we can happily use the NcML file to change the longitude back to > illustrate the IDV problem. > > <netcdf xmlns="http://www.unidata.ucar.edu/namespaces/netcdf/ncml-2.2" > location="http://rocky.umeoce.maine.edu/cousins/test.nc"> > <variable name="Depth"> > <attribute name="positive" value="up"/> > </variable> > <variable name="Longitude"> > <attribute name="units" value="degrees_east"/> > <!-- <values start="-159.8819" increment="0.125"/>--> > <values start="200.1181" increment="0.125"/> > </variable> > <variable name="Latitude"> > <attribute name="units" value="degrees_north"/> > </variable> > <attribute name="Conventions" type="String" value="CF-1.0"/> > </netcdf> > > Using this NcML reproduces the original problem of the data plotting > off the coastline map. See attached: This seems to work now in the nightly build. If you could test it on other datasets, that would be good. Don > On Sun, Feb 8, 2009 at 3:25 PM, Unidata IDV Support > <address@hidden> wrote: > > Hi Rich- > > > > I've finally gotten back to this (only taken a year). If I > > load in the test.nc file that the peru.ncml points to, it > > looks like the lat/lons have been changed. Is that true? > > If so, do you have a file that exhibits the initial behavior? > > > > Thanks. > > > > Don > >> > On Tue, Apr 15, 2008 at 5:30 PM, Unidata IDV Support > >> > <address@hidden> wrote: > >> > > >> > > It's really that the map lines go from -180 to 180 and the data > >> > > goes from 0-360. Depending on the projection, one will not > >> > > line up. > >> > > >> > Ah, okay. > >> > >> Let me explain that a bit more. The map projection from the > >> data is based on the range of the longitude values in the data. > >> In your case, you have values > 180. The map lines are in > >> -180 to 180. So, the map projection is going to be to the > >> right of the map lines: > >> > >> -180 180 200+(your area) > >> > >> map data > >> > >> However, when you change the data to be in the -180 to 180 range, > >> then both are within the same bounds. > >> > >> (not sure if that clears it up or makes it more confusing). > >> > >> > > > >> > > > If would be nice if IDV did this so I didn't have to! > >> > > > >> > > That would be nice. ;-) > >> > > > >> > > > http://stellwagen.er.usgs.gov/models/share/peru.ncml > >> > > > >> > > That dataset only goes to about -160. Is that the correct > >> > > link? I'm not sure I'm understanding the problem you are seeing > >> > > with this example. > >> > > >> > If you delete the line in the NcML where I overwrote the Longitude > >> > values you will see the problem. > >> > >> I've put a check in there to see if the bounds of the map > >> projection fall within 0-360 or -180 to 180. Based on that > >> I normalize all longitudes to fit in that range. I've got > >> a lot of testing to do, but this might just work. Thanks > >> for the suggestion. > >> > >> Don > >> > > > > > > Ticket Details > > =================== > > Ticket ID: KWE-346293 > > Department: Support IDV > > Priority: Normal > > Status: Open > > > > > > > > -- > Dr. Richard P. Signell (508) 457-2229 > USGS, 384 Woods Hole Rd. > Woods Hole, MA 02543-1598 > > Ticket Details =================== Ticket ID: KWE-346293 Department: Support IDV Priority: Normal Status: Open