Thanks.
kss
On Fri, Mar 23, 2012 at 15:06, Frank Warmerdam wrote:
> On Fri, Mar 23, 2012 at 1:57 PM, Kyle Shannon wrote:
> > Can the VSI*L support be added to drivers that use a third party API
> similar
> > to the way it is done in the geotiff driver? Would that be a good
> reference
> > to
On Fri, Mar 23, 2012 at 1:57 PM, Kyle Shannon wrote:
> Can the VSI*L support be added to drivers that use a third party API similar
> to the way it is done in the geotiff driver? Would that be a good reference
> to add support to other drivers?
Kyle,
There are a number of external libraries whe
Etienne,
I saw that under the vsizip section, but it wasn't clear to me if the same
constraints were on the vsicurl handler.
kss
On Fri, Mar 23, 2012 at 14:56, Etienne Tourigny wrote:
> Kyle,
>
> the driver(s) probably need to support "large file API"
>
> From http://trac.osgeo.org/gdal/wiki/Use
Can the VSI*L support be added to drivers that use a third party API
similar to the way it is done in the geotiff driver? Would that be a good
reference to add support to other drivers?
On Fri, Mar 23, 2012 at 14:33, Frank Warmerdam wrote:
> Kyle,
>
> You need to have built GDAL with curl suppo
Kyle,
the driver(s) probably need to support "large file API"
>From http://trac.osgeo.org/gdal/wiki/UserDocs/ReadInZip
The fact that this new capability is implemented as virtual file
systems imply that it will only work for GDAL drivers supporting the
"large file API". A non-exhaustive list of s
Kyle,
You need to have built GDAL with curl support and the drivers has do
do all file access through VSI*L functions.
Best regards,
Frank
On Fri, Mar 23, 2012 at 1:31 PM, Kyle Shannon wrote:
> What are the requirements for using the vsicurl handler for accessing files?
> Do drivers have to imp
What are the requirements for using the vsicurl handler for accessing
files? Do drivers have to implement anything special do have curl support?
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Dinesh,
Let us narrow the error location.
Give the argument --help-general or --version. You should get the
appropriate results. If not, it means that the arguments are not passed to
the executable.
On Fri, Mar 23, 2012 at 9:11 PM, Dinesh Dass Subramanian <
sdineshd...@gmail.com> wrote:
> Chaita
On Fri, Mar 23, 2012 at 10:29 AM, Chaitanya kumar CH
wrote:
> Output pixel value = (raw pixel value * scale) + offset
Exactly.
The reason for scale and offset to exist is that "real world" measures
like elevation, temperature, pressure are often represented in raster
datasets as integer values r
Output pixel value = (raw pixel value * scale) + offset
On Fri, Mar 23, 2012 at 5:44 PM, Saâd HESSANE wrote:
> Ok, thank you again Chaitanya,
>
> But what is the function of this two element?
>
>
> 2012/3/23 Chaitanya kumar CH
>
>> Saâd,
>>
>> A VRT raster band can be derived from more than one
Great to know. You can always clip the source rasters before the warp
operation to save time.
Etienne
On Fri, Mar 23, 2012 at 11:54 AM, Derek Morgan wrote:
> Etienne - Thanks for you advice. Gdalwarp did work quite nicely.
> Afterwhich, I just needed to clip the resulting raster back down to m
Chaitanya,
The inputAoiPath contains the list of the input coordinates to be
transformed. The path to the tiff file contains the RPC file using which
the transformation is performed. The outputAoiPath file contains the
transformed coordinates. Thanks.
On Thu, Mar 22, 2012 at 10:57 AM, Chaitanya k
Thanks Doug, this is great feedback. It is folks like you, and the others
who responded, that making working w/ open sources tools a pretty awesome
alternative.
Cheers,
Derek
On Fri, Mar 23, 2012 at 7:50 AM, wrote:
>
> Derek,
> You can do this in GRASS ( using gdal in the background)
Etienne - Thanks for you advice. Gdalwarp did work quite nicely.
Afterwhich, I just needed to clip the resulting raster back down to my
extent of interest which is no problem.
Cheers,
Derek
On Thu, Mar 22, 2012 at 10:37 PM, Etienne Tourigny
wrote:
> Derek - unless I am mistaken, gdalwarp shou
Ok, thank you again Chaitanya,
But what is the function of this two element?
2012/3/23 Chaitanya kumar CH
> Saâd,
>
> A VRT raster band can be derived from more than one source.
>
> Offset and Scale elements apply to the whole VRT raster band.
> The ScaleOffset and ScaleRatio perform the same
Derek,
You can do this in GRASS ( using gdal in the background) by doing
the following:
1) create a workspace in the same projection as your existing raster (
when you first start GRASS it will ask you to set up a workspace with
projection information)
2) import the existing raster la
Saâd,
A VRT raster band can be derived from more than one source.
Offset and Scale elements apply to the whole VRT raster band.
The ScaleOffset and ScaleRatio perform the same task but it is done only on
that particular ComplexSource.
On Fri, Mar 23, 2012 at 3:43 PM, Saâd HESSANE wrote:
> Hy al
Hy all,
The vrt format allow defining the scale and offset element. But the
documentation is not clear about that :
- *Offset*: This optional element contains the offset that should be
applied when computing "real" pixel values from scaled pixel values on a
raster band. The default is 0.
Derek,
Since you are rasterizing vectors, you can get the best results if you do
it onto the original raster or a blank raster created based on the extents
of the original raster. The key here is to create a georeferenced raster
prior to burning the vector onto it.
You can create a raster that fit
On 03/22/12 21:57, Even Rouault wrote:
Oh well, if you can confirm the patch works, I'll end up commiting it. It isn't
too invasive.
Yes, your patch works. You can commit it, thanks.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osg
20 matches
Mail list logo
