Re: [gdal-dev] Cassini_Soldner warping using WGS84 GCPs is distorted
Hi Frank, thank you for your answer. I have tried gdalwarp -t_srs EPSG:4326 -tr 0.031156 0.019021 pic_gcp.tif result.tif but neither with QGis nor with SharpMap the map is rendered undistorted. And that although the sizes now have proper values... Any idea? Best regards, Martin ..\FWTools2.4.2\bingdalinfo result.tif Driver: GTiff/GeoTIFF Files: result.tif Size is 15141, 11373 Coordinate System is: GEOGCS[WGS 84, DATUM[WGS_1984, SPHEROID[WGS 84,6378137,298.257223563, AUTHORITY[EPSG,7030]], AUTHORITY[EPSG,6326]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433], AUTHORITY[EPSG,4326]] Origin = (13.437037980137905,52.481881537880760) Pixel Size = (0.0311560,-0.0190210) Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left ( 13.4370380, 52.4818815) ( 13d26'13.34E, 52d28'54.77N) Lower Left ( 13.4370380, 52.4602490) ( 13d26'13.34E, 52d27'36.90N) Upper Right ( 13.4842113, 52.4818815) ( 13d29'3.16E, 52d28'54.77N) Lower Right ( 13.4842113, 52.4602490) ( 13d29'3.16E, 52d27'36.90N) Center ( 13.4606246, 52.4710652) ( 13d27'38.25E, 52d28'15.83N) Band 1 Block=15141x1 Type=Byte, ColorInterp=Palette Color Table (RGB with 256 entries) 0: 0,0,0,255 1: 1,1,1,255 2: 2,2,2,255 Original-Nachricht Datum: Fri, 18 Sep 2009 10:39:09 -0400 Von: Frank Warmerdam warmer...@pobox.com An: Martin Geng martin.g...@gmx.de CC: gdal-dev@lists.osgeo.org Betreff: Re: [gdal-dev] Cassini_Soldner warping using WGS84 GCPs is distorted Martin, Examining the GCPs in WGS84 space I see: (13.4841338099227 - 13.4370322252183) / 15118 3.1155962894827404e-06 %.10f % ((13.4841338099227 - 13.4370322252183) / 15118) '0.031156' %.10f % ((52.4818154665202 - 52.4602476117909)/ 11339) '0.019021' Basically, in WGS84 space your source pixels are distinctly non-square and gdalwarp distorts your image to produce square pixels in the output projection. If you want to preserve the original aspect ratio try: -tr 0.031 0.019 on the gdalwarp commandline. But basically WGS84 and Cassini-Soldner have quite different characteristics in the area of your image, and WGS84 may not be a good working coordinate system for the image. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Spatialite oddness
Hi, Thanks a lot. It was indeed enough to put a new dll into FWTools bin directory. Right now I am pleased enough because I can handle the data storaged in Spatialite database with both FWTools and current Spatialite programs. However, Spatialite database feels so handy that it attracts me to try delivering some data from it through Mapserver. I fear that missing spatial extensions in FWTools means lost spatial indexes and slow bounding box queries as well but I will see it soon. I made a new FWTools bug number 2099 through bugzilla about outdated dll. -Jukka Rahkonen- Even Rouault wrote Selon Jukka Rahkonen jukka.rahko...@mmmtike.fi: Jukka, yes, I can also reproduce the issue, but the solution is quite easy. You'll have to convince Frank to update FWTools' sqlite3.dll to a newer one as it appears that the sqlite lib used by spatialite-gui outputs the SQLITE db in a newer format that an ancient sqlite3.dll can't read. I've managed to make it work by just dropping the DLL from http://www.sqlite.org/sqlitedll-3_6_18.zip into fwtools/bin (But note, that you won't be able to use the spatial extensions from spatialite from FWTools. GDAL/OGR needs to be compiled and linked against libspatialite for that) Best regards, Even Hi, I made some trials with Spatialite and faced some problems. My environment: Windows Vista Business Spatialite-GUI v.1.2.1 with Spatialite 2.3.1 inside GDAL 1.7.0dev, FWTools 2.4.2, released 2009/06/24 Oddness is that ogr does not recognise Spatialite database that is created with Spatialite-GUI. Or it does, initially after the database is created but still without data: C:\data\Vmap0ogrinfo bordersdb.sqlite INFO: Open of `bordersdb.sqlite' using driver `SQLite' successful. However, once I have inported a shapefile into this database with Spatialite-GUI Load shapefile tool it is no more recognised: C:\data\Vmap0ogrinfo bordersdb.sqlite ERROR 1: Unable to fetch list of tables: unsupported file format ERROR 1: Unable to fetch list of tables: unsupported file format FAILURE: Unable to open datasource `bordersdb.sqlite' with the following drivers. QGis version 1.3.0 build 11628 open this same Spatialite db without problems. I tried also to create a Spatialite database with ogr2ogr from the same shapefile as: C:\data\Vmap0ogr2ogr -f SQLite sqlite4.sqlite borders.shp -dsco spatialite=yes This database is opened by all three: ogr, Spatialite-GUI and QGis. Is the Spatialite driver that comes with FWtools 2.4.2 outdated or what is going on? By the way, there is quite a difference in file sizes if the same shapefile is imported either by Spatialite-GUI or ogr2ogr: 15.09.2009 20:08 642Â 048 Spatialite-GUI_borders.sqlite 15.09.2009 20:1555Â 296 FWTools_borders.sqlite -Jukka Rahkonen- ___ 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] Problems with TIFF internal symbols
On Fri, Sep 18, 2009 at 08:55:03AM +0200, Antonio Valentino wrote: Hi list, I'm trying to use OTB (Orfeo ToolBox) on Debian Sid with GDAL 1.6.2 and I get a lot of segmentation fault related to GDAL and TIFF files. A guy on the OTB mailing list suggested that it could depend on the with-hide-internal-symbols flag used for Debian packages. See thread http groups dot google dot com /group/otb-users/browse_thread/thread/be8ad5e263aafe14 (sorry the spam filter of my ISP keeps blocking this message) Is the above hypothesis correct? How can we solve the issue in this case? Best regards The only problem found in the past with that option was: http://svn.debian.org/viewsvn/pkg-grass/packages/gdal/trunk/debian/patches/cpl_dll.dpatch?revision=2232view=markup and it was detected at linking time. It seems OTB is misusing the original TIFF API or exploting some inner problems of the same library. Note that the geotiff internal gdal library has been used since 1.6.0 in debian, the old one used the same library you are now linking with the default configuration. So the objection seems pointless. -- Francesco P. Lovergine ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Problems with TIFF internal symbols
Hi Francesco, thanks for your feedback - Original Message - From: Francesco P. Lovergine fran...@debian.org To: Antonio Valentino antonio.valent...@tiscali.it Cc: gdal-dev@lists.osgeo.org Sent: Monday, September 21, 2009 10:45 AM Subject: Re: [gdal-dev] Problems with TIFF internal symbols On Fri, Sep 18, 2009 at 08:55:03AM +0200, Antonio Valentino wrote: Hi list, I'm trying to use OTB (Orfeo ToolBox) on Debian Sid with GDAL 1.6.2 and I get a lot of segmentation fault related to GDAL and TIFF files. A guy on the OTB mailing list suggested that it could depend on the with-hide-internal-symbols flag used for Debian packages. See thread http groups dot google dot com /group/otb-users/browse_thread/thread/be8ad5e263aafe14 (sorry the spam filter of my ISP keeps blocking this message) Is the above hypothesis correct? How can we solve the issue in this case? Best regards The only problem found in the past with that option was: http://svn.debian.org/viewsvn/pkg-grass/packages/gdal/trunk/debian/patches/cpl_dll.dpatch?revision=2232view=markup and it was detected at linking time. It seems OTB is misusing the original TIFF API or exploting some inner problems of the same library. Note that If my understanding is correct OTB implements some check at configuration time in order to determine whenever GDAL exposes TIFF/GeoTIFF simbols or not. http://hg.orfeo-toolbox.org/OTB/file/591cba0c0fb0/CMakeLists.txt#l499 At first look the procedure seems to be correct but segmentation faults arise when the GDAL file reader try to open/create TIFF files (the debugger stops on the m_hDriver-Create call or so. I can't figure out why this happens, just I hoped someone more expert than me could provide some hint. the geotiff internal gdal library has been used since 1.6.0 in debian, the old one used the same library you are now linking with the default configuration. So the objection seems pointless. Yes, no problem with GDAL packages of version 1.6.0. I'm aware that the change (use of internal libtiff) happened in 1.6.0 packages so I guessed the problem could be related to a bad handling of libtiff symbols. I wonder if there is some particular advice on how to build/link client code. Best regards -- Antonio VALENTINO ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[Gdal-dev] Extent of a set of tiles
Dear all, I have a set of tiles. I would like to know the polygon coordinates which describe the extent of this set of tiles. Is there a way to make this with GDAL? I saw the possibility to make a rectangular extent but here it is more a polygon (as the set of tiles doesn't represent necessary a rectangle) thanks Pascal -- View this message in context: http://n2.nabble.com/Extent-of-a-set-of-tiles-tp3684624p3684624.html Sent from the GDAL - Dev mailing list archive at Nabble.com. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Extend Maintenance Contract
On Sep 20, 2009, at 10:19 PM, Frank Warmerdam wrote: Folks, Motion: Extend Chaitanya's maintenance contract to December 31st. --- Chaitanya has only billed $1224.00 during the planned maintenance period ending August 31st, 2009 out of available funding of $6000.00. Chaitanya has indicate greater time availability and a wish to continue working as maintainer. I would like to modify the existing contract to extend it till the end of December 2009, without modifying the other terms including the amount. So basically giving Chaitanya another 4 months to bill work against the existing amount. I will start voting with a +1. +1. Speaking of which, are we going to release 1.7 on your birthday again? ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] 1.7 Release Planning
Howard Butler wrote: Speaking of which, are we going to release 1.7 on your birthday again? Howard, I would like to aim somewhat earlier - perhaps the end of October with a bit of room to slip if needed. Does anyone have particular features they want to see accomplished in time for 1.7? I'd like to see some sort of handling of utf-8 filenames on windows. I'd like to see a new PCIDSK driver based on the new PCIDSK SDK. I'd like to see WKT Raster in trunk. I'd like to see serious progress on the bug list. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] OGRGeometry Distance
Hi all; I wanted to compute the distance between two points, and for this reason I tried the OGRGeometry::Distance member function. However, I saw that this function only returns the linear distance between the objects, regardless of their geospatial reference. (as it is also stated somewhere on the net that GEOS library implements it this way) So I would like to compute the actual distance between the points, let's say, 23 degrees north, 30 degrees east and 25 degrees west, -5 degrees east. My question is, do we need to implement this functionality by using projection transformations etc., or is there an easy way to do this using the OGR library? Also, as another related question, I query the DEPCNT layer in one of my ENC files, and it has a geospatial reference. However, the points on the line string features themselves return NULL when they are queried with getSpatialReference(). Aren't they expected to return exactly the same instance for the layer that they reside on? Regards, Yilmaz ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: Problem with gdal_translate
gdal_translate -scale src_dataset.asc dst_dataset.tif -scale [src_min src_max [dst_min dst_max]]: Rescale the input pixels values from the range src_min to src_max to the range dst_min to dst_max. If omitted the output range is 0 to 255. If omitted the input range is automatically computed from the source data. see: http://gdal.org/gdal_translate.html By the way: TILES is not a valid creation option (TILED however is). Hermann Chris Emberson wrote: Thanks for your reply. Would you be able to give me an example of the syntax for the gdal_translate option*? *How do I change the dynamics to 8 bits?* -scale* /[src_min src_max [dst_min dst_max]]/: Thanks Chris Date: Fri, 11 Sep 2009 18:06:48 +0200 From: even.roua...@mines-paris.org To: chrisember...@hotmail.com CC: gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] Problem with gdal_translate Selon Chris Emberson chrisember...@hotmail.com: The behaviour you see is expected. -expand rgb only works for bands that have color maps. You can transform your grey scale FILEA.asc into a RGB file by doing this : gdal_translate -of GTiff -co TILES=YES -b 1 -b 1 -b 1 FILEA.asc FILEB.tif This will use the source band 1 for the R, G, B components of the output file. You may need to use the scaling/translate options of gdal_translate to reduce the dynamics to 8 bits. I am having trouble converting a single band raster (.asc) when using the GDAL utility gdal_translate (version 1.6) This is the command... gdal_translate -of GTiff -co TILES=YES -expand rgb FILEA.asc FILEB.tif I get this message Error : band 1 has no color table I want to be able to tile this raster using Mapnik - therefore it needs to be a 3 band tiff - Can anyone help with this problem? Thanks in advance Chris _ Save time by using Hotmail to access your other email accounts. http://clk.atdmt.com/UKM/go/167688463/direct/01/ View your other email accounts from your Hotmail inbox. Add them now. http://clk.atdmt.com/UKM/go/167688463/direct/01/ ___ 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] Motion: Extend Maintenance Contract
+1 Best regards, Tamas 2009/9/21 Frank Warmerdam warmer...@pobox.com Folks, Motion: Extend Chaitanya's maintenance contract to December 31st. --- Chaitanya has only billed $1224.00 during the planned maintenance period ending August 31st, 2009 out of available funding of $6000.00. Chaitanya has indicate greater time availability and a wish to continue working as maintainer. I would like to modify the existing contract to extend it till the end of December 2009, without modifying the other terms including the amount. So basically giving Chaitanya another 4 months to bill work against the existing amount. I will start voting with a +1. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdamhttp://pobox.com/%7Ewarmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ 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] 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
[gdal-dev] Problem converting .gml to shapefile
Hello everybody, I have a problem converting a gml file into .shp. I'm using this command: ogr2ogr -append -f ESRI Shapefile limits limits.gml -nlt multipolygon but it's not working, it seems that only one geometry per feature is converted. What am I doing wrong? You can have a look at the gml file here: http://groups.google.com/group/geodjango/web/limits.gml.tar.gz Thank you very much, I've spent all day with this without success. Regards, Adrian signature.asc Description: This is a digitally signed message part. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Extend Maintenance Contract
Selon Frank Warmerdam warmer...@pobox.com: +1 Best regards Folks, Motion: Extend Chaitanya's maintenance contract to December 31st. --- Chaitanya has only billed $1224.00 during the planned maintenance period ending August 31st, 2009 out of available funding of $6000.00. Chaitanya has indicate greater time availability and a wish to continue working as maintainer. I would like to modify the existing contract to extend it till the end of December 2009, without modifying the other terms including the amount. So basically giving Chaitanya another 4 months to bill work against the existing amount. I will start voting with a +1. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ 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] Motion: Extend Maintenance Contract
Frank Warmerdam wrote: Folks, Motion: Extend Chaitanya's maintenance contract to December 31st. --- Chaitanya has only billed $1224.00 during the planned maintenance period ending August 31st, 2009 out of available funding of $6000.00. Chaitanya has indicate greater time availability and a wish to continue working as maintainer. I would like to modify the existing contract to extend it till the end of December 2009, without modifying the other terms including the amount. So basically giving Chaitanya another 4 months to bill work against the existing amount. +1 Daniel -- Daniel Morissette http://www.mapgears.com/ ___ 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?
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
Re: [gdal-dev] OGRGeometry Distance
Yilmaz Arslanoglu wrote: I wanted to compute the distance between two points, you need to be clear by what you mean here: I suspect you mean: The shortest distance between two points following the surface of the earth In which case, what you are looking for is referred to as the geodesic distance: http://www.vterrain.org/Misc/distance.html To do this accurately (and you may not need much accuracy!) on an ellipsoid requires a fair bit of math. I don't know if it's built in to OGR or PROJ at this point, but there are a few libraries out that that do it, including Gerald I. Evenden's geodesic lib, which can be found here: http://home.comcast.net/~gevenden56/geodesy/project/ -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ 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
Re: [gdal-dev] OGRGeometry Distance
Selon Christopher Barker chris.bar...@noaa.gov: I'd note that in the OGR XPlane driver, a function is available to compute the distance on the spheroid. You could use it if you don't need much accuracy : http://trac.osgeo.org/gdal/browser/trunk/gdal/ogr/ogrsf_frmts/xplane/ogr_xplane_geo_utils.cpp (It's an internal function to OGR, so you'd have to copypaste it in your code, or add a CPL_DLL decoration in the corresponding .h and rebuild GDAL) Yilmaz Arslanoglu wrote: I wanted to compute the distance between two points, you need to be clear by what you mean here: I suspect you mean: The shortest distance between two points following the surface of the earth In which case, what you are looking for is referred to as the geodesic distance: http://www.vterrain.org/Misc/distance.html To do this accurately (and you may not need much accuracy!) on an ellipsoid requires a fair bit of math. I don't know if it's built in to OGR or PROJ at this point, but there are a few libraries out that that do it, including Gerald I. Evenden's geodesic lib, which can be found here: http://home.comcast.net/~gevenden56/geodesy/project/ -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ 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?
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/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
[gdal-dev] Re: gdal_rasterize with a NetCDF file?
Selon Scott Lewis scott.le...@nsidc.org:
You've got the main point, but the meaning of '+' is a bit more subtle. The '+'
indicates in fact support for the Create() method. Some drivers support updating
existing datasets (like DTED for example), or CreateCopy() (translating entire
existing dataset to the new format) but not the Create() method itself.
I realize that many drivers are missing code to error out with proper message if
they are requested to open the dataset in update mode, but they don't support
it. It's done properly in some (GIF, JPEG, PNG, ...), but not in netCDF,
I'll try to improve that.
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):
{
[gdal-dev] ERROR 6: SetNoDataValue() not supported for this dataset.
Hi, In this example I get the (apparently innocuous) error message below. The file is correctly converted, but why is it complaining? gdal_translate w020n40.Bathymetry.srtm lixo.tiff ERROR 6: SetNoDataValue() not supported for this dataset. Input file size is 4800, 6000 0...10...20...30...40...50...60...70...80...90...100 - done. w020n40.Bathymetry.hdr BYTEORDER M LAYOUTBIL NROWS 6000 NCOLS 4800 NBANDS1 NBITS 16 PIXELTYPE SIGNEDINT BANDROWBYTES 9600 TOTALROWBYTES 9600 BANDGAPBYTES 0 NODATA-32768 ULXMAP-19.99583 ULYMAP39.99583 XDIM 0.008 YDIM 0.008 Joaquim Luis ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ERROR 6: SetNoDataValue() not supported for this dataset.
Selon Joaquim Luis jl...@ualg.pt: I can't reproduce your issue with trunk, nor can I understand how it can happen. This error message is thrown when a driver doesn't implement the SetNoDataValue() method. But the GTiff driver has supported it for ages. Hi, In this example I get the (apparently innocuous) error message below. The file is correctly converted, but why is it complaining? gdal_translate w020n40.Bathymetry.srtm lixo.tiff ERROR 6: SetNoDataValue() not supported for this dataset. Input file size is 4800, 6000 0...10...20...30...40...50...60...70...80...90...100 - done. w020n40.Bathymetry.hdr BYTEORDER M LAYOUTBIL NROWS 6000 NCOLS 4800 NBANDS1 NBITS 16 PIXELTYPE SIGNEDINT BANDROWBYTES 9600 TOTALROWBYTES 9600 BANDGAPBYTES 0 NODATA-32768 ULXMAP-19.99583 ULYMAP39.99583 XDIM 0.008 YDIM 0.008 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] ERROR 6: SetNoDataValue() not supported for this dataset.
Yes, strange it is. I'm using trunk as well (from yesterday) but I don't get it when I use FWTools. Even weirder, I used GTiff just as an easy example but the original place where I saw it is with my gdalread MEX, which only reads a dataset and does not attempt to write it anywhere. Even Rouault wrote: Selon Joaquim Luis jl...@ualg.pt: I can't reproduce your issue with trunk, nor can I understand how it can happen. This error message is thrown when a driver doesn't implement the SetNoDataValue() method. But the GTiff driver has supported it for ages. Hi, In this example I get the (apparently innocuous) error message below. The file is correctly converted, but why is it complaining? gdal_translate w020n40.Bathymetry.srtm lixo.tiff ERROR 6: SetNoDataValue() not supported for this dataset. Input file size is 4800, 6000 0...10...20...30...40...50...60...70...80...90...100 - done. w020n40.Bathymetry.hdr BYTEORDER M LAYOUTBIL NROWS 6000 NCOLS 4800 NBANDS1 NBITS 16 PIXELTYPE SIGNEDINT BANDROWBYTES 9600 TOTALROWBYTES 9600 BANDGAPBYTES 0 NODATA-32768 ULXMAP-19.99583 ULYMAP39.99583 XDIM 0.008 YDIM 0.008 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] ERROR 6: SetNoDataValue() not supported for this dataset.
Selon Joaquim Luis jl...@ualg.pt: Very weird. In such cases, I'd recommand a 'make clean; make', especially if you've hacked your tree. If it still continues afterwards, you'll have to set a breakpoint in GDALRasterBand::SetNoDataValue() and see what calls it. Yes, strange it is. I'm using trunk as well (from yesterday) but I don't get it when I use FWTools. Even weirder, I used GTiff just as an easy example but the original place where I saw it is with my gdalread MEX, which only reads a dataset and does not attempt to write it anywhere. Even Rouault wrote: Selon Joaquim Luis jl...@ualg.pt: I can't reproduce your issue with trunk, nor can I understand how it can happen. This error message is thrown when a driver doesn't implement the SetNoDataValue() method. But the GTiff driver has supported it for ages. Hi, In this example I get the (apparently innocuous) error message below. The file is correctly converted, but why is it complaining? gdal_translate w020n40.Bathymetry.srtm lixo.tiff ERROR 6: SetNoDataValue() not supported for this dataset. Input file size is 4800, 6000 0...10...20...30...40...50...60...70...80...90...100 - done. w020n40.Bathymetry.hdr BYTEORDER M LAYOUTBIL NROWS 6000 NCOLS 4800 NBANDS1 NBITS 16 PIXELTYPE SIGNEDINT BANDROWBYTES 9600 TOTALROWBYTES 9600 BANDGAPBYTES 0 NODATA-32768 ULXMAP-19.99583 ULYMAP39.99583 XDIM 0.008 YDIM 0.008 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
[gdal-dev] CEOS issues on WinXP
Hi all, Opening ALOS AVNIR-2 PRISM (CEOS format) images using GDAL is really slow and uses loads of memory on Windows XP. This includes things like gdalinfo and opening via the python bindings (gdal.Open()). I've tried (on WinXP) with various gdal installs (fwtools, osgeo4w, basic binaries) and same issue. Is anybody else experiencing this, is this a bug that I should log? Below is an example using gdalinfo on an ALOS PRISM image on WinXP linux. Testdata is from: http://www.ga.gov.au/remote-sensing/get-satellite-imagery-data/product-s amples.jsp Regards Luke Pinner Example: **Windows XP (32 bit)** C:\ gdalinfo --version GDAL 1.6.2, released 2009/07/31 C:\ gdalinfo U:\work\testdata\alos_prism\ceos_02041_02b\product\scene01\img-alpsmb021 733905-o1b2g_ub Driver: CEOS/CEOS Image Files: U:\work\testdata\alos_prism\ceos_02041_02b\product\scene01\img-alpsmb021 733905-o1b2g_ub U:\work\testdata\alos_prism\ceos_02041_02b\product\scene01\img-alpsmb021 733905-o1b2g_ub.aux.xml Size is 18855, 17086 Coordinate System is `' Corner Coordinates: Upper Left (0.0,0.0) Lower Left (0.0,17086.0) Upper Right (18855.0,0.0) Lower Right (18855.0,17086.0) Center ( 9427.5, 8543.0) Band 1 Block=18855x1 Type=Byte, ColorInterp=Undefined Min=1.000 Max=255.000 Minimum=1.000, Maximum=255.000, Mean=69.835, StdDev=18.376 NoData Value=0 Metadata: STATISTICS_MINIMUM=1 STATISTICS_MAXIMUM=255 STATISTICS_MEAN=69.834780742218 STATISTICS_STDDEV=18.375728841108 Takes: 111 seconds Peak mem usage: 636 Mb **Ubuntu 9.04 (64 bit)** $ gdalinfo --version GDAL 1.6.2, released 2009/07/31 $ gdalinfo /data/work/testdata/alos_prism/ceos_02041_02b/product/scene01/img-alpsmb 021733905-o1b2g_ub Driver: CEOS/CEOS Image Files: /data/work/testdata/alos_prism/ceos_02041_02b/product/scene01/img-alpsmb 021733905-o1b2g_ub /data/work/testdata/alos_prism/ceos_02041_02b/product/scene01/img-alpsmb 021733905-o1b2g_ub.aux.xml Size is 18855, 17086 Coordinate System is `' Corner Coordinates: Upper Left (0.0,0.0) Lower Left (0.0,17086.0) Upper Right (18855.0,0.0) Lower Right (18855.0,17086.0) Center ( 9427.5, 8543.0) Band 1 Block=18855x1 Type=Byte, ColorInterp=Undefined Min=1.000 Max=255.000 Minimum=1.000, Maximum=255.000, Mean=69.835, StdDev=18.376 NoData Value=0 Metadata: STATISTICS_MINIMUM=1 STATISTICS_MAXIMUM=255 STATISTICS_MEAN=69.834780742218 STATISTICS_STDDEV=18.375728841108 Takes: 1.4 seconds Peak mem usage: 0.6 Mb (ps -o rss) -- If you have received this transmission in error please notify us immediately by return e-mail and delete all copies. If this e-mail or any attachments have been sent to you in error, that error does not constitute waiver of any confidentiality, privilege or copyright in respect of information in the e-mail or attachments. Please consider the environment before printing this email. -- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
