Re: [gdal-dev] [Geotiff] libgeotiff 1.7.2 release candidate

oops. Here are the corrected URLs: https://download.osgeo.org/geotiff/libgeotiff/libgeotiff-1.7.2rc1.tar.gz https://download.osgeo.org/geotiff/libgeotiff/libgeotiff-1.7.2rc1.zip Le 21/05/2024 à 15:44, Greg Troxel via Geotiff a écrit : Even Rouault via Geotiff writes: do you mean

Re: [gdal-dev] GeoTiff with ColorInterp=Palette

Le 20/02/2024 à 11:15, Elena Ruiz via gdal-dev a écrit : Hello, I have version 3.6.2 of GDAL and I need to crop an image using a contour from a GML file, so far there is no problem. The problem begins when the original image is a GEOTIFF with transparency and it generates a cropped image,

[gdal-dev] GeoTiff with ColorInterp=Palette

Hello, I have version 3.6.2 of GDAL and I need to crop an image using a contour from a GML file, so far there is no problem. The problem begins when the original image is a GEOTIFF with transparency and it generates a cropped image, the information of both images is a little lower. The color

Re: [gdal-dev] GeoTiff JXL sample format & bits per sample restrictions?

JXL in tiff should support the 2 band case correctly. What is not supported here is the int16 datatype. Only uint8, uint16 and float32 are supported. TB On Fri, Feb 9, 2024 at 3:32 PM Meyer, Jesse R. (GSFC-618.0)[SCIENCE SYSTEMS AND APPLICATIONS INC] via gdal-dev wrote: > We are trying to

Re: [gdal-dev] GeoTiff JXL sample format & bits per sample restrictions?

could you share the output of "gdalinfo in.tif" please? On Fri, Feb 9, 2024 at 3:32 PM Meyer, Jesse R. (GSFC-618.0)[SCIENCE SYSTEMS AND APPLICATIONS INC] via gdal-dev wrote: > We are trying to convert a 2 band int16 ZSTD compressed geotiff to JXL > compression. However for each band the

[gdal-dev] GeoTiff JXL sample format & bits per sample restrictions?

We are trying to convert a 2 band int16 ZSTD compressed geotiff to JXL compression. However for each band the following error message is given “ERROR 1: GetJXLDataType:Unsupported combination of SampleFormat and BitsPerSample”. On GDAL 3.8.3, released 2024/01/04. JXL v0.9.2 gdal_translate

Re: [gdal-dev] GeoTIFF and concurrent block reads

