Perfect, thanks! That worked for both gdalinfo and for derived data
via CreateCopy().
-Mike
On 2 June 2011 21:21, Even Rouault wrote:
> Le jeudi 02 juin 2011 00:54:48, Mike Toews a écrit :
>> I'm struggling to understand why both the aux.xml file and output from
>> gdalinfo are really bulky in f
On 02/06/11 20:32, Even Rouault wrote:
Le jeudi 02 juin 2011 20:28:42, Andrés Maneiro a écrit :
Thanks Even for the response, I suppose it has to do with your
suggestions, but I don't know why, as I don't see any compression
algorithm within gdalinfo output :/
ok, so it is well NBITS = 1 and a
Ah, by the way, your suggestion generates an output 10 times shorter.
Smart guess :) But I'd like to generate a file more or less equal than
input to not loose quality.
Other thing that is weird for a newbie as me, is that the gdalinfo for
the output tiff is the same (even Size parameter!) apa
Le jeudi 02 juin 2011 20:28:42, Andrés Maneiro a écrit :
> Thanks Even for the response, I suppose it has to do with your
> suggestions, but I don't know why, as I don't see any compression
> algorithm within gdalinfo output :/
ok, so it is well NBITS = 1 and actually uncompressed, and with 64x64
Thanks Even for the response, I suppose it has to do with your
suggestions, but I don't know why, as I don't see any compression
algorithm within gdalinfo output :/
Here the output of gdalinfo on the original tiff:
Driver: GTiff/GeoTIFF
Files: 120135.tif
Size is 12261, 9595
Coordinate System i
Le jeudi 02 juin 2011 20:00:15, Andrés Maneiro a écrit :
> Hello devs,
>
> I'm playing with GDAL to set the CRS of a set of geotiff files I was
> given to upload them to geoserver later.
>
> These files, were generated using ArcGIS and it seems that the CRS set
> in the geotiff file header is not
Hello devs,
I'm playing with GDAL to set the CRS of a set of geotiff files I was
given to upload them to geoserver later.
These files, were generated using ArcGIS and it seems that the CRS set
in the geotiff file header is not standar (at least, my geoserver
doesn't recognize them). What I d
On Wed, Jun 1, 2011 at 1:08 PM, Anton Korosov wrote:
> we are developing software for automatic processing of satellite data and
> decided to base it mostly on GDAL-Python bindings. Can I ask you about
> options to create Warped VRT datasets in Python?
At my script, I'm just assembling VRT code f
Your blind guess was perfect!!
Thank you, that did it.
Jerl
On Thu, Jun 2, 2011 at 6:43 AM, Even Rouault
wrote:
> Jerl,
>
> Difficult to say without seing the data and the exact BuildPolygonFromEdges
> you
> invoke...
>
> A blind guess would be to increase the value of the tolerance parameter.
Hi Frank, RSyaoxin, Knut-Frode,
Il 16/05/2011 19:48, Antonio Valentino ha scritto:
> Il 16/05/2011 18:38, Frank Warmerdam ha scritto:
>> On 11-05-16 12:30 PM, Antonio Valentino wrote:
>>> An alternative solution is to write from scratch the routines for
>>> decoding of ENVISAT records but this is
Jerl,
Difficult to say without seing the data and the exact BuildPolygonFromEdges you
invoke...
A blind guess would be to increase the value of the tolerance parameter.
Best regards,
Even
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://list
Hi:
I'm having a weird issue that I'm hoping someone can shed some light
on for me. I have a python script that reads through a CSV file and
builds a couple ESRI Shapefiles from it. I'm generating 2 geometries,
POLYGON and LINESTRING. LINESTRING works great but POLYGON fails when
points are "ne
Rui,
> Hello everyone,
>
> the ESRI shape driver allows feature removal for layers with update
> access OGRLayer::DeleteFeature.
>
> After successful removal of a feature and sync to disk, the method
> OGRLayer::GetFeatureCount still returns the same number, as before the
> deletion.
>
> Actual
Hello everyone,
the ESRI shape driver allows feature removal for layers with update
access OGRLayer::DeleteFeature.
After successful removal of a feature and sync to disk, the method
OGRLayer::GetFeatureCount still returns the same number, as before the
deletion.
Actually, the number of records
Le jeudi 02 juin 2011 00:54:48, Mike Toews a écrit :
> I'm struggling to understand why both the aux.xml file and output from
> gdalinfo are really bulky in file size for my GeoTIFFs. First, output
> from gdalinfo on a 375 KB GeoTIFF file has 196664 lines:
>
> Driver: GTiff/GeoTIFF
> Files: HorizB
Le jeudi 02 juin 2011 09:22:37, Antonio Valentino a écrit :
> Hi Even,
>
> Il 01/06/2011 13:58, Even Rouault ha scritto:
> > Selon Antonio Valentino :
> >>> Yes, with Dataset.Create() by specifying a SUBCLASS=VRTWarpedDataset
> >>> creation option. ... But I don't think it will help you much since
Hi Even,
Il 01/06/2011 13:58, Even Rouault ha scritto:
> Selon Antonio Valentino :
>>> Yes, with Dataset.Create() by specifying a SUBCLASS=VRTWarpedDataset
>>> creation option. ... But I don't think it will help you much since the
>>> GDALInitializeWarpedVRT() that is then used by gdalwarp to fill
17 matches
Mail list logo
