- Mensaje reenviado -
De: David Ortiz
Para: "chaitanya...@gmail.com"
Enviado: Miércoles, febrero 8, 2012 12:12 A.M.
Asunto: Re: [gdal-dev] HDF-EOS AIRS CO2 images without georeference using
gdal_translate
Hi Chaitanya,
I have some questions:
1. Is there some way to get the resi
Hi All,
Gdal 1.9 fails to open Esri Personal geodatabase file (.mdb) in some cases.
The new PGeo driver looks into the header of the file for the GDB_GeomColumns
table (http://trac.osgeo.org/gdal/changeset/21550) and cannot find it due to (I
assume) the limited size of the header allocated (100Kb
On Tue, Feb 7, 2012 at 9:13 PM, Even Rouault
wrote:
> Le lundi 06 février 2012 02:41:40, Etienne Tourigny a écrit :
>> Hi all,
>>
>> The default memory limit for warp operations is 64MB, which is far too
>> low using recent hardware and leads to inefficiencies in I/O when
>> warping large images.
Anybody got any ideas on troubleshooting this error? Any help/suggestions
would be hugely appreciated. I am trying real hard to not fallback on to
esri gp tasks...
Thank You,
Vish
--
View this message in context:
http://osgeo-org.1560.n6.nabble.com/gdal-polygonize-error-with-Arc-Info-binary-gri
Thank you guys for your quick response. Unless I hear otherwise from
someone else then we'll go with #3.
Daniel
On 12-02-07 4:56 PM, Howard Butler wrote:
On Feb 7, 2012, at 3:53 PM, Even Rouault wrote:
Le mardi 07 février 2012 22:49:34, Frank Warmerdam a écrit :
On Tue, Feb 7, 2012 at 1:3
Le lundi 06 février 2012 02:41:40, Etienne Tourigny a écrit :
> Hi all,
>
> The default memory limit for warp operations is 64MB, which is far too
> low using recent hardware and leads to inefficiencies in I/O when
> warping large images.
>
> This can be changed using the -wm option of gdalwarp,
Wow, thanks Even!
I now follow the logic for the original insert method. And yes your
implementation makes a reasonable assumption.
Thanks again,
Jeremy
> -Original Message-
> From: Even Rouault [mailto:even.roua...@mines-paris.org]
> Sent: Wednesday, 8 February 2012 11:50 a.m.
> To: g
> Is there a specific reason for the OGRPGTableLayer::BuildCopyFields (and
> CreateFeatureViaCopy) checking that the field must exist in the layer
> FieldDefn before adding it to the copy field list? Or is this a bug?
Jeremy,
I've created http://trac.osgeo.org/gdal/ticket/4495 to capture the issu
Any chance? Should I log a bug report?
>
> Hi
>
> When using the config PG_USE_COPY option the copy command does not include the
> destination FID in the field list. In my case the destination FID field is a
> primary key
> with a not null constraint, so the copy fails.
>
> e.g.
>
> ogr2ogr -
On Feb 7, 2012, at 3:53 PM, Even Rouault wrote:
> Le mardi 07 février 2012 22:49:34, Frank Warmerdam a écrit :
>> On Tue, Feb 7, 2012 at 1:34 PM, Daniel Morissette
>>
>> wrote:
>>> Hi GDAL PSC,
>>>
>>> The Seattle Sprint has a surplus this year and is offering the
>>> participants three option
Le mardi 07 février 2012 22:49:34, Frank Warmerdam a écrit :
> On Tue, Feb 7, 2012 at 1:34 PM, Daniel Morissette
>
> wrote:
> > Hi GDAL PSC,
> >
> > The Seattle Sprint has a surplus this year and is offering the
> > participants three options to deal with part of the surplus. I am
> > emailing t
On Tue, Feb 7, 2012 at 1:34 PM, Daniel Morissette
wrote:
> Hi GDAL PSC,
>
> The Seattle Sprint has a surplus this year and is offering the participants
> three options to deal with part of the surplus. I am emailing to ask what
> the PSC wants to do with respect to the registration paid by GDAL fo
Hi GDAL PSC,
The Seattle Sprint has a surplus this year and is offering the
participants three options to deal with part of the surplus. I am
emailing to ask what the PSC wants to do with respect to the
registration paid by GDAL for Brian Case.
The options are:
1- Take a reimbursement of 10
Even, Frank,
thanks for your answers. I have run into a problem with using
gdalwarp with geoloc transform.
In ticket #1895 there is an hdf file for which the HDF4 driver creates
GEOLOCATION metadata.
Trying gdalwarp on it gives an error, and the result transform is
incorrect. Am I doing someth
On 02/07/12 21:41, Even Rouault wrote:
It would be extremely useful to have a Ozi driver that supports a wider
range of projections than the current iteration, and it seems slightly odd
that a developer who is ready to do the necessary work to improve the
driver is not being encouraged.
We hav
On 08/02/2012, at 7:41 AM, Even Rouault wrote:
>>
>> It would be extremely useful to have a Ozi driver that supports a wider
>> range of projections than the current iteration, and it seems slightly odd
>> that a developer who is ready to do the necessary work to improve the
>> driver is not bei
On Tue, Feb 7, 2012 at 7:40 AM, Etienne Tourigny
wrote:
> Hi all,
>
> I would like to have information on the status of geolocation array
> support in GDAL.
>
> The relevant RFC4 (http://trac.osgeo.org/gdal/wiki/rfc4_geolocate) is
> still "under development", and the information there is that
> G
Le mercredi 01 février 2012 22:26:11, Even Rouault a écrit :
> Motion: GDAL/OGR Commit rights are extended to Robert Coup
I declare this motion passed with support from myself, FrankW, HowardB,
DanielM and TamasS. Welcome on board Robert !
Robert, I let to FrankW the practical details of enablin
Le mardi 07 février 2012 16:40:21, Etienne Tourigny a écrit :
> Hi all,
>
> I would like to have information on the status of geolocation array
> support in GDAL.
>
> The relevant RFC4 (http://trac.osgeo.org/gdal/wiki/rfc4_geolocate) is
> still "under development", and the information there is t
>
> It would be extremely useful to have a Ozi driver that supports a wider
> range of projections than the current iteration, and it seems slightly odd
> that a developer who is ready to do the necessary work to improve the
> driver is not being encouraged.
We have now obtained permission from O
Hi all,
I am trying to convert an Arc/Info binary grid raster file to a shapefile
using the gdal_polygonize.py utility. But the operation fails with the
following error
*Warning 1: Unsupported Arc/Info Binary Grid tile of type 0x80 encountered.
This and subsequent unsupported tile types set to n
Hi all,
I am trying to convert an Arc/Info binary grid raster file to a shapefile
using the gdal_polygonize.py utility. But the operation fails with the
following error
*Warning 1: Unsupported Arc/Info Binary Grid tile of type 0x80 encountered.
This and subsequent unsupported tile types set to n
I am getting the following error when trying to open NITF files for read:
Warning 1: Attribute subsection not large enough (124 bytes) to contain 196
attributes.
I am running multi threaded, and processing many different NITF files for
read (I am extracting the metadata). Is this a memory issue?
Hi all,
I would like to have information on the status of geolocation array
support in GDAL.
The relevant RFC4 (http://trac.osgeo.org/gdal/wiki/rfc4_geolocate) is
still "under development", and the information there is that
GDALCreateGeoLocTransformer "is currently partially implemented".
Also,
24 matches
Mail list logo
