Opened 18 years ago

Last modified 18 years ago

#1259 closed defect (fixed)

NetCDF Driver - no-linear latitude/longitude maps not recognised

Reported by: warmerdam Owned by: warmerdam
Priority: highest Milestone:
Component: GDAL_Raster Version: unspecified
Severity: normal Keywords:
Cc:

Description

I have a netcdf dataset with latitude and longitude dimensions:

dimensions:
        time = 1 ;
        depth = 59 ;
        latitude = 499 ;
        longitude = 720 ;
variables:
        float time(time) ;
                time:units = "days since 1950-01-01 00:00:00" ;
        float latitude(latitude) ;
                latitude:units = "degree_north" ;
                latitude:valid_min = -90.f ;
                latitude:valid_max = 90.f ;
        float longitude(longitude) ;
                longitude:units = "degree_east" ;
                longitude:valid_min = -180.f ;
                longitude:valid_max = 180.f ;
...
 latitude = -77.01048, -76.89761, -76.78378, -76.66898, -76.5532, -76.43644, 
    -76.31867, -76.19991, -76.08014, -75.95934, -75.83752, -75.71467, 
    -75.59077, -75.46582, -75.33981, -75.21273, -75.08458, -74.95534, 
    -74.825, -74.69357, -74.56102, -74.42735, -74.29256, -74.15662, 
    -74.01955, -73.88131, -73.74191, -73.60134, -73.45959, -73.31665, 
    -73.17251, -73.02715, -72.88058, -72.73279, -72.58376, -72.43347, 
    -72.28194, -72.12914, -71.97506, -71.8197, -71.66305, -71.5051, 
    -71.34583, -71.18523, -71.02332, -70.86005, -70.69543, -70.52946, 
    -70.36211, -70.19337, -70.02325, -69.85174, -69.6788, -69.50445, 
    -69.32867, -69.15144, -68.97276, -68.79263, -68.61102, -68.42793, 
    -68.24334, -68.05725, -67.86966, -67.68053, -67.48988, -67.29768, 
    -67.10394, -66.90862, -66.71173, -66.51326, -66.31319, -66.11152, 
    -65.90823, -65.70332, -65.49677, -65.28857, -65.07871, -64.8672, 
    -64.65399, -64.4391, -64.22252, -64.00423, -63.78421, -63.56247, 
    -63.33899, -63.11375, -62.88676, -62.658, -62.42746, -62.19513, 
    -61.96099, -61.72505, -61.48729, -61.24769, -61.00626, -60.76297, 
    -60.51783, -60.27082, -60.02193, -59.77115, -59.51847, -59.26389, 
    -59.00738, -58.74895, -58.48859, -58.22628, -57.96202, -57.6958, 
    -57.4276, -57.15743, -56.88527, -56.61111, -56.33495, -56.05677, 
    -55.77657, -55.49435, -55.21008, -54.92377, -54.63541, -54.34499, 
    -54.05251, -53.75795, -53.46131, -53.16258, -52.86176, -52.55884, 
    -52.25381, -51.94667, -51.63742, -51.32603, -51.01253, -50.69688, 

If you examine the latitude values, the distance from one step to the next
varies as you go through the array.  In this case it is beause the real
underlying data is in some sort of Mercator projection even though all the
geolocation info is in geographic. 

The driver incorrectly assumes that the latitude is linear.  It ought to 
examine the latitude and longitude array and refuse to return a geotransform
for the data if the interval of either map noticably varies through the array (within some sort of precision tolerance).

Change History (2)

comment:1 by warmerdam, 18 years ago

The dataset is public, and can be found (at least temporarily) at:

  ftp://ftp.ifremer.fr/ifremer/sismer/CampToCamp/netcdf/OA_20050518.nc

It is around 80MB. 

comment:2 by denis.nadeau@…, 18 years ago

For lat/lon array,  I was only checking if the longitude array was equally space.  It seems that this was not sufficient.  The driver now will check if both array longitude and lattitude are equally spaced.
Note: See TracTickets for help on using tickets.