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 https://dow

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, the

[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 ta

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 conve

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 followi

[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 -ot

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 w

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, sin

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 thin

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

.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ä

Re: [gdal-dev] GeoTIFF gdalwarp puzzle

-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-dev] GeoTIFF gdalwarp puzzle > > > > Hi, > > > > I'm working with som

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 on

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. *gdalinf

[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 citati

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 https://gdal.

[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 r

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 give

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 befor

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 "jpeg:sampling-facto

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 an

[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 t

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 w

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, SPAR

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 count

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 FillEmptyTiles so that if nodata is set

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 > a

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 als

[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 bands

[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), th

[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 did

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 serv

[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 disp

Re: [gdal-dev] Geotiff nodata handling

Even Rouault 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 TIFF only ho

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 >

[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 NoDat

[gdal-dev] geotiff false easting/northing unit nuisance

Hello, I am trying to have GDAL play nice with some geotiff aerial images, and I have an issue with the way the units are handled on the false easting/northing parameters. The images use the California State Plane projection (zone 2), in feet, not meters, i.e.: http://spatialreference.org/

Re: [gdal-dev] GeoTiff crashing qgis

David Strip 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. Next

[gdal-dev] GeoTiff crashing qgis

I have a piece of C++ code that is clipping regions from a very large (roughly 90,000 x 100,000 pixels, 11G compressed) Float32 gray-scale single band image and writing each as a separate GeoTiff (with LZW compression). In the sample that I've run, I've clipped four different regions. gdalinfo can

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

Le jeudi 14 novembre 2013 21:24:01, Trent Piepho a écrit : > On Nov 10, 2013 1:44 AM, "Even Rouault" > > 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 listge

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

On Nov 10, 2013 1:44 AM, "Even Rouault" 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 the georeferencing.

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

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 d

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 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

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

On Sat, Nov 9, 2013 at 1:07 PM, Norman Goldstein 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 seems that

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 affine

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

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 O

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 wrote: > I have created a geotiff file using the "GTiff" driver, and have > successfully set o

[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 and LZWDecode (LZWEncode?) errors

1. juli 2013 15:40 > To: Casper Børgesen (CABO) > Cc: gdal-dev@lists.osgeo.org > Subject: 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 yo

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

oesn't set 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-d

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

[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 offs

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

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 4

[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 49.11

Re: [gdal-dev] GeoTiff ProjectedCSTypeGeoKey SIRGAS2000 31983

Reinaldo, It is a known system, at least in trunk. Possibly your libgeotiff support files are somewhat antique or not being found? Best regards, Frank On Fri, Dec 21, 2012 at 6:49 AM, wrote: > Ivan, > > Do you know the correct specification of GeoTiff's ProjectedCSTypeGeoKey for > SIRGAS2000

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 20

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 , gdal-dev > > Subject: GeoTiff ProjectedCSTypeGeoKey SIRGAS2000 31983 > Sent: Dec 21 '12 09:49 > > Ivan, > > Do you know the correct

[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 (http://ww

Re: [gdal-dev] geotiff

nt: Friday, 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 mailto:neelima.emm...@iictechno

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, >

[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

[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

Note that it will sacrify binary compatibility against casual builds. You will need to build against the Debian version of GDAL, not third parties builds. For casual builds, we have another solution : don't use hide-internal-symbols, and install the tiff/geotiff headers from gdal source tree

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 so

Re: [gdal-dev] geotiff conflict

Quoting "Francesco P. Lovergine" : 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 pac

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 geoti

Re: [gdal-dev] geotiff conflict

Hi Even, Quoting Even Rouault : 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

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

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

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 : http://hg.orfeo-toolbox.org/OTB/file/1e0e2f87aa5

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

OK. Thank you very much. Nicky 2011/4/18 Even Rouault > Selon Nicolas Mayer : > > > 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 t

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

Selon Nicolas Mayer : > 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 advanced question lik

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 > Selon Nicolas Maye

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

Selon Nicolas Mayer : > 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=Und

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 Type=By

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

Selon Nicolas Mayer : 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, ColorInterp=Gray Band 2 Block=100x20

[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 10

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 > 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

[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 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

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 to

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 tha

[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 proble

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

To be more precise, Band.SetOffset() and Band.SetScale() do exist, but they are recent additions only available in the development version (1.8.0dev). Le mardi 10 août 2010 15:30:54, Chaitanya kumar CH a écrit : > Martin, > > Python methods do exist. > Refer to > http://trac.osgeo.org/gdal/brows

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

Martin, Python methods do exist. Refer to http://trac.osgeo.org/gdal/browser/trunk/autotest/gcore/tiff_write.py for some Python examples of these four methods. On Tue, Aug 10, 2010 at 6:27 PM, Martin Raspaud wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Frank Warmerdam skrev: > >

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frank Warmerdam skrev: > On Tue, Aug 10, 2010 at 7:16 AM, Martin Raspaud > wrote: >> Hmmm, that sounds like a sufficient solution indeed, very good idea, thanks. >> >> Is there any scale/slope and offset/intercept tags defined in geotiff ? > > Marti

  1   2   >