On Feb 8, 2010, at 9:10 PM, Frank Warmerdam wrote:
> It would be nice if the dates of source code in the distribution files
> were based on the date of last change; however, that is not how our
> release preparation steps work. I don't see it as desirable enough to try
> and figure out how to cha
Greg Coats wrote:
Upon further investigation, I am left puzzled why the 25 Jan 2010 version of
frmts/jp2kak/jp2kakdataset.cpp, that was successfully updated & enhanced by
Frank, is not included in GDAL 1.7.1 RC1, particularly since the 27 Jan 2010
version (note: that is 2 days later) of swig/pyth
Indeed I do!
The fixed & enhanced code for frmts/jp2kak/jp2kakdataset.cpp was actually
available before GDAL 1.7.0 was released, but Frank elected not to include it,
and I was given assurances at that time by Frank that the fixed
jp2kakdataset.cpp would be include in the next release of GDAL. GD
Upon further investigation, I am left puzzled why the 25 Jan 2010 version of
frmts/jp2kak/jp2kakdataset.cpp, that was successfully updated & enhanced by
Frank, is not included in GDAL 1.7.1 RC1, particularly since the 27 Jan 2010
version (note: that is 2 days later) of swig/python/scripts/gdal_m
On Feb 8, 2010, at 8:12 PM, Greg Coats wrote:
> otherwise people will have to wait until GDAL 1.7.2 before being able to use
> it.
I don't see the relaxing of this as any reason to hold up the release. In
fact, one could argue this is a new feature just as easily and should be
targeted at 1
I'm now getting a test failure in the PDS driver. Looks like r18694 - I guess
1.7.1 also needs a new autotest package.
On Feb 8, 2010, at 1:58 PM, Frank Warmerdam wrote:
> Folks,
>
> I have prepared a GDAL/OGR 1.7.1 release candidate at:
>
> http://download.osgeo.org/gdal/gdal171RC1.zip
> h
Frank,
Thanks for preparing this GDAL 1.7.1 Release Candidate 1.
I observe that line 2578 of frmts/jp2kak/jp2kakdataset.cpp has the old
needlessly restrictive
if( dfQuality < 1.0 || dfQuality > 100.0 )
even though you had replaced that restriction on or before 25 Jan 2010 with the
less restrictiv
Stefan Keller wrote:
Dear Frank, dear all
I have a question reading in a DXF file which is an official test data
set from the Swiss Federal Office of Topography (swisstopo) available
here: http://tinyurl.com/rimini-testdata . When I try to import the
data I get an error:
ogrinfo rimtestgp.dxf
Peter Rankor wrote:
List,
I need to rasterize a polygon layer coming from a SHP file. However, the
values in the outputraster need to be the FID of the corresponding polygon.
My command:
gdal_rasterize -a FID -l FECS FECS.shp flattenedRaster.tif
Peter,
Could you try:
gdal_rasterize -a FID
Thanks a lot!!!
It was crucial - to expand color table to RGB! After that everything
works perfect.
Once again: big thank you!
Ralf Wagner
Chaitanya kumar CH pisze:
From what Ed said, editing the color table is useless. Try to expand
the tiff to rgb and proceed from there. At least the error
Motion: The GDAL/OGR 1.7.1 RC1 release candidate is promoted to a full
release, and the GDAL/OGR 1.7.0 release is retracted due to the serious
bug with Erdas Imagine file creation (http://trac.osgeo.org/gdal/ticket/3382)
---
Folks,
As previously discussed, I think bug 3382 is a serious regressi
Folks,
I have prepared a GDAL/OGR 1.7.1 release candidate at:
http://download.osgeo.org/gdal/gdal171RC1.zip
http://download.osgeo.org/gdal/gdal171.zip.md5
http://download.osgeo.org/gdal/gdal-1.7.1RC1.tar.gz
http://download.osgeo.org/gdal/gdal-1.7.1.tar.gz.md5
Feedback is welcome, though
>From what Ed said, editing the color table is useless. Try to expand the
tiff to rgb and proceed from there. At least the error message should
change. ;-)
On Mon, Feb 8, 2010 at 8:52 PM, Grissom, Edward (Ed) <
ed.gris...@intergraph.com> wrote:
>
> Are you aware that the TIFF (and GeoTIFF) spec d
List,
I need to rasterize a polygon layer coming from a SHP file. However, the
values in the outputraster need to be the FID of the corresponding polygon.
My command:
gdal_rasterize -a FID -l FECS FECS.shp flattenedRaster.tif
I get:
Failed to find field FID on layer FECS, skipping.
And the prog
Ralf,
Your tif files seem to use color tables. You may be able to edit the color
table to represent RGBA instead of RGB with A value set to 0 for nodata and
1 elsewhere. I don't know much about handling the color tables.
If you don't want to deal color tables, use the -expand option in
gdal_trans
Unfortunately I have absolutely no idea how to deal with this
transparency problem - all my trials failed.
I am experimenting on four properly referenced GeoTiff, overlapping
files with white margins.
My (temporary) goal was to obtain ONE GeoTIFF file from these FOUR
source files - but, of cours
Peder,
You can try to prepare a 'fake' large file from an existing smaller file by
using the gdal_translate utility with the -outsize 200% 200% option. You can
play with the value of the scale to give you an appropriate size.
On Mon, Feb 8, 2010 at 3:26 PM, Peder Axensten wrote:
> Are there any
Are there any larger (>2 Gbyte sizes) raster test files to test extremes on?
I've found files in various data directories in
http://trac.osgeo.org/gdal/browser/trunk/, but they all seem to be rather small?
I'm trying to interest Lemke Software to use GDAL in their GraphicConverter.
There doesn't
Hi,
Now,I have a .tif file(it is a satallite photo),How to get the heightmap of it?
Kind regards.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
19 matches
Mail list logo
