Hi Even,
> ---Original Message---
> From: Even Rouault
> To: gdal-dev@lists.osgeo.org, Ivan Lucena
> Subject: Re: [gdal-dev] JRE vs JDK
> Sent: Oct 26 '12 13:26
>
> Le vendredi 26 octobre 2012 17:52:18, Ivan Lucena a écrit :
> > Hi there,
> >
> > I am getting this exception wh
Le vendredi 26 octobre 2012 17:52:18, Ivan Lucena a écrit :
> Hi there,
>
> I am getting this exception when loading gdal.jar:
>
> *
> Native library load failed.
> java.lang.UnsatisfiedLinkError: org.gdal.gdal.gdalJNI.HasThreadSupport()I
> *
>
> If I change the script that launch my application
> QUESTION:
>
> Is there a way to enhance my input channels separately in a single
> gdal_translate call, or do I need
> to make multiple passes?
Multiple passes. But you could also generate a VRT with a different rescaling
for each channel, and translate it into the target dataset.
>
> Than
Hello,
I have some input data where the dynamic range and offset of each channel
are distinct.
This means that applying the same linear enhancement based on data range to
my selected RGB output
bands will not produce an optimal visual enhancement.
-scale smin smax dmin dmax
only provides the s
In SAGA GIS there is a "Crop to Data" module (in Grid Tools module
library), which performs the task.
But this would require you to import your Geotif with the GDAL import
module, process it in SAGA, and finally export it as Geotif again with
the GDAL export module.
Best regards,
Volker
On
Hi there,
I am getting this exception when loading gdal.jar:
*
Native library load failed.
java.lang.UnsatisfiedLinkError: org.gdal.gdal.gdalJNI.HasThreadSupport()I
*
If I change the script that launch my application to use the "java.exe" from
the JDK instead of the JRE then the problem is gone
Selon Jukka Rahkonen :
> Even Rouault mines-paris.org> writes:
>
>
> > For the record, unfortuanetely it won't help you much, but I don't
> reproduce
> > the issues you're facing. The gdaltransform -s_srs EPSG:4326 -t_srs
> EPSG:3857
> > < "WGS84.txt" >"Grid.txt" command just works fine for me. P
you can surely identify the valid pixels with visualization software
such as qgis, using the valuetool plugin, to identify the 4 corners of
the valid region.
Another option is to compress the gtiff with e.g. DEFLATE compression like this
gdal_translate -co COMPRESS=DEFLATE in.tif out.tif
Etienne
At the time I created the ticket I had created a workaround that uses
gdal_translate to clip a rectangular window and gdal_rasterize to burn an
inverse image of the vector. Interested folks can email me for the script (does
the list take attachments?). The script makes some assumptions about you
Even Rouault mines-paris.org> writes:
> For the record, unfortuanetely it won't help you much, but I don't
reproduce
> the issues you're facing. The gdaltransform -s_srs EPSG:4326 -t_srs
EPSG:3857
> < "WGS84.txt" >"Grid.txt" command just works fine for me. Perhaps an
issue with
> your set
Hi,
2012/1/18 Etienne Tourigny :
> However, as your changes only affect your driver, I think it would be
> easier to commit them to 1.9.0 without an RFC. It would be easier if
> you prepare a small wiki page (similar to RFCs) describing the
> changes, and create at least one bug entry.
I have fi
Even Rouault mines-paris.org> writes:
> This is the very same topic that is discussed in
> http://trac.osgeo.org/gdal/ticket/3947 . There's no solution to your problem,
> but some background discussion that explains the current behaviour.
This is close to a problem I had once with creating mo
12 matches
Mail list logo