On Thu, Sep 21, 2023, at 18:05, Even Rouault wrote: > >> Of course, but I'm asking if it's worth calling ReadBlock on multiple >> threads (if it always takes a lock, it's not, and I should use RasterIO >> instead). > Not on the same dataset object, otherwise you'll get crashes as no lock is >

Re: [gdal-dev] GeoTIFF and concurrent block reads

Of course, but I'm asking if it's worth calling ReadBlock on multiple threads (if it always takes a lock, it's not, and I should use RasterIO instead). Not on the same dataset object, otherwise you'll get crashes as no lock is taken (*) I think these can also be implemented at VSI level by

Re: [gdal-dev] GeoTIFF and concurrent block reads

Hi, On Thu, Sep 21, 2023, at 17:02, Even Rouault wrote: > Laurentiu, > >> >> GDAL 3.6 added support for multi-threaded reading using PRead, but I >> couldn't spot ReadBlock using the same code path. > If you read one single block at a time, the multi-threaded optimization > cannot kick in,

Re: [gdal-dev] GeoTIFF and concurrent block reads

Laurentiu, GDAL 3.6 added support for multi-threaded reading using PRead, but I couldn't spot ReadBlock using the same code path. If you read one single block at a time, the multi-threaded optimization cannot kick in, since the elementary decoding unit is a block. You must call RasterIO()

[gdal-dev] GeoTIFF and concurrent block reads

Hello, GDAL 3.6 added support for multi-threaded reading using PRead, but I couldn't spot ReadBlock using the same code path. On the other hand, I didn't see it taking a lock either, so I'm a little confused :-). My question is whether ReadBlock supports concurrent reads or not (*). (*) I

Re: [gdal-dev] GeoTIFF gdalwarp puzzle

. -Jukka Rahkonen- Lähettäjä: gdal-dev Puolesta Carl Godkin Lähetetty: perjantai 5. marraskuuta 2021 17.36 Vastaanottaja: gdal-dev@lists.osgeo.org Aihe: Re: [gdal-dev] GeoTIFF gdalwarp puzzle ...And it works fine for me in 3.4.0 as well. Guess I just got unlucky with the GDAL 3.3.x series! Th

Re: [gdal-dev] GeoTIFF gdalwarp puzzle

Processing Caribbean 2 VFR Chart.tif [1/1] : >>> 0...10...20...30...40...50...60...70...80...90...100 - done. >>> >>> >>> >>> The map in caribbean_4326.tif is complete. >>> >>> >>> >>> -Jukka Rahkonen- >>> >

Re: [gdal-dev] GeoTIFF gdalwarp puzzle

.30...40...50...60...70...80...90...100 - done. >> >> >> >> The map in caribbean_4326.tif is complete. >> >> >> >> -Jukka Rahkonen- >> >> >> >> *Lähettäjä:* gdal-dev *Puolesta *Carl >> Godkin >> *Lähetetty:*

Re: [gdal-dev] GeoTIFF gdalwarp puzzle

ka Rahkonen- > > > > *Lähettäjä:* gdal-dev *Puolesta *Carl > Godkin > *Lähetetty:* perjantai 5. marraskuuta 2021 16.25 > *Vastaanottaja:* gdal-dev@lists.osgeo.org > *Aihe:* [gdal-dev] GeoTIFF gdalwarp puzzle > > > > Hi, > > > > I'm working with some aviation

Re: [gdal-dev] GeoTIFF gdalwarp puzzle

bean 2 VFR Chart.tif [1/1] : 0...10...20...30...40...50...60...70...80...90...100 - done. The map in caribbean_4326.tif is complete. -Jukka Rahkonen- Lähettäjä: gdal-dev Puolesta Carl Godkin Lähetetty: perjantai 5. marraskuuta 2021 16.25 Vastaanottaja: gdal-dev@lists.osgeo.org Aihe: [gdal-de

[gdal-dev] GeoTIFF gdalwarp puzzle

Hi, I'm working with some aviation charts and found one that behaves in a puzzling manner. This page https://www.faa.gov/air_traffic/flight_info/aeronav/digital_products/vfr/ has two Caribbean VFR charts in GeoTIFF format. I have been trying to run gdalwarp on "Caribbean 2 VFR Chart.tif" but I

Re: [gdal-dev] GeoTIFF: connection between CRS WKT and GeoKeys

Le 13/10/2021 à 18:35, Eric Robeck a écrit : I have a question about which GeoTIFF tags should be used for storing CRS information. I have two GeoTIFFs: one original and the same file saved as a COG. Then I created gdalinfo and listgeo reports for each and compared them for changes.

[gdal-dev] GeoTIFF: connection between CRS WKT and GeoKeys

I have a question about which GeoTIFF tags should be used for storing CRS information. I have two GeoTIFFs: one original and the same file saved as a COG. Then I created gdalinfo and listgeo reports for each and compared them for changes. *gdalinfo*: Aside from the difference in the PROJCRS

Re: [gdal-dev] GeoTiff writer refuses to set 42113 (NoData) from Python

Hi, There is a common belief that problems with images happen only with exactly that confidential multigigabyte image that user is playing with. That is uncommon and usually the problem can be repeated with any other image with similar structure. If you have GDAL v. 3.2 you can use

[gdal-dev] GeoTiff writer refuses to set 42113 (NoData) from Python

Hey devs, I have an issue where writing any GeoTiff from python results in ERROR 1: TIFFSetField:Path/To/File: Unknown tag 42113 This happens regardless of warp or translate (the only two applicable tools for my use case) However, running this through the CLI tools with the exact same inputs

Re: [gdal-dev] [Geotiff] libgeotiff 1.6.0 release soon

On lundi 20 avril 2020 13:39:50 CEST Sebastiaan Couwenberg wrote: > On 4/20/20 12:15 PM, Even Rouault wrote: > > In preparation for the upcoming GDAL 3.1.0 release, I intend to prepare a > > libgeotiff 1.6.0 release later this week. I believe things are in good > > shape, but if people want to

Re: [gdal-dev] [Geotiff] libgeotiff 1.6.0 release soon

On 4/20/20 12:15 PM, Even Rouault wrote: > In preparation for the upcoming GDAL 3.1.0 release, I intend to prepare a > libgeotiff 1.6.0 release later this week. I believe things are in good shape, > but > if people want to give it a quick try to master, that's welcome. Will there be an RC

Re: [gdal-dev] GeoTIFF: embedd JPEG without recompression

Am Fr, 2.11.2018, 18:40 schrieb Even Rouault: > > Yes, this is limited to a single JPEG file as a source (not a VRT of > several JPEG files for example), and if you use -co COMPRESS=JPEG > without an explicit -co QUALITY setting. -co TILED=YES is supported. Yeeks, it also gets

Re: [gdal-dev] GeoTIFF: embedd JPEG without recompression

On vendredi 2 novembre 2018 17:33:07 CET Tobias Wendorff wrote: > Hi there, > > can "gdal_translate" embedd a JPEG file in TIFF without recompression? Yes, this is limited to a single JPEG file as a source (not a VRT of several JPEG files for example), and if you use -co COMPRESS=JPEG without

[gdal-dev] GeoTIFF: embedd JPEG without recompression

Hi there, can "gdal_translate" embedd a JPEG file in TIFF without recompression? Best regards, Tobias ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] GeoTIFF NoData

Hi all, Sorry if my question has been discussed here before. I followed 1 Answer/Option 2 of this post to convert an image (GeoTIFF) external pixels RGB(255,255,255) to NoData. So, I used

Re: [gdal-dev] Geotiff FillEmptyTiles with no data value?

Le mercredi 06 juillet 2016 16:17:32, Daniele Romagnoli a écrit : > Hi Even, > thanks I'm already using the SPARSE_OK=TRUE to create an empty tiff > and afterwards warp input files on that with SKIP_NOSOURCE=YES. > I have already updated the ImageIO-EXT's TIFFImageReader to deal with > tile/strip

Re: [gdal-dev] Geotiff FillEmptyTiles with no data value?

Hi Even, thanks I'm already using the SPARSE_OK=TRUE to create an empty tiff and afterwards warp input files on that with SKIP_NOSOURCE=YES. I have already updated the ImageIO-EXT's TIFFImageReader to deal with tile/strip with zero byte count. Final question: Starting from which GDAL version,

Re: [gdal-dev] Geotiff FillEmptyTiles with no data value?

Daniele, > has this improvement also being backported on previous versions (as an > instance 2.1.x, 2.0.x)? No, trunk only. You could as well use the SPARSE_OK=TRUE creation option to avoid writting blocks at all. Provided that your reader knows how to deal with tile/strips with a 0 byte

Re: [gdal-dev] Geotiff FillEmptyTiles with no data value?

Hi Even, has this improvement also being backported on previous versions (as an instance 2.1.x, 2.0.x)? Cheers, Daniele On Tue, May 10, 2016 at 3:29 PM, Even Rouault wrote: > Le mardi 10 mai 2016 09:22:19, jramm a écrit : > > Hi > > I have made changes to

Re: [gdal-dev] Geotiff FillEmptyTiles with no data value?

Le mardi 10 mai 2016 09:22:19, jramm a écrit : > Hi > I have made changes to FillEmptyTiles so that if nodata is set, then it > will always fill with nodata, otherwise 0. > > I have attached the raw diff...I have no idea how to submit a change > request/review etc? > > fillempty_nodata.diff >

Re: [gdal-dev] Geotiff FillEmptyTiles with no data value?

Hi I have made changes to FillEmptyTiles so that if nodata is set, then it will always fill with nodata, otherwise 0. I have attached the raw diff...I have no idea how to submit a change request/review etc? fillempty_nodata.diff

Re: [gdal-dev] Geotiff FillEmptyTiles with no data value?

Le vendredi 06 mai 2016 13:33:36, jramm a écrit : > NoDataValue is set on a band level and FillEmptyTiles operates at a dataset > level. > > I've never heard of a geotiff with different nodata per band - is this even > possible, or would it be reasonable to take the nodatavalue of the 1st band >

Re: [gdal-dev] Geotiff FillEmptyTiles with no data value?

NoDataValue is set on a band level and FillEmptyTiles operates at a dataset level. I've never heard of a geotiff with different nodata per band - is this even possible, or would it be reasonable to take the nodatavalue of the 1st band and use this to initialise the empty tiles block? Then there

Re: [gdal-dev] Geotiff FillEmptyTiles with no data value?

Le mardi 03 mai 2016 20:23:49, jramm a écrit : > Hi > > When writing geotiffs, if I dont write blocks they will automatically be > filled on close by the FillEmptyTiles. > It appears that this will only fill with zeros - is it possible to make it > fill with the no data value instead? You can

[gdal-dev] Geotiff FillEmptyTiles with no data value?

Hi When writing geotiffs, if I dont write blocks they will automatically be filled on close by the FillEmptyTiles. It appears that this will only fill with zeros - is it possible to make it fill with the no data value instead? This is potentially a huge time saver when processing a large, fairly

Re: [gdal-dev] GeoTiff 16bit to 8bit with GDAL 11.x

Le jeudi 14 avril 2016 22:48:23, Christine Waigl a écrit : > Hi Even, > > Thanks so much for this quick and thorough response. The workaround made it > possible to fix my code, and I've extended it to multi-band GeoTIFF files > (my RGB composites) as > > gdal_translate -ot Byte -of vrt -b 1 -b 1

Re: [gdal-dev] GeoTiff 16bit to 8bit with GDAL 11.x

Hi Even, Thanks so much for this quick and thorough response. The workaround made it possible to fix my code, and I've extended it to multi-band GeoTIFF files (my RGB composites) as gdal_translate -ot Byte -of vrt -b 1 -b 1 -b 2 -b 3 -scale_4 -scale_1 -scale_2 -scale_3 infile.tif infile_8bit.vrt

Re: [gdal-dev] GeoTiff 16bit to 8bit with GDAL 11.x

Le mercredi 13 avril 2016 22:26:45, Christine Waigl a écrit : > Hi all, > > I have been using the GDAL command line tools to pre-process various kinds > of remote sensing imagery datasets in GeoTIFF format. This includes > resampling 16 bit images (eg. from Landsat 8) to 8-bit and to combine

[gdal-dev] GeoTiff 16bit to 8bit with GDAL 11.x

Hi all, I have been using the GDAL command line tools to pre-process various kinds of remote sensing imagery datasets in GeoTIFF format. This includes resampling 16 bit images (eg. from Landsat 8) to 8-bit and to combine bands into RBG composites. In GDAL 11.4 (and previous 11.x that I tried),

[gdal-dev] GeoTIFF with non-meter linear unit in SRS

Hi, I've pushed in trunk per https://trac.osgeo.org/gdal/ticket/6210 a fix to hopefully address issues when reading GeoTIFF files whose SRS uses non-meter linear units (such as us-foot). I'd appreciate if people could confirm it doesn't break existing use cases, and hopefully fix cases that

[gdal-dev] Geotiff client side

Hi WCS has the ability to return a coverage as a GeoTiff file. Then if you want to display or process row data from this file in a Javascript web client, you need to have to ability to decode the GeoTiff part of this file. I found a Tiff.js library compiled with Emscripten. I succeed to

Re: [gdal-dev] Geotiff client side

Hi Xavier, there is a couple of options with WCS 2. - you can request another format which is easier to handle by the client, such as PNG (builtin browser support). - you can send a separate DescibeCoverage request and get an XML structure containing all metadata. - you can direct the

Re: [gdal-dev] Geotiff nodata handling

Even Rouault even.rouault at mines-paris.org writes: This is a rather tricky area indeed. A few facts : - The concept of nodata value in GDAL is something per band, which leave multi-band processing of nodata values subject to interpretation. - The TIFFTAG_GDAL_NODATA extension tag in

[gdal-dev] Geotiff nodata handling

Hi, I'm trying to wrap my head around how gdal handles nodata values. In an image with this gdalinfo exceprt: Band 1 Block=512x512 Type=Byte, ColorInterp=Red NoData Value=0 Band 2 Block=512x512 Type=Byte, ColorInterp=Green NoData Value=0 Band 3 Block=512x512 Type=Byte, ColorInterp=Blue

Re: [gdal-dev] Geotiff nodata handling

Le mercredi 18 juin 2014 18:35:49, Andrea Aime a écrit : Hi, I'm trying to wrap my head around how gdal handles nodata values. In an image with this gdalinfo exceprt: Band 1 Block=512x512 Type=Byte, ColorInterp=Red NoData Value=0 Band 2 Block=512x512 Type=Byte, ColorInterp=Green

Re: [gdal-dev] GeoTiff crashing qgis

David Strip gdal at stripfamily.net writes: At the moment I'm at a loss as to where to start looking for the problem. Any suggestions are most welcome. Send us links to the images you have created with GDAL and which make troubles with QGIS. Perhaps someone finds what is wrong in these images.

Re: [gdal-dev] geotiff projection not showing up

On Nov 10, 2013 1:44 AM, Even Rouault even.roua...@mines-paris.org wrote: Le dimanche 10 novembre 2013 00:14:42, Trent Piepho a écrit : I've found that unless you call SetGeoTransform() and give an affine transform, most apps, including listgeo and gdalsrsinfo, aren't entirely happy with

Re: [gdal-dev] geotiff projection not showing up

Frank and Trent, I have created a proper GeoTIFF file with the code listed, below. There is still one oddity: The code sets the line/sample -- x/y affine transformation using an array of 6 doubles. The code contains a conditional compilation that chooses between two different arrays of 6

Re: [gdal-dev] geotiff projection not showing up

Le lundi 11 novembre 2013 20:46:47, Norman Goldstein a écrit : Frank and Trent, I have created a proper GeoTIFF file with the code listed, below. There is still one oddity: The code sets the line/sample -- x/y affine transformation using an array of 6 doubles. The code contains a

Re: [gdal-dev] geotiff projection not showing up

Le dimanche 10 novembre 2013 00:14:42, Trent Piepho a écrit : On Sat, Nov 9, 2013 at 1:07 PM, Norman Goldstein norm...@telus.net wrote: Things are better, now, but not quite there for me. Still not able to transform pixel/line to PCS space. (the listgeo dump is, below) I think the

Re: [gdal-dev] geotiff projection not showing up

Frank, Things are better, now, but not quite there for me. Still not able to transform pixel/line to PCS space. (the listgeo dump is, below) I think the problem is that there is no definition of the ModelPixelScaleTag It seems that this tag, together with the ModelTiepointTag, is how an

Re: [gdal-dev] geotiff projection not showing up

On Sat, Nov 9, 2013 at 1:07 PM, Norman Goldstein norm...@telus.net wrote: Things are better, now, but not quite there for me. Still not able to transform pixel/line to PCS space. (the listgeo dump is, below) I think the problem is that there is no definition of the ModelPixelScaleTag It

Re: [gdal-dev] geotiff projection not showing up

Norman, My apologies. The GCP projection is actually supposed to be passed as the third value in the SetGCPs call - where you have passed the string Richmond. Instead pass the whole WKT strings for the coordinate system. Best regards, Frank On Wed, Nov 6, 2013 at 4:00 PM, Norman Goldstein

[gdal-dev] geotiff projection not showing up

I have created a geotiff file using the GTiff driver, and have successfully set options for it to be a strips file with no compression. Also, successfully called the functions dataset-SetMetadataItem( AREA_OR_POINT, Point,

Re: [gdal-dev] geotiff projection not showing up

Norman, I believe you want to call SetGCPProjection() instead of SetProjection() when using GCPs instead of an affine transform. Best regards, Frank On Wed, Nov 6, 2013 at 1:23 PM, Norman Goldstein norm...@telus.net wrote: I have created a geotiff file using the GTiff driver, and have

Re: [gdal-dev] geotiff projection not showing up

Frank, I am using GDAL Version : 1.9.2 so maybe that is why I do not see the method SetGCPProjection(). I think you have convinced me, though, to calculate the 6 coefficients directly, and then call SetGeoTransform(). Will let you guys know how this works out for me. Thank you, Norm

[gdal-dev] GeoTIFF and LZWDecode (LZWEncode?) errors

Hi When batch processing GeoTIFF files, I tend to get this problem a bit too often: Warning 1: LZWDecode:LZWDecode: Strip 11 not terminated with EOI code ERROR 1: LZWDecode:Not enough data at scanline 11 (short 30 bytes) ERROR 1: TIFFReadEncodedStrip() failed. band 1: IReadBlock failed at X

Re: [gdal-dev] GeoTIFF and LZWDecode (LZWEncode?) errors

Casper, I'm not sure to have understood if you have this problem while reading or generating compressed files. Could you provide a way (that is to say provide both the input data and the command line used) of reproducing this ? Best regards, Even Hi When batch processing GeoTIFF files, I

Re: [gdal-dev] GeoTIFF and LZWDecode (LZWEncode?) errors

ERRORLEVEL 1 or similar even though the process cannot continue. Kind regards, Casper -Original Message- From: Even Rouault [mailto:even.roua...@mines-paris.org] Sent: 11. juli 2013 15:40 To: Casper Børgesen (CABO) Cc: gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] GeoTIFF

Re: [gdal-dev] GeoTIFF and LZWDecode (LZWEncode?) errors

: Re: [gdal-dev] GeoTIFF and LZWDecode (LZWEncode?) errors Casper, I'm not sure to have understood if you have this problem while reading or generating compressed files. Could you provide a way (that is to say provide both the input data and the command line used) of reproducing

Re: [gdal-dev] GeoTIFF with LZW compression Overviews error

Frank, I'm assuming you mean gdaladdo is run on y.tif, the output of gdalwarp, right? Yes, sorry, that's what I meant. I tried the steps with a manufactured input file of the same size and did not encounter the problem on my system. The most likely important difference is that I am not using

[gdal-dev] GeoTIFF with LZW compression Overviews error

Dear devs, I'm experiencing strange errors when I try to add overviews to specific GeoTIFF files with internal tiling and LZW compression. This error shows only on some (about 3-5%) of the input files. This is how I process the file: $gdal_translate -gcp 0 0 19.09 49.22 -gcp 100 0 20.1

Re: [gdal-dev] GeoTIFF with LZW compression Overviews error

Fabian, I'm assuming you mean gdaladdo is run on y.tif, the output of gdalwarp, right? I tried the steps with a manufactured input file of the same size and did not encounter the problem on my system. The most likely important difference is that I am not using libtiff 3.9.4 - I'm using libtiff

[gdal-dev] GeoTiff ProjectedCSTypeGeoKey SIRGAS2000 31983

Ivan, Do you know the correct specification of GeoTiff's ProjectedCSTypeGeoKey for SIRGAS2000 EPSG: 31983? I get Unknown-31983 with gdal utility programs. Thanks, Reinaldo Escada Chohfi Sócio Gerente GeoDesign Internacional www.geodesign.com.br

Re: [gdal-dev] GeoTiff ProjectedCSTypeGeoKey SIRGAS2000 31983

Have you look at [http://spatialreference.org/ref/epsg/31983/] ? ---Original Message--- From: reina...@geodesign.com.br To: Ivan Lucena ivan.luc...@princeton-ma.us, gdal-dev gdal-dev@lists.osgeo.org Subject: GeoTiff ProjectedCSTypeGeoKey SIRGAS2000 31983 Sent: Dec 21 '12

Re: [gdal-dev] GeoTiff ProjectedCSTypeGeoKey SIRGAS2000 31983

On 21/12/2012 15:49, reina...@geodesign.com.br wrote: Ivan, Do you know the correct specification of GeoTiff's ProjectedCSTypeGeoKey for SIRGAS2000 EPSG: 31983? I get Unknown-31983 with gdal utility programs. Thanks, GDAL knows this system : $ epsg_tr.py 31983 PROJCS[SIRGAS 2000 / UTM

[gdal-dev] geotiff

Hi Can anyone tell me how to display geotiff image in a dotspatial map using c#. With Regards, Neelima Emmani ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] geotiff

Neelima, Please refer to the DotSpatial docs at http://dotspatial.codeplex.com/documentation On Thu, Sep 27, 2012 at 5:26 PM, Neelima Emmani neelima.emm...@iictechnologies.com wrote: Hi Can anyone tell me how to display geotiff image in a dotspatial map using c#. With Regards, Neelima

Re: [gdal-dev] geotiff

, September 28, 2012 8:33 AM To: Neelima Emmani Cc: gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] geotiff Neelima, Please refer to the DotSpatial docs at http://dotspatial.codeplex.com/documentation On Thu, Sep 27, 2012 at 5:26 PM, Neelima Emmani neelima.emm

[gdal-dev] geoTiff to tiles

I am working with 2gb large geotiff image.I need convert the large geoTiff to tiles (about 250x250 pixels) with c++ language; i dont wanna read the whole geotiff file since it is gonna be real slow .. i want to get the tiles according to geographic position and i am not sure exactly how to do it

Re: [gdal-dev] geotiff conflict

Hello, As it seems like the gdal 1.8 debian package is not out yet, maybe there is still some time left to tackle this issue for the next gdal debian package. To sum up the current situation when reading TIFF files with gdal : - this program :

Re: [gdal-dev] geotiff conflict

Le mardi 26 avril 2011 18:36:45, Julien Malik a écrit : Hello, As it seems like the gdal 1.8 debian package is not out yet, maybe there is still some time left to tackle this issue for the next gdal debian package. To sum up the current situation when reading TIFF files with gdal : -

Re: [gdal-dev] geotiff conflict

On Tue, Apr 26, 2011 at 07:55:00PM +0200, Even Rouault wrote: What can we do to help find a solution (what kind of modification to the gdal debian package would you agree to make to solve this issue) ? I'm not sure the solution is really in the debian packaging... There are indeed very

Re: [gdal-dev] geotiff conflict

Hi Even, Quoting Even Rouault even.roua...@mines-paris.org: Le mardi 26 avril 2011 18:36:45, Julien Malik a écrit : Hello, As it seems like the gdal 1.8 debian package is not out yet, maybe there is still some time left to tackle this issue for the next gdal debian package. To sum up the

Re: [gdal-dev] geotiff conflict

All this comes from the fact that Orfeo Toolbox has ossim as one of its main dependency, and ossim handles TIFF via libgeotiff and not via gdal. For example : http://trac.osgeo.org/ossim/browser/trunk/ossim/src/ossim/support_data/ossi mGeoTiff.cpp which makes extensive use of the geotiff

Re: [gdal-dev] geotiff conflict

Quoting Francesco P. Lovergine fran...@debian.org: On Tue, Apr 26, 2011 at 07:55:00PM +0200, Even Rouault wrote: What can we do to help find a solution (what kind of modification to the gdal debian package would you agree to make to solve this issue) ? I'm not sure the solution is really in

Re: [gdal-dev] geotiff conflict

On Tue, Apr 26, 2011 at 09:39:21PM +0200, MALIK Julien wrote: Here we go: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#id293268 of course this is a possibile solution to avoid symbol collision among different libraries. It is not a os-independent solution even,

[gdal-dev] GeoTiff and the 4th band

Hello I have a problem with the geotiff (GTiff) driver. I create a 4-bands raster image in a c++ program. The fourth band was considered as an alpha band in the geotiff image (actually, it is near infrared : NIR) $ gdalinfo new_geotiff.tif Driver: GTiff/GeoTIFF Files: new__geotiff.tif Size is

Re: [gdal-dev] GeoTiff and the 4th band

Selon Nicolas Mayer nmayer31...@gmail.com: Retry by setting the PHOTOMETRIC creation option to MINISBLACK. Otherwise, by default, without specifying it, GDAL assumes that the PHOTOMETRIC is RGB and that the 4th band is an alpha band. You should get : Band 1 Block=100x20 Type=Byte,

Re: [gdal-dev] GeoTiff and the 4th band

Even, thank you very much for answering me so quicly With the PHOTOMETRIC creation option to MINISBLACK, I get now : Band 1 Block=100x20 Type=Byte, ColorInterp=Gray Band 2 Block=100x20 Type=Byte, ColorInterp=Undefined Band 3 Block=100x20 Type=Byte, ColorInterp=Undefined Band 4 Block=100x20

Re: [gdal-dev] GeoTiff and the 4th band

Selon Nicolas Mayer nmayer31...@gmail.com: Even, thank you very much for answering me so quicly With the PHOTOMETRIC creation option to MINISBLACK, I get now : Band 1 Block=100x20 Type=Byte, ColorInterp=Gray Band 2 Block=100x20 Type=Byte, ColorInterp=Undefined Band 3 Block=100x20 Type=Byte,

Re: [gdal-dev] GeoTiff and the 4th band

Even, Thank you very much ! With the two creation options : PHOTOMETRIC=RGB and ALPHA=NO, I obtain the same behaviour I whish. Can you explain me where you found this answer ? (to help me to become more autonomous with GDAL) Thank you again Nicky 2011/4/18 Even Rouault

Re: [gdal-dev] GeoTiff and the 4th band

Selon Nicolas Mayer nmayer31...@gmail.com: Even, Thank you very much ! With the two creation options : PHOTOMETRIC=RGB and ALPHA=NO, I obtain the same behaviour I whish. Can you explain me where you found this answer ? (to help me to become more autonomous with GDAL) Well, for an

Re: [gdal-dev] GeoTiff and the 4th band

OK. Thank you very much. Nicky 2011/4/18 Even Rouault even.roua...@mines-paris.org Selon Nicolas Mayer nmayer31...@gmail.com: Even, Thank you very much ! With the two creation options : PHOTOMETRIC=RGB and ALPHA=NO, I obtain the same behaviour I whish. Can you explain me where

[gdal-dev] GeoTIFF to Shapefile

Hello, I have GeoTIFF files and need to get a shapefile with the contour of each one. The aim of this conversion is to display on a world map the areas which I have satellite images using a WMS service with MapServer. What free tool can I use? Best regards.

Re: [gdal-dev] GeoTIFF to Shapefile

Hi Emilio, I think you could use the gdaltindex tool: http://www.gdal.org/gdaltindex.html Hope this helps. Regards, Daniele 2011/3/24 Emilio de Torres Fernández emilio.detor...@fueca.es Hello, I have GeoTIFF files and need to get a shapefile with the contour of each one. The aim of this

[gdal-dev] geotiff conflict

Hello, I'm reviving an already known problem about the gdal packages for Ubuntu/Debian, related to the use of the hide-internal-symbols configure option. To sum it up, we get into troubles with the gdal packages since we also use the geotiff API. Until recently, we knew only about a

Re: [gdal-dev] geotiff conflict

Julien, To be fair, I think that --with-hide-internal-symbols just does what it advertizes : it hides GDAL internal symbols (internal libtiff, internal libgeotiff) to applications that link with libgdal. I mean that they cannot use those symbols (if they only link to libgdal). The advantage is

Re: [gdal-dev] geotiff conflict

Even, I am working with Julien on the same project, and you are right about the --hide-internal-symbols option : if symbols are not hidden, we recognize that gdal exposes tiff symbols and we manage to deal with this case by forcing all tiff access to use gdal internal tiff library (we have

Re: [gdal-dev] geotiff conflict

Hello Even, Thank you for your answer. Le 29/11/2010 15:51, Even Rouault a écrit : Julien, To be fair, I think that --with-hide-internal-symbols just does what it advertizes : it hides GDAL internal symbols (internal libtiff, internal libgeotiff) to applications that link with libgdal. I mean

[gdal-dev] Geotiff with bands of different type

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I'm using gdal/python and I would like to create geotiffs using one band of bytes and one of float32s... Is this even possible ? Thanks, Martin -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora

Re: [gdal-dev] Geotiff with bands of different type

Martin, Yes, it is possible. You can specify the data type in GDALDataset::AddBand() On Tue, Aug 10, 2010 at 12:44 PM, Martin Raspaud martin.rasp...@smhi.sewrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I'm using gdal/python and I would like to create geotiffs using one band

Re: [gdal-dev] Geotiff with bands of different type

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chaitanya kumar CH skrev: Martin, I'm sorry. I just found out that GDALDataset::AddBand() is not supported by most format drivers. GeoTiff format driver doesn't support it. Also, having different data types for bands may confuse some

[gdal-dev] GeoTiff null values

Hi List, I'm running tests with GDAL 1.7 and python for achieving a function for the sum of GeoTIFF file. I found some difficulty in handling null values. I wanted to know if you can assign a specific value (like 99) to null when I call the Open function. The code is as follows: # Open

Re: [gdal-dev] GeoTiff null values

Filippo, Please note that those values are called nodata values. Nodata value is assigned a specific value during the creation of the raster and all the pixels where data is unavailable are assigned that value. Using the python interface, you can find the specified value with GetNoDataValue().

Re: [gdal-dev] Geotiff AREA_OR_POINT

Am I correct in interpreting this post to mean that the pixel-is-area and pixel-is-point tiffs are read the exact same way by GDAL, with the only difference being in the value of the AREA_OR_POINT metadata key? Should viewers then be looking for the AREA_OR_POINT key in addition to the

Re: [gdal-dev] Geotiff AREA_OR_POINT

On 28-06-2010 23:21, Michael Sumner wrote: Am I correct in interpreting this post to mean that the pixel-is-area and pixel-is-point tiffsare read the exact same way by GDAL, with the only difference being in the value of theAREA_OR_POINT metadata key? Should viewers then be looking forthe

Re: [gdal-dev] Geotiff AREA_OR_POINT

Thanks for the heads up, I've not used GMT versions of NetCDF much, or recently. The vast majority of NetCDF I've had to work with do not make this explicit, and this is about the most detailed discussion I've seen: http://www.mail-archive.com/cf-metad...@cgd.ucar.edu/msg00566.html Cheers, Mike.

  1   2   >