Dear Team,
I've reviewed the change log for release 8 so far and do not think that
this question is version specific.
I'm coding to support an incremental process for loading a large spatial
database from a set of distribution objects. I have noted that my present
approach results
Hi Peter,
Do you mean that just after issuing a CreateFeature(), the feature ID isn't set
to the correct value (the one that you'll find after dataset reopening) ?
You have to be more specific about which OGR driver you are talking about
because the mechanisms for setting/retrieving FID is
Even,
thank you for your response. I had missed feat.SetFID, mentioned in the PG
ticket, so will have a go with that.
For the record, I'm currently working against the OCI driver but wish to be
reasonably independent of the underlying database implementation - hence use of OGR.
Hello,
stumbled across a problem when reading MrSid:
The MrSid dataset contains 3 bands, R/G/B. None of the 3 bands gives me a
GetNoDataValue(),
however, the metadata contains IMAGE__NO_DATA_VALUE=255,255,255.
Does this mean, that I have to check for both cases ?
The version is GDAL 1.7.2.
Oyvind,
GDAL handles nodata values band by band, whereas in MrSID all the bands of
the particular pixel location must match the nodata values for that pixel to
be considered nodata.
Currently nodata values are ignored in this driver. I don't know if anything
is planned for future releases.
On
Thanks for fast reply !
I assume the IMAGE__NO_DATA_VALUE=255,255,255 comes from the MrSid SDK
library.
These values could easily be mapped to the GDAL-bands NoData, as they
practically means
the same ? (255 for each band)
-- Oyvind
On Thu, Oct 28, 2010 at 1:09 PM, Chaitanya kumar CH
Oyvind,
The best abstraction to deal with a nodata triplet would be the NODATA_VALUES
metadata item at the dataset level described in
http://www.gdal.org/gdal_datamodel.html
You can do : gdal_translate your.sid your.tif -mo NODATA_VALUES=255 255 255
Since a few GDAL releases this will results
Even and team,
following the hint from Even's post below, I have been experimenting with
OGR_F_SetFID to get the FID for appends to increment beyond the existing value,
rather than always to start at 1. I'm testing against the OCI driver and am not
(yet) using 1.8.
I've found that
Peter J Halls wrote:
Even and team,
following the hint from Even's post below, I have been experimenting
with OGR_F_SetFID to get the FID for appends to increment beyond the
existing value, rather than always to start at 1. I'm testing against
the OCI driver and am not (yet) using 1.8.
An interesting discussion, but shouldn't the layer table have been cread
with a UNIQUE contraint in the ID column in the first place ?
Anders
On Thu, Oct 28, 2010 at 5:02 PM, Frank Warmerdam warmer...@pobox.comwrote:
Peter J Halls wrote:
Even and team,
following the hint from Even's post
Selon Peter J Halls p.ha...@york.ac.uk:
Not using it, it's hard for me to comment on OCI peculiarities. I've looked
quickly at the code of ogroctitablelayer.cpp and it seems to be consistant with
the behaviour you describe : if you set a FID before using CreateFeature() it
will use it, otherwise
Selon Tacot cfa...@hotmail.fr:
gdalbuildvrt is aimed at building a single dataset from a mosaic of tiles. You
just want to do the contrary. You were on a better track the other day when you
were exploring gdal_retile.
Generally the syntax for GDAL utilities is there :
Hi All,
I am working on fixing a memory use issue in the Virtual Planet Builder
project (an off shoot of OpenSceneGraph) and have come accross the exact
issue described in this thread.
The code essential runs in a loop creating an image pyramid from a large ECW
file. During this loop there a
Even Rouault even.rouault at mines-paris.org writes:
Selon Tacot cfab13 at hotmail.fr:
gdalbuildvrt is aimed at building a single dataset from a mosaic of tiles. You
just want to do the contrary. You were on a better track the other day when
you
were exploring gdal_retile.
Perhapt
BradC wrote:
Hi All,
I am working on fixing a memory use issue in the Virtual Planet Builder
project (an off shoot of OpenSceneGraph) and have come accross the exact
issue described in this thread.
The code essential runs in a loop creating an image pyramid from a large ECW
file. During this
Hi,
This motion has passed with +1 from PSC members EvenR, FrankW, DanielM,
TamasS and HowardB (and non-PSC +1 from GaigeP).
I will proceed soon to commiting the patch to svn.
I'll make VSIL_STRICT_ENFORCE active when DEBUG is defined. Hopefully this will
not cause troubles. Anyway, it'd be
Hello,
I have been working on ticket #3797. In the example given, gdalinfo is the
calling the netcdf driver. I agree with Frank's opinion on this in ticket
#1660:
Note that GDALRasterBand has methods to get the offset and scale. The normal
GDAL practice would be to return them via those
Joaquim,
With my code I wrote today, the offset and scale are set on the
GDALRasterBand itself. If I do the following:
gdal_translate lixo.grd lixo.tif
gdalinfo lixo.tif -mm
I get:
Driver: GTiff/GeoTIFF
Files: lixo.tif
lixo.tif.aux.xml
Size is 21, 21
Coordinate System is `'
Origin =
Kyle,
Yes, that is much better but (sorry for one other 'but') what about
formats that do not know anything about scale/offset?
(Surfer format is one comes right to my mind)
In those cases conversion would definitively go wrong. Issue a
screaming warning in than?
Joaquim
Joaquim,
With my
Ah, I see your issue. I honestly don't know what to do about that. The
only option I see is issuing a warning and continuing. I don't think
unscaling that data is an option without a user explicitly asking for it to
be unscaled. I am still not sure if this is even a gdal issue. The caller
When you use gdalwarp -tps what is the practical limit to the number of GCPs
useable in the thin plate spline algorithm before the program bogs down.
I would like to use it with over 1600 spline knots spread over the image.
Currently on a X86_64 smp linux system with 4 cores and 8 cpus and
Does GDAL utilize MMAP calls? Is this something you would consider as an
enhancement?
--
Max Buchheit
Canada Centre for Remote Sensing / Centre Canadien de Télédétection
Earth Sciences Sector / Secteur des Sciences de la Terre
Natural Resources Canada / Ressources Naturelles
Le jeudi 28 octobre 2010 21:41:30, Buchheit, Maximilian a écrit :
Is any of the GDAL code SMP aware (in linux)?
You mean multithreaded ? or multi-thread safe ?
* multithreaded : very little currently. To my knowledge only the warping code
that can use 2 threads : one for I/O, another one for
Le jeudi 28 octobre 2010 21:39:51, Buchheit, Maximilian a écrit :
When you use gdalwarp -tps what is the practical limit to the number of
GCPs useable in the thin plate spline algorithm before the program bogs
down. I would like to use it with over 1600 spline knots spread over the
image.
Buchheit, Maximilian wrote:
Does GDAL utilize MMAP calls? Is this something you would consider as
an enhancement?
Max,
I am interested in adding mmap support the VSI*L IO API and seeing where
it could be used. Libtiff can utilize memory mapping, and in some cases
in the past I've seen
Peter J Halls P.Halls at york.ac.uk writes:
Dear Team,
I've reviewed the change log for release 8 so far and do not think that
this question is version specific.
I'm coding to support an incremental process for loading a large spatial
database from a set of distribution
26 matches
Mail list logo
