Re: [gdal-dev] Why not netCDF output?
Joaquim, The valid formats for the output of gdalwarp are formats that support the Create() method, not just the CreateCopy() method. This is indicated by (rw+) : the + indicates that Create() is supported. The difference between Create() and CreateCopy() is mainly that Create() allows writing of pixel data in random order, which is needed by gdalwarp. You can try in 2 steps : 1) gdalwarp -of VRT lixo.grd [other_options] temp.vrt 2) gdal_translate -of netCDF temp.vrt proj.grd Best regards, Even Hi While running this command gdalwarp -s_srs +proj=latlong -t_srs +proj=ortho +lon_0=-42 +lat_0=40 +ellps=WGS84 -of netCDF lixo.grd proj.grd I get Output driver `netCDF' not recognised or does not support direct output file creation. The following format drivers are configured (a format list where netCDF is not listed) but if I ask gdalwarp the list of formats, netCDF is listed there as (rw). Furthermore gdalwarp --format netCDF Format Details: Short Name: netCDF Long Name: Network Common Data Format Extension: nc Help Topic: frmt_netcdf.html Supports: CreateCopy() - Create dataset by copying another. ?? Joaquim Luis ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Why not netCDF output?
Thanks Even, I think that's the second time you explain me that (sorry, an easy thing to forget), but the docs could be a bit clearer about this. For example *--formats* List all raster formats supported by this GDAL build (read-only and read-write) and exit. The format support is indicated as follows: 'ro' is read-only driver; 'rw' is read or write (ie. supports CreateCopy); 'rw+' is read, write and update (ie. supports Create). so I though the + was for updating A second point is that the command I used shows a bug in gdalwarp. In that the lixo.grd is a grid extracted from one the etopo_something (actually a regrid version created by me) saning [-180 180] [0 90] and the bug is that at dateline there is a stripe of nodata. Since the grid is too big to post in a ticket, can you please try to reproduce this? Joaquim Joaquim, The valid formats for the output of gdalwarp are formats that support the Create() method, not just the CreateCopy() method. This is indicated by (rw+) : the + indicates that Create() is supported. The difference between Create() and CreateCopy() is mainly that Create() allows writing of pixel data in random order, which is needed by gdalwarp. You can try in 2 steps : 1) gdalwarp -of VRT lixo.grd [other_options] temp.vrt 2) gdal_translate -of netCDF temp.vrt proj.grd Best regards, Even Hi While running this command gdalwarp -s_srs +proj=latlong -t_srs +proj=ortho +lon_0=-42 +lat_0=40 +ellps=WGS84 -of netCDF lixo.grd proj.grd I get Output driver `netCDF' not recognised or does not support direct output file creation. The following format drivers are configured (a format list where netCDF is not listed) but if I ask gdalwarp the list of formats, netCDF is listed there as (rw). Furthermore gdalwarp --format netCDF Format Details: Short Name: netCDF Long Name: Network Common Data Format Extension: nc Help Topic: frmt_netcdf.html Supports: CreateCopy() - Create dataset by copying another. ?? Joaquim Luis ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Why not netCDF output?
Le lundi 27 septembre 2010 21:20:02, Joaquim Luis a écrit : Thanks Even, I think that's the second time you explain me that (sorry, an easy thing to forget), but the docs could be a bit clearer about this. For example *--formats* List all raster formats supported by this GDAL build (read-only and read-write) and exit. The format support is indicated as follows: 'ro' is read-only driver; 'rw' is read or write (ie. supports CreateCopy); 'rw+' is read, write and update (ie. supports Create). so I though the + was for updating What would you suggest to be clearer ? A second point is that the command I used shows a bug in gdalwarp. In that the lixo.grd is a grid extracted from one the etopo_something (actually a regrid version created by me) saning [-180 180] [0 90] and the bug is that at dateline there is a stripe of nodata. Since the grid is too big to post in a ticket, can you please try to reproduce this? Yes I reproduce it too. I managed to solve it by increasing the SAMPLE_STEPS warping option to 60 for example (input source is 5120 x 2560). See http://gdal.org/structGDALWarpOptions.html for more explanations gdalwarp world.tif -t_srs +proj=ortho +lon_0=-42 +lat_0=40 +ellps=WGS84 out.tif -overwrite -wo SAMPLE_STEPS=60 Joaquim Joaquim, The valid formats for the output of gdalwarp are formats that support the Create() method, not just the CreateCopy() method. This is indicated by (rw+) : the + indicates that Create() is supported. The difference between Create() and CreateCopy() is mainly that Create() allows writing of pixel data in random order, which is needed by gdalwarp. You can try in 2 steps : 1) gdalwarp -of VRT lixo.grd [other_options] temp.vrt 2) gdal_translate -of netCDF temp.vrt proj.grd Best regards, Even Hi While running this command gdalwarp -s_srs +proj=latlong -t_srs +proj=ortho +lon_0=-42 +lat_0=40 +ellps=WGS84 -of netCDF lixo.grd proj.grd I get Output driver `netCDF' not recognised or does not support direct output file creation. The following format drivers are configured (a format list where netCDF is not listed) but if I ask gdalwarp the list of formats, netCDF is listed there as (rw). Furthermore gdalwarp --format netCDF Format Details: Short Name: netCDF Long Name: Network Common Data Format Extension: nc Help Topic: frmt_netcdf.html Supports: CreateCopy() - Create dataset by copying another. ?? Joaquim Luis ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Why not netCDF output?
On 27-09-2010 20:39, Even Rouault wrote: Le lundi 27 septembre 2010 21:20:02, Joaquim Luis a écrit : Thanks Even, I think that's the second time you explain me that (sorry, an easy thing to forget), but the docs could be a bit clearer about this. For example *--formats* List all raster formats supported by this GDAL build (read-only and read-write) and exit. The format support is indicated as follows: 'ro' is read-only driver; 'rw' is read or write (ie. supports CreateCopy); 'rw+' is read, write and update (ie. supports Create). so I though the + was for updating What would you suggest to be clearer ? Well, using your own words, and to not extend the wording too much. Something like ... 'rw+' is read, write and update (ie. supports Create). Note: The valid formats for the output of gdalwarp are formats that support the Create() method, not just the CreateCopy() method. Yes I reproduce it too. I managed to solve it by increasing the SAMPLE_STEPS warping option to 60 for example (input source is 5120 x 2560). See http://gdal.org/structGDALWarpOptions.html for more explanations gdalwarp world.tif -t_srs +proj=ortho +lon_0=-42 +lat_0=40 +ellps=WGS84 out.tif -overwrite -wo SAMPLE_STEPS=60 Thanks. It worked for me too. I have followed this issue that is recurrent here in different disguises. If it was easy to solve you guys would have done it long ago, but about a warning message when this problem arises? I mean, is there any doable way to detect a posteriori that the shit happened and the SAMPLE_STEPS can help clean it? Joaquim ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Why not netCDF output?
Le lundi 27 septembre 2010 22:11:43, Joaquim Luis a écrit : Well, using your own words, and to not extend the wording too much. Something like ... 'rw+' is read, write and update (ie. supports Create). Note: The valid formats for the output of gdalwarp are formats that support the Create() method, not just the CreateCopy() method. Applied. But note that gdalwarp is just a (common) example. There are also other utilities that have this restriction. Yes I reproduce it too. I managed to solve it by increasing the SAMPLE_STEPS warping option to 60 for example (input source is 5120 x 2560). See http://gdal.org/structGDALWarpOptions.html for more explanations gdalwarp world.tif -t_srs +proj=ortho +lon_0=-42 +lat_0=40 +ellps=WGS84 out.tif -overwrite -wo SAMPLE_STEPS=60 Thanks. It worked for me too. I have followed this issue that is recurrent here in different disguises. If it was easy to solve you guys would have done it long ago, but about a warning message when this problem arises? I mean, is there any doable way to detect a posteriori that the shit happened and the SAMPLE_STEPS can help clean it? Yes, that's probably doable, but clearly not trivial. I add a hard time (look at how ugly/complicated the code now looks...) doing something similar in GDALSuggestedWarpOutput2() to guess the extent of the target extent when such discontinuities in the reprojection occur (and it probably doesn't solve 100% situations). Something similar (in spirit) would probably be needed in GDALWarpOperation::ComputeSourceWindow(). Joaquim ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Why not netCDF output?
Yes, that's probably doable, but clearly not trivial. I add a hard time (look at how ugly/complicated the code now looks...) doing something similar in GDALSuggestedWarpOutput2() to guess the extent of the target extent when such discontinuities in the reprojection occur (and it probably doesn't solve 100% situations). Something similar (in spirit) would probably be needed in GDALWarpOperation::ComputeSourceWindow(). Yes, big it is and I confess that I didn't even try to comprehend what it does. But my suggestion was perhaps simpler (in mind). My idea was to just give a warning that a discontinuity had occurred and advise that the SAMPLE_STEPS can be of much help. And how to detect the discontinuity? Sure that's the key question, but on the current case the -180 and the 180 points should be coincident on the target grid, or at least very, very close (in terms of target grid steps). If they aren't ... ring the bell Well just a thought. Joaquim ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
