[gdal-dev] can't open grib2 files
Dear All, I am not able to open grib2 files with GDAL. For example, in the attached file http://rapidshare.com/files/249911240/MPE_20090629_0900_M9_00.rar.html I succeed in obtaining information about the file with GDALINFO command, but I cannot convert it into a GTiff (using gdal_translate command). I obtain the following message: Input file size is 3712, 3712 0Segmentation fault I know this file is not corrupted because I can open it with another software. What am I doing wrong? Thank you -- Alberto Pettazzi MeteoGalicia - Departamento de Climatología y Observación Consellería de Medio Ambiente, Territorio e Infraestruturas Rúa de Roma, 6 15707 Santiago de Compostela. A Coruña Teléfono: +34-881-999646 e-mail: alberto.petta...@meteogalicia.es mailto:alberto.petta...@meteogalicia.es ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] including GCP file for gdal_translate
Hi, I am trying to layer stack 7 bands from Raw landsat image. I have been provided with 7 tif files one for each band (with no proj) A separate GCP file (.txt) with nearly 90 GCPs has been provided too. I want to input all the GCPs into gdal_translate. I am using FWTools to work with gdal. Is there any option to do so? Narmadha ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] including GCP file for gdal_translate
Narmadha, gdal_translate cannot 'stack' multiple images into one. One way is to use gdal_merge.py with the -seperate option to create a single tif file and then use gdal_translate to intorduce the projection with the GCPs. To make it easy to mention the GCPs to gdal_translate you could use --optfile (refer http://www.gdal.org/gdal_utilities.html) to edit the GCP file into the required format ( [-gcp pixel line easting northing [elevation]]* ). On Mon, Jun 29, 2009 at 5:18 PM, NarmadhaK narmadh...@gmail.com wrote: Hi, I am trying to layer stack 7 bands from Raw landsat image. I have been provided with 7 tif files one for each band (with no proj) A separate GCP file (.txt) with nearly 90 GCPs has been provided too. I want to input all the GCPs into gdal_translate. I am using FWTools to work with gdal. Is there any option to do so? Narmadha ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev Best regards, -- Chaitanya kumar CH. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re:[FWTools] GDALRasterizeGeometries() and Python
Hi Frank and GDAL-dev team, By reading the following message and unsuccessfully searching for documentation and possibilities to rasterize geometries, I would be pleased to know if the Python bindings for GDALRasterizeGeometries() are still somehow planned. If no bindings are planned is there another work-around than invoking the utilities from the shell to mask raster data from vector data, within gdal or within numpy (after ReadAsArray) ? Best regards, Matthieu --- Travis, I have checked, and can confirm that the rasterize geometries function is not currently exposed in Python at all. I've been adding bindings for some other algorithms this week, and I'll look at adding one for this too, though I think it may be a bit tricky. Best regards, On Wed, Sep 17, 2008 at 11:39 AM, Travis Kirstine traviskirstine at gmail.com wrote: I'm was hoping to use GDALRasterizeGeometries() from the gdal_agl.h file with python to burn polygons from PostGIS into a geotiff. I don't believe that there are python binding available, am I correct? -- Travis K. Toronto, Canada ___ FWTools mailing list FWTools at lists.maptools.org http://lists.maptools.org/mailman/listinfo/fwtools http://fwtools.maptools.org/ RapidEye AG Molkenmarkt 30 14776 Brandenburg an der Havel Germany Follow us on Twitter! www.twitter.com/rapideye_ag Head Office/Sitz der Gesellschaft: Brandenburg an der Havel Management Board/Vorstand: Wolfgang G. Biedermann Chairman of Supervisory Board/Vorsitzender des Aufsichtsrates: Axel Schmalz Commercial Register/Handelsregister Potsdam HRB 17 796 Tax Number/Steuernummer: 048/100/00053 VAT-Ident-Number/Ust.-ID: DE 199331235 DIN EN ISO 9001 certified * Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet. The information in this e-mail is intended for the named recipients only. It may contain privileged and confidential information. If you have received this communication in error, any use, copying or dissemination of its contents is strictly prohibited. Please erase all copies of the message along with any included attachments and notify RapidEye AG or the sender immediately by telephone at the number indicated on this page. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re:[FWTools] GDALRasterizeGeometries() and Python
Matthieu Rigal wrote: Hi Frank and GDAL-dev team, By reading the following message and unsuccessfully searching for documentation and possibilities to rasterize geometries, I would be pleased to know if the Python bindings for GDALRasterizeGeometries() are still somehow planned. If no bindings are planned is there another work-around than invoking the utilities from the shell to mask raster data from vector data, within gdal or within numpy (after ReadAsArray) ? Matthieu, It appears that the only rasterization entry point provided through the swig bindings is RasterLayer which rasterizes from an OGR feature layer. This is available in 1.6. You can see an example of it's use in: http://svn.osgeo.org/gdal/branches/1.6/autotest/alg/rasterize.py I do not have any plans to add a lower level GDALRasterizeGeometries at this time. 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
Re: [gdal-dev] can't open grib2 files
Hi Scott,
thank you for your reply! I just have executed the command you suggested me,
gdal-config --formats
and that's what I got:
gxf gtiff hfa aigrid aaigrid ceos ceos2 iso8211 xpm sdts raw dted mem
jdem envisat elas fit vrt usgsdem l1b nitf bmp pcidsk airsar rs2 ilwis
rmf leveller sgi srtmhgt idrisi gsg ingr ers jaxapalsar dimap gff cosar
pds adrg coasp tsx terragen blx msgn wcs wms grib bsb jpeg2000 hdf5 hdf4
gif jpeg png netcdf pcraster rik
So, I guess that I have already built the jpeg2000 support. Any Suggestion?
Alberto Pettazzi
MeteoGalicia - Departamento de Climatología y Observación
Consellería de Medio Ambiente, Territorio e Infraestruturas
Rúa de Roma, 6
15707 Santiago de Compostela. A Coruña
Teléfono: +34-881-999646
e-mail: alberto.petta...@meteogalicia.es
mailto:alberto.petta...@meteogalicia.es
Scott Sinclair escribió:
2009/6/29 Alberto Pettazzi alberto.petta...@meteogalicia.es:
I am not able to open grib2 files with GDAL. For example, in the attached
file
http://rapidshare.com/files/249911240/MPE_20090629_0900_M9_00.rar.html
I succeed in obtaining information about the file with GDALINFO command, but
I cannot convert it into a GTiff (using gdal_translate command). I obtain
the following message:
Input file size is 3712, 3712
0Segmentation fault
I know this file is not corrupted because I can open it with another
software. What am I doing wrong?
Hi Alberto,
GRIB2 files can be compressed using different encoding schemes, the
GDAL page here (http://www.gdal.org/frmt_grib.html) says
There are several encoding schemes for raster data in GRIB format.
Most common ones should be supported including PNG encoding. JPEG2000
encoded GRIB files will generally be supported if GDAL is also built
with JPEG2000 support via one of the GDAL JPEG2000 drivers. The JasPer
library generally provides the best jpeg2000 support for the GRIB
driver.
It doesn't look like JPEG2000 support is built by default
(http://www.gdal.org/formats_list.html), so you might need to build
your own GDAL, if you want to read these files using GDAL. You could
start by checking whether your GDAL has been built with JPEG2000
support ('gdal-config --formats' on the command line).
An alternative to access the data is wgrib2
(http://www.cpc.ncep.noaa.gov/products/wesley/wgrib2/), which I've
used in the past to read the Meteosat precipitation product you're
dealing with.
Cheers,
Scott
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] OGR API for ESRI Shapefile writer
Hi All,
I was trying to create a shapefile using the code below:
It looks like though the fieldnames are getting created but the values
(I tried just one row) are not getting created:
OGRRegisterAll();
OGRSFDriver *poDriver =
OGRSFDriverRegistrar::GetRegistrar()-GetDriverByName(ESRI Shapefile);
OGRDataSource *poDS = poDriver-CreateDataSource(point_out.shp,
0);
OGRLayer *poLayer = poDS-CreateLayer(point_out, 0, wkbPoint, 0);
OGRFieldDefn oField1(Longitude, OFTReal);
OGRFieldDefn oField2(Latitude, OFTReal);
OGRFieldDefn oField3(Speed, OFTReal);
if(poLayer-CreateField(oField1) != OGRERR_NONE)
{
std::cout creation of Longitude failed std::endl;
exit(1);
}
if(poLayer-CreateField(oField2) != OGRERR_NONE)
{
std::cout creation of Latitude failed std::endl;
exit(1);
}
if(poLayer-CreateField(oField3) != OGRERR_NONE)
{
std::cout creation of Speed failed std::endl;
exit(1);
}
OGRFeature *poFeature = OGRFeature::CreateFeature(
poLayer-GetLayerDefn() );
poFeature-SetField(Longitude, 1.1);
poFeature-SetField(Latitude, 2.2);
poFeature-SetField(Speed, 3.3);
if( poLayer-CreateFeature( poFeature ) != OGRERR_NONE )
{
std::cout Failed to create feature in shapefile
std::endl;
exit( 1 );
}
OGRFeature::DestroyFeature( poFeature );
Am I missing something basic here ?
Thanks,
Chandra
**
This communication contains information which is confidential and may also be
legally privileged. It is for the exclusive use of the intended recipient(s).
If you are not the intended recipient(s), disclosure, copying, distribution, or
other use of, or action taken or omitted to be taken in reliance upon, this
communication or the information in it is prohibited and maybe unlawful. If you
have received this communication in error please notify the sender by return
email, delete it from your system and destroy any copies.
**
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] OGR API for ESRI Shapefile writer
Almost perfect, but you've made a classical error : you've just forgotten to
properly close the dataset with OGRDataSource::DestroyDataSource( poDS );
Quoting http://gdal.org/ogr/ogr_apitut.html: Finally we need to close down
the datasource in order to ensure headers are written out in an orderly way
and all resources are recovered.
I'll mention it in the doc of OGRSFDriver::CreateDataSource() for the sake of
completeness.
Le Monday 29 June 2009 19:54:45 Chandra Shekhar Kumar, vous avez écrit :
OGRRegisterAll();
OGRSFDriver *poDriver =
OGRSFDriverRegistrar::GetRegistrar()-GetDriverByName(ESRI Shapefile);
OGRDataSource *poDS = poDriver-CreateDataSource(point_out.shp,
0);
OGRLayer *poLayer = poDS-CreateLayer(point_out, 0, wkbPoint, 0);
OGRFieldDefn oField1(Longitude, OFTReal);
OGRFieldDefn oField2(Latitude, OFTReal);
OGRFieldDefn oField3(Speed, OFTReal);
if(poLayer-CreateField(oField1) != OGRERR_NONE)
{
std::cout creation of Longitude failed std::endl;
exit(1);
}
if(poLayer-CreateField(oField2) != OGRERR_NONE)
{
std::cout creation of Latitude failed std::endl;
exit(1);
}
if(poLayer-CreateField(oField3) != OGRERR_NONE)
{
std::cout creation of Speed failed std::endl;
exit(1);
}
OGRFeature *poFeature = OGRFeature::CreateFeature(
poLayer-GetLayerDefn() );
poFeature-SetField(Longitude, 1.1);
poFeature-SetField(Latitude, 2.2);
poFeature-SetField(Speed, 3.3);
if( poLayer-CreateFeature( poFeature ) != OGRERR_NONE )
{
std::cout Failed to create feature in shapefile
std::endl;
exit( 1 );
}
OGRFeature::DestroyFeature( poFeature );
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
RE: [gdal-dev] OGR API for ESRI Shapefile writer
-Original Message- From: Even Rouault [mailto:even.roua...@mines-paris.org] Almost perfect, but you've made a classical error : you've just forgotten to properly close the dataset with OGRDataSource::DestroyDataSource( poDS ); Quoting http://gdal.org/ogr/ogr_apitut.html: Finally we need to close down the datasource in order to ensure headers are written out in an orderly way and all resources are recovered. [Chandra ] It worked like a magic! It was my fault that I didn't read the tutorial completely :( though it was hardly 2-3 pages and complete in all sense. Thanks a lot Even! Regards, Chandra ** This communication contains information which is confidential and may also be legally privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), disclosure, copying, distribution, or other use of, or action taken or omitted to be taken in reliance upon, this communication or the information in it is prohibited and maybe unlawful. If you have received this communication in error please notify the sender by return email, delete it from your system and destroy any copies. ** ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL WKT Raster Driver weekly report #5
Jorge Arévalo wrote: Hello, This is the report #5 of GDAL WKT Raster driver: http://www.gis4free.org/blog/2009/06/27/gsoc-09-weekly-report-5-1906-2606/ The project can be followed here: http://trac.osgeo.org/gdal/wiki/WKTRasterDriver Jorge, I appologise for not staying on top of my mentoring duties. I am reviewing the design document at: http://www.gis4free.org/blog/wp-content/uploads/2009/06/gdal-wktrasterdriver-spec-0.2.pdf Is this still the most current version of your design? I see Even, Mateusz, Pierre and others have provided some feedback. Their comments seem good. I would also support the suggestion to put the design in a more malliable form, such that others can contribute more directly - such as a trac wiki page. I also think the design needs some further updates from the 0.2 version. I notice you have your own trac now, though it does not seem to have any public access which I think is unfortunate. Don't hesitate to keep the design in the GDAL trac. I would like design to better address the relationship between WKTRaster's data model and the GDAL data model. So, for instance, you might note things like: 1) The fPixelSizeX, fPixelSizeY, fUpperLeftX, fUpperLeftY, fRotationX, fRotationY values will become the GeoTransform in GDAL, possibly noting how the transformation will take place. Actually, the f* fields I note are actually on a single WKTRaster objects after fetching and instead you really need to populate the Geotransform based on the extent, pixelsize_x and pixelsize_y fields from the RASTER_COLUMNS table and that for now only north up images will be supported (unrotated). 2) Note that WKTRaster uses an SRID lookup into the spatial_ref_sys which may contain WKT and PROJ.4 representations of a coordinate system, but that GDAL needs WKT. Note perhaps that the spatial_ref_sys lookup code from the OGR PG driver can be used essentially unchanged, and that things only get messy when there is a need to create new rasters as it is sometimes hard to establish what SRID to use for a given WKT (or whether to create a new one), but that this matter can also be done using the same approach as the OGR PG driver. -- In general I was surprised to find no mention of the RASTER_COLUMNS table and the implications for the WKTRaster driver. To a significant extent this table was defined to make it easier to write the WKTRaster driver. It encapsulates a concept of simplistic rasters that can be easily mapped onto the GDAL data model and that can be efficiently manipulated by GDAL. I would like the design talk about steps in implementation. The first complete step should be a read-only driver that supports regular_blocking type images defined via RASTER_COLUMNS. I would hope this would be accomplished by the mid-term review. After that some additions you could work on are: 1) Supporting rasters that are not regular_blocking. I think it will be hard to make this really efficient, but it is definately doable. 2) Support in place update for existing rasters. 3) Support creating new rasters. 4) Support access to overviews. 5) Support outdb rasters. I would like a sense of which of these you hope to do this summer, in what order, and what you see as the issues with them. I would personally be quite happy if you did a bulletproof and efficient implementation of read-only access to WKTRasters with overviews and all applicable metadata and access to outdb rasters. Make sure the project plan includes time to extend the python test suite with tests for the WKTRaster driver, and to write up user driver documentation. -- ---+-- 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] Re: running gdal_merge for a lot of files
I had the problem when running the gdal_mergey.py with many tiles using the * parameter. But using the --optfile options resolves this for me. I had also problems constructing big images from many tiles, I did a partitioning on the the tile set and merged in an iterative manner. WolfgangZ writes: Frank Warmerdam schrieb: Pavel Iacovlev wrote: Good day all, I am trying to merge a large data set, the input imagery is 1TB RGB uncompressed tifs (lots of them). Then I run gdal_merge.py on a small data set it runs ok and with -v option I can see whats happening. But then I run on a large dataset I don't get no verbose output (I don't get no output at all) and it stuck on 8.9 GB image size. I can just track that the image is getting bigger but not verbose output whatsoever and I can tell why it stops on 8.9 GB. My command is: gdal_merge.py -v -init 255 -of GTiff -co TILED=YES -co COMPRESS=JPEG -co PHOTOMETRIC=YCBCR -co BIGTIFF=YES -o of.tif of/*.tif The input images are around 160mb each so loading them 1 by 1 into memory is not a problem. Pavel, I don't know what is going wrong. I would suggest adding lots of print statements in the gdal_merge.py script to try and establish where it is freezing up. Best regards, wasn't there once a problem with the number of files that are joined? Or was this only when adding the files manually at the command line (not using the * operator). Wolf ___ 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] GDAL WKT Raster Driver weekly report #5
Hello Frank, 2009/6/30 Frank Warmerdam warmer...@pobox.com Jorge Arévalo wrote: Hello, This is the report #5 of GDAL WKT Raster driver: http://www.gis4free.org/blog/2009/06/27/gsoc-09-weekly-report-5-1906-2606/ The project can be followed here: http://trac.osgeo.org/gdal/wiki/WKTRasterDriver Jorge, I appologise for not staying on top of my mentoring duties. I am reviewing the design document at: http://www.gis4free.org/blog/wp-content/uploads/2009/06/gdal-wktrasterdriver-spec-0.2.pdf Is this still the most current version of your design? I see Even, Mateusz, Pierre and others have provided some feedback. Their comments seem good. Don't worry. As you said, this is not the current version. Even, Mateusz, Tamas... and myself, have commented a lot of things that must be added. I would also support the suggestion to put the design in a more malliable form, such that others can contribute more directly - such as a trac wiki page. I also think the design needs some further updates from the 0.2 version. I notice you have your own trac now, though it does not seem to have any public access which I think is unfortunate. Don't hesitate to keep the design in the GDAL trac. OK. I'll use the GDAL trac to create a web version with more information. I would like design to better address the relationship between WKTRaster's data model and the GDAL data model. So, for instance, you might note things like: 1) The fPixelSizeX, fPixelSizeY, fUpperLeftX, fUpperLeftY, fRotationX, fRotationY values will become the GeoTransform in GDAL, possibly noting how the transformation will take place. Actually, the f* fields I note are actually on a single WKTRaster objects after fetching and instead you really need to populate the Geotransform based on the extent, pixelsize_x and pixelsize_y fields from the RASTER_COLUMNS table and that for now only north up images will be supported (unrotated). 2) Note that WKTRaster uses an SRID lookup into the spatial_ref_sys which may contain WKT and PROJ.4 representations of a coordinate system, but that GDAL needs WKT. Note perhaps that the spatial_ref_sys lookup code from the OGR PG driver can be used essentially unchanged, and that things only get messy when there is a need to create new rasters as it is sometimes hard to establish what SRID to use for a given WKT (or whether to create a new one), but that this matter can also be done using the same approach as the OGR PG driver. -- In general I was surprised to find no mention of the RASTER_COLUMNS table and the implications for the WKTRaster driver. To a significant extent this table was defined to make it easier to write the WKTRaster driver. It encapsulates a concept of simplistic rasters that can be easily mapped onto the GDAL data model and that can be efficiently manipulated by GDAL. I would like the design talk about steps in implementation. The first complete step should be a read-only driver that supports regular_blocking type images defined via RASTER_COLUMNS. I would hope this would be accomplished by the mid-term review. After that some additions you could work on are: 1) Supporting rasters that are not regular_blocking. I think it will be hard to make this really efficient, but it is definately doable. 2) Support in place update for existing rasters. 3) Support creating new rasters. 4) Support access to overviews. 5) Support outdb rasters. I would like a sense of which of these you hope to do this summer, in what order, and what you see as the issues with them. I would personally be quite happy if you did a bulletproof and efficient implementation of read-only access to WKTRasters with overviews and all applicable metadata and access to outdb rasters. Make sure the project plan includes time to extend the python test suite with tests for the WKTRaster driver, and to write up user driver documentation. Understood. Since now, I'm working on an extended version of the document (1.0 this time), describing more in detail all the work, including your comments, and any other information that can be useful. Many thanks for your comments, I'll keep you (and the list) informed. Best regards Jorge -- ---+-- 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
