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 i
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 driver
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.
Thank
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.
Re
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 Thu
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
wrote:
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 the
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.
Hi
I would like to reshape a ECW pictures in several tiles.
Would it be possible to translate ECW in VRT; cut the VRT in tiles, and
re-translate all VRT in ECW?
And if it's possible, what are the syntax for those commands?
Thanks
--
View this message in context:
http://osgeo-org.1803224.n2.nab
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 wrote:
> Peter J Halls wrote:
>
>> Even and team,
>>
>> following the hint from Even's post below, I ha
Selon Peter J Halls :
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 it will use a seria
Selon Tacot :
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 :
http://gdal.org/gdal_utilities.html
>
> Hi
>
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 ver
Even Rouault mines-paris.org> writes:
>
> Selon Tacot 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 gdal2tiles or MapTil
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 lo
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 e
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 metho
Kyle,
Frank added in GDAL 1.7 a '-unscale' option to gdal_translate, so people can
always use gdal_translate -unscale to apply the offset and scale (they can even
do that do a VRT file to save disk space), and then use gdalinfo on the result.
Extract from the gdal_translate man page:
"-unscale
Even
Thanks for pointing into this that I was not aware of as it would be the
main point of my answer to Kyle's question.
But still, as it is referred in the ticket (sorry for lousy formatting
but I never learn how to do it better) the main issue occurred in the
conversion to another format (g
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 = (-10
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
just
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 "-m
Is any of the GDAL code SMP aware (in linux)?
--
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 Canada
4th Floor, 588 Booth Street / 4-ieme
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 Ca
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 c
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
> imag
Le jeudi 28 octobre 2010 21:42:09, Buchheit, Maximilian a écrit :
> Does GDAL utilize MMAP calls?
No
> Is this something you would consider as an
> enhancement?
>
Hum I dunno. I guess you would have to show that it brings real enhancements,
and not break portability to OS that don't support mm
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 notewo
Peter J Halls 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 objec
31 matches
Mail list logo