Thanks! That gets it down to 268K!
ncks -4 --deflate 9 -v water_u,water_v -d depth,1,2,1 -d lon,0,360,10
hycom_glb_911_2015110200_t000_uv3z.nc out4.nc
On Thu, Nov 19, 2015 at 12:22 PM, Julien Demaria
wrote:
> If you want to reduce again your file you should be able to keep 0..360
> but change
If you want to reduce again your file you should be able to keep 0..360 but
change the step by decimating: -d lon,0,360,10 for example to keep only 37
longitudes.
http://research.jisao.washington.edu/data_sets/nco/#example10
Julien
De : Kurt Schwehr [schw...@gma
Julien,
Bummer that I broke you patches. I don't expect to do much more in frmts
for a while. My big sprint is done and I will likely only do a couple
hours each Friday. My focus will likely be finishing ports/ and working on
gcore and then ogr.
Here is what I currently have based on comments
Dear Kurt,
Yes you can do that using ncks from nco by specifying the subset on each
dimension:
ncks -d lon,340.0,10.0 -d lat,10.0,20.0 in.nc out.nc
another solution is to do ncdump -h into a file, editing the ascii to reduce
dimensions and do ncgen to generate the NetCDF. By default it will fill
Also asked here:
http://gis.stackexchange.com/questions/170882/how-can-a-make-a-netcdf-with-subgroups-smaller
Is there an easy way to make a netcdf with subdatasets but shrink it
without resorting to C or Fortan?
I'm trying to write a test for code that works with hycom netcdf global
ocean circul
I noticed that ogr_db2_hack.py exists to test for some DB2 V7.2 problem
with WKB. I don't know what the problem was but we did make some fixes
to the DB2 WKB support and I'm wondering if this test is still necessary.
If the test is still necessary, was the problem reported to DB2 development?
Evan,
I wanted to circle back to you and thank you for the suggestion regarding
"fieldmap identity". It turns out this was indeed the problem. I was
convinced that it needed to be used to ensure that the domains and
sub-types of the filegeodatabase were transferred.
Thanks again!
David Vick
P
What I decided to do it to set the GPCs on the corners :
var gcps = new[]
{
new GCP(LeftUp.X, LeftUp.Y, LeftUp.Z, 0, 0, null, "1"),
new GCP(RightUp.X, RightUp.Y, RightUp.Z, Width , 0, null, "2"),
new GCP(RightDown.X, RightDown.Y, RightDown.Z, Width, Height, null, "3"),
new GCP(LeftDown.X, LeftDown
Done: https://trac.osgeo.org/gdal/ticket/6225#ticket
Thanks once again!!
Simon
On Thu, Nov 19, 2015 at 10:59 AM, Even Rouault
wrote:
> Le jeudi 19 novembre 2015 10:47:50, Simon Lyngby Kokkendorff a écrit :
> > I can confirm also that it works when I set a target srs.
> > But must admit that th
Le jeudi 19 novembre 2015 10:47:50, Simon Lyngby Kokkendorff a écrit :
> I can confirm also that it works when I set a target srs.
> But must admit that the current behaviour was confusing. I knew how to
> interpret the input data - under the assumption that a geotransform is not
> changed when I d
I can confirm also that it works when I set a target srs.
But must admit that the current behaviour was confusing. I knew how to
interpret the input data - under the assumption that a geotransform is not
changed when I do no transformations or interpolations:
If I know that my data are "points" rat
On 19.11.2015 11:26, Even Rouault wrote:
GDAL version:
GDAL 1.11.2, released 2015/02/10
Simon,
Regarding the fact that the geotiff file looses the half-pixel shift, it seems
to be due to the absence of a SRS. If I do "gdal_translate test.asc test.tif -
a_srs EPSG:32630" for example, then the
Le jeudi 19 novembre 2015 09:24:46, Simon Lyngby Kokkendorff a écrit :
> Basically it seems to be an issue with interpreting "center" directives
> when doing the gdal_translate. Consider:
>
> ncols 2
> nrows 2
> xllcenter 0.0
> yllcenter 0.0
> cellsize 1.0
> nodata_value -999
> 2 2
> 2 2
>
> gdal
Thanks Ari,
I wasn't aware of that. Naively assumed that GDAL would just keep the
geotransform in a gdal_translate, no matter what. Good to know, thanks!
Cheers,
SImon
On Thu, Nov 19, 2015 at 10:03 AM, Ari Jolma wrote:
> Simon,
>
> If you set the configuration option GTIFF_POINT_GEO_IGNORE
Simon,
If you set the configuration option GTIFF_POINT_GEO_IGNORE to "TRUE"
instead of the default "FALSE" the offset will not happen.
I've tested this and it works. The configuration option needs to be set
in code, it is not a GTiff creation option.
I'm not quite sure why you need to do th
Basically it seems to be an issue with interpreting "center" directives
when doing the gdal_translate. Consider:
ncols 2
nrows 2
xllcenter 0.0
yllcenter 0.0
cellsize 1.0
nodata_value -999
2 2
2 2
gdalinfo on this file, will give the expected GeoTransform:
In [2]: ds = gdal.Open("center.asc")
In
16 matches
Mail list logo
