[gdal-dev] gdal_rasterize with a NetCDF file?
Hi,
I'm still fairly new at using GDAL, but I am having trouble burning a
vector image onto a NetCDF file. I've had success with using
gdal_rasterize to burn a vector onto a GeoTIFF file, but when I try to
burn the same vector onto a NetCDF file, I get an error.
Based on the error, I'm suspecting it's because it doesn't know how to
find the right band in the NetCDF File (I want the
Albedo_with_1400_Local_Time_of_Measurement subdataset), but although
I've looked at the documentation, I'm not sure how to specify this to
gdal_rasterize.
Any help would be much appreciated! Below is the info.
Here is the command I am trying to run:
/usr/local/FWTools-2.0.6/bin_safe/gdal_rasterize -i -burn 0 -l
OGRGeoJSON dummy.json Albedo.nc
And the error I get:
ERROR 5: GDALDataset::GetRasterBand(1) - Illegal band #
/usr/local/FWTools-2.0.6/bin_safe/gdal_rasterize: line 9: 26950
Segmentation fault $FWTOOLS_HOME/bin/`basename $TARGET` $@
Here is the gdalinfo for Albedo.nc:
Driver: netCDF/Network Common Data Format
Files: Albedo.nc
Size is 512, 512
Coordinate System is `'
Metadata:
NC_GLOBAL#Conventions=CF-1.4
NC_GLOBAL#institution=National Snow Ice Data Center, Boulder, CO
NC_GLOBAL#title=AVHRR Polar Pathfinder Twice-Daily 5 km EASE-Grid
Composites Albedo
NC_GLOBAL#source=See the title and references for this information
NC_GLOBAL#comment=Not set at this time
NC_GLOBAL#references=Documentation available at:
http://nsidc.org/data/docs/daac/nsidc0066_avhrr_5km.gd.html
NC_GLOBAL#history=Mon, 21 Sep 2009 09:31:24: File created.
Subdatasets:
SUBDATASET_1_NAME=NETCDF:Albedo.nc:Albedo_with_1400_Local_Time_of_Measurement
SUBDATASET_1_DESC=[1x244x242]
Albedo_with_1400_Local_Time_of_Measurement (8-bit integer)
SUBDATASET_2_NAME=NETCDF:Albedo.nc:latitude
SUBDATASET_2_DESC=[244x242] latitude (64-bit floating-point)
SUBDATASET_3_NAME=NETCDF:Albedo.nc:longitude
SUBDATASET_3_DESC=[244x242] longitude (64-bit floating-point)
Corner Coordinates:
Upper Left (0.0,0.0)
Lower Left (0.0, 512.0)
Upper Right ( 512.0,0.0)
Lower Right ( 512.0, 512.0)
Center ( 256.0, 256.0)
And for completeness, the dummy.json file (it's basically a triangle):
{
type: FeatureCollection,
features: [{
type: Feature,
properties: { BASIN_ID: 1.00, AREA_SQKM: 1739.016470 },
geometry: {
type: Polygon,
coordinates: [ [
[ -200, -250 ],
[ -250, -140 ],
[ -150, -140 ],
[ -200, -250 ]
] ]
}
}]
}
Thanks!
Scott Lewis
National Snow Ice Data Center
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal_rasterize with a NetCDF file?
Evan,
Thanks, that seems to be getting me in the right direction: I'm no
longer getting the segfault error, or ERROR 5 at all.
However, now it's giving me a different error. The first line has the:
0...10...20...30...40...50...60...70...80...90...100 - done.
message, like I would expect from when I do this with GeoTIFF files.
But following that I am getting a whole bunch of this error, repeated
many times:
ERROR 6: WriteBlock() not supported for this dataset.
Doing a search online, I'm getting the impression that this might mean
that gdal_rasterize doesn't support writing to a NetCDF file? Is this
correct, or does the problem lie elsewhere with my calling of the utility.
Here's the command line I'm using now:
/usr/local/FWTools-2.0.6/bin_safe/gdal_rasterize -i -burn 0 -l
OGRGeoJSON dummy.json
'NETCDF:Albedo.nc:Albedo_with_1400_Local_Time_of_Measurement'
Thanks again for the help!
Scott
Even Rouault wrote:
Selon Scott Lewis scott.le...@nsidc.org:
Scott,
Anytime you want to access to a subdataset with a gdal utility, you must use
the
value of the relevant SUBDATASET_xxx_NAME metadata item, in that instance
'NETCDF:Albedo.nc:Albedo_with_1400_Local_Time_of_Measurement'
The segmentation fault however wasn't expected, so I commited fixes per ticket
http://trac.osgeo.org/gdal/ticket/3146 to error out more nicely.
Best regards
Hi,
I'm still fairly new at using GDAL, but I am having trouble burning a
vector image onto a NetCDF file. I've had success with using
gdal_rasterize to burn a vector onto a GeoTIFF file, but when I try to
burn the same vector onto a NetCDF file, I get an error.
Based on the error, I'm suspecting it's because it doesn't know how to
find the right band in the NetCDF File (I want the
Albedo_with_1400_Local_Time_of_Measurement subdataset), but although
I've looked at the documentation, I'm not sure how to specify this to
gdal_rasterize.
Any help would be much appreciated! Below is the info.
Here is the command I am trying to run:
/usr/local/FWTools-2.0.6/bin_safe/gdal_rasterize -i -burn 0 -l
OGRGeoJSON dummy.json Albedo.nc
And the error I get:
ERROR 5: GDALDataset::GetRasterBand(1) - Illegal band #
/usr/local/FWTools-2.0.6/bin_safe/gdal_rasterize: line 9: 26950
Segmentation fault $FWTOOLS_HOME/bin/`basename $TARGET` $@
Here is the gdalinfo for Albedo.nc:
Driver: netCDF/Network Common Data Format
Files: Albedo.nc
Size is 512, 512
Coordinate System is `'
Metadata:
NC_GLOBAL#Conventions=CF-1.4
NC_GLOBAL#institution=National Snow Ice Data Center, Boulder, CO
NC_GLOBAL#title=AVHRR Polar Pathfinder Twice-Daily 5 km EASE-Grid
Composites Albedo
NC_GLOBAL#source=See the title and references for this information
NC_GLOBAL#comment=Not set at this time
NC_GLOBAL#references=Documentation available at:
http://nsidc.org/data/docs/daac/nsidc0066_avhrr_5km.gd.html
NC_GLOBAL#history=Mon, 21 Sep 2009 09:31:24: File created.
Subdatasets:
SUBDATASET_1_NAME=NETCDF:Albedo.nc:Albedo_with_1400_Local_Time_of_Measurement
SUBDATASET_1_DESC=[1x244x242]
Albedo_with_1400_Local_Time_of_Measurement (8-bit integer)
SUBDATASET_2_NAME=NETCDF:Albedo.nc:latitude
SUBDATASET_2_DESC=[244x242] latitude (64-bit floating-point)
SUBDATASET_3_NAME=NETCDF:Albedo.nc:longitude
SUBDATASET_3_DESC=[244x242] longitude (64-bit floating-point)
Corner Coordinates:
Upper Left (0.0,0.0)
Lower Left (0.0, 512.0)
Upper Right ( 512.0,0.0)
Lower Right ( 512.0, 512.0)
Center ( 256.0, 256.0)
And for completeness, the dummy.json file (it's basically a triangle):
{
type: FeatureCollection,
features: [{
type: Feature,
properties: { BASIN_ID: 1.00, AREA_SQKM: 1739.016470 },
geometry: {
type: Polygon,
coordinates: [ [
[ -200, -250 ],
[ -250, -140 ],
[ -150, -140 ],
[ -200, -250 ]
] ]
}
}]
}
Thanks!
Scott Lewis
National Snow Ice Data Center
___
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
[gdal-dev] Re: gdal_rasterize with a NetCDF file?
Ah, thanks. I must have missed that. Looks like I'll have to find
another way to accomplish what I'm trying to do then!
Thanks for your help!
Scott
Hermann Peifer wrote:
The driver doesn't support updating netCDF files. gdalinfo --formats says:
GTiff (rw+): GeoTIFF
(...)
netCDF (rw): Network Common Data Format
The + indicates update support, which is obviously missing for netCDF
format.
Hermann
Original Message
Subject: Re:gdal_rasterize with a NetCDF file?
From: Scott Lewis scott.le...@nsidc.org
To: Date: 21/09/2009 20:37
Evan,
Thanks, that seems to be getting me in the right direction: I'm no
longer getting the segfault error, or ERROR 5 at all.
However, now it's giving me a different error. The first line has the:
0...10...20...30...40...50...60...70...80...90...100 - done.
message, like I would expect from when I do this with GeoTIFF files.
But following that I am getting a whole bunch of this error, repeated
many times:
ERROR 6: WriteBlock() not supported for this dataset.
Doing a search online, I'm getting the impression that this might mean
that gdal_rasterize doesn't support writing to a NetCDF file? Is this
correct, or does the problem lie elsewhere with my calling of the
utility.
Here's the command line I'm using now:
/usr/local/FWTools-2.0.6/bin_safe/gdal_rasterize -i -burn 0 -l
OGRGeoJSON dummy.json
'NETCDF:Albedo.nc:Albedo_with_1400_Local_Time_of_Measurement'
Thanks again for the help!
Scott
Even Rouault wrote:
Selon Scott Lewis scott.le...@nsidc.org:
Scott,
Anytime you want to access to a subdataset with a gdal utility, you
must use the
value of the relevant SUBDATASET_xxx_NAME metadata item, in that
instance
'NETCDF:Albedo.nc:Albedo_with_1400_Local_Time_of_Measurement'
The segmentation fault however wasn't expected, so I commited fixes
per ticket
http://trac.osgeo.org/gdal/ticket/3146 to error out more nicely.
Best regards
Hi,
I'm still fairly new at using GDAL, but I am having trouble burning a
vector image onto a NetCDF file. I've had success with using
gdal_rasterize to burn a vector onto a GeoTIFF file, but when I try to
burn the same vector onto a NetCDF file, I get an error.
Based on the error, I'm suspecting it's because it doesn't know how to
find the right band in the NetCDF File (I want the
Albedo_with_1400_Local_Time_of_Measurement subdataset), but although
I've looked at the documentation, I'm not sure how to specify this to
gdal_rasterize.
Any help would be much appreciated! Below is the info.
Here is the command I am trying to run:
/usr/local/FWTools-2.0.6/bin_safe/gdal_rasterize -i -burn 0 -l
OGRGeoJSON dummy.json Albedo.nc
And the error I get:
ERROR 5: GDALDataset::GetRasterBand(1) - Illegal band #
/usr/local/FWTools-2.0.6/bin_safe/gdal_rasterize: line 9: 26950
Segmentation fault $FWTOOLS_HOME/bin/`basename $TARGET` $@
Here is the gdalinfo for Albedo.nc:
Driver: netCDF/Network Common Data Format
Files: Albedo.nc
Size is 512, 512
Coordinate System is `'
Metadata:
NC_GLOBAL#Conventions=CF-1.4
NC_GLOBAL#institution=National Snow Ice Data Center, Boulder, CO
NC_GLOBAL#title=AVHRR Polar Pathfinder Twice-Daily 5 km EASE-Grid
Composites Albedo
NC_GLOBAL#source=See the title and references for this information
NC_GLOBAL#comment=Not set at this time
NC_GLOBAL#references=Documentation available at:
http://nsidc.org/data/docs/daac/nsidc0066_avhrr_5km.gd.html
NC_GLOBAL#history=Mon, 21 Sep 2009 09:31:24: File created.
Subdatasets:
SUBDATASET_1_NAME=NETCDF:Albedo.nc:Albedo_with_1400_Local_Time_of_Measurement
SUBDATASET_1_DESC=[1x244x242]
Albedo_with_1400_Local_Time_of_Measurement (8-bit integer)
SUBDATASET_2_NAME=NETCDF:Albedo.nc:latitude
SUBDATASET_2_DESC=[244x242] latitude (64-bit floating-point)
SUBDATASET_3_NAME=NETCDF:Albedo.nc:longitude
SUBDATASET_3_DESC=[244x242] longitude (64-bit floating-point)
Corner Coordinates:
Upper Left (0.0,0.0)
Lower Left (0.0, 512.0)
Upper Right ( 512.0,0.0)
Lower Right ( 512.0, 512.0)
Center ( 256.0, 256.0)
And for completeness, the dummy.json file (it's basically a triangle):
{
type: FeatureCollection,
features: [{
type: Feature,
properties: { BASIN_ID: 1.00, AREA_SQKM:
1739.016470 },
geometry: {
type: Polygon,
coordinates: [ [
[ -200, -250 ],
[ -250, -140 ],
[ -150, -140 ],
[ -200, -250 ]
] ]
}
}]
}
Thanks!
Scott Lewis
National Snow Ice Data Center
___
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
Re: [gdal-dev] gdalwarp cutting off projected image
Frank Warmerdam wrote: Scott Lewis wrote: Frank, The image I've been trying to convert is at this URL. It's about 6MB, hopefully that's not too big. ftp://sidads.colorado.edu/pub/incoming/glewis/polar.gtiff.tif Basically, I'm trying to convert it to a plain-old EPGS:4326 (latlong projection). I appreciate you taking a look. Scott, I have established the problem is the logic that computes the desired extent of the output file. It walks the edges of the input file, transforming to WGS84 and ends up with incomplete extents because there is no recognition that there is a topological discontinuity in the transformation (the pole issue). Normally my advice would be to use the SAMPLE_GRID=YES warp option to force internal sampling of the region when computing the bounds, but I have discovered that only applies to deciding what source region to read during warping - not to the computation of the original warp region. So, in the meantime you can just force selection of output extents. Something like: gdalwarp -t_srs EPSG:4326 polar.gtiff.tif out.tif -te -180 28 180 90 When I have the ticket in hand, I'll plan to modify the GDALSuggestedWarpOutput() function to allow forcing of internal gridding. It would also be nice if I could automatically recognise this sort of case to trigger it automatically, but I'm not sure how to do that without quite a bit of extra work. PS - I'm still new to the GDAL list; when you say file a Trac ticket, where would I do this? Visit: http://trac.osgeo.org/gdal There should be brief instructions on getting an OSGeo Userid which you can use to login to the site, and then hit New Ticket to file a bug report. If you find this path isn't deducable from the main GDAL web page, please email me suggestions on how to improve things. Best regards, Frank, Thanks a lot for your help, that gdalwarp string worked great. I'll submit a ticket today as well! Scott ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] gdalwarp cutting off projected image
Hi, I'm fairly new with GDAL, and have been working with a coworker who is a little more familiar with GDAL and gdalwarp, but we are both stumped by this particular issue. I have a GeoTiff image that is in a north polar Lamber Azimuthal Equal Area (laea) projection. I am trying to reproject it using gdalwarp to a cylindrical projection (like EPSG:4326). I am using the following command: gdalwarp -t_srs EPSG:4326 input.gtiff.tif output.gtiff.tif The tool runs OK, but when I open output.gtiff.tif, the projection is incomplete. The parts that are there look correct, but it seems everything above about 50 degrees is cut off, like the input.gtiff.tif had a big circle around 50 degrees cut out before the reprojection was made. I've tried looking at the options for gdalwarp, but can't seem to find anything that would help. Is there a way to force gdalwarp to reproject the entire image? Thanks! Scott Lewis NSIDC ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalwarp cutting off projected image
Frank, The image I've been trying to convert is at this URL. It's about 6MB, hopefully that's not too big. ftp://sidads.colorado.edu/pub/incoming/glewis/polar.gtiff.tif Basically, I'm trying to convert it to a plain-old EPGS:4326 (latlong projection). I appreciate you taking a look. Scott PS - I'm still new to the GDAL list; when you say file a Trac ticket, where would I do this? Scott Lewis wrote: I've been having problems getting it staged. As soon as I'm able to I'll send the URL. Maybe the source geotiff file doesn't have the information necessary to convert correctly, perhaps. Again, thanks for your help. Hopefully I'll have the URL soon. Scott Frank Warmerdam wrote: Scott Lewis wrote: Frank, Thanks for the help. I tried doing this, and ended up with the same image (even diff found them to be the same). Here are the various commands I tried. Maybe I'm just using the -wo option wrong. gdalwarp -t_srs EPSG:4326 -wo SOURCE_EXTRA=1000 input.gtiff.tif output1.gtiff.tif gdalwarp -t_srs EPSG:4326 -wo SOURCE_EXTRA=1000 input.gtiff.tif output2.gtiff.tif gdalwarp -t_srs EPSG:4326 -wo SOURCE_EXTRA=1000 SAMPLE_GRID=YES SAMPLE_STEP=100 input.gtiff.tif output3.gtiff.tif I'll continue to play with those options, though. gdalwarp seems to not act any different (IE, it takes the same amount of time to process) with or without the -wo option, so I'm thinking I'm just not using the option correctly somehow. Again, I appreciate your help! Scott, I suspect I've misconstrued what is going wrong. If you can stage the input file somewhere, and if it isn't too terribly huge, I would be interested in trying it myself. Ideally this could be filed as a Trac ticket. Best regards, ___ 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
