I am using C# Gdal library.
On Wed, Jan 16, 2013 at 5:25 PM, Dheeraj Reddy Mamidi <
drmam...@rothwellgroup.com> wrote:
> Hi,
>
> I am trying to create a Raster using grid of points(with latitude and
> longitude values) within an area which are separated at a distance measured
> in degrees. At hig
Hi,
I am trying to create a Raster using grid of points(with latitude and
longitude values) within an area which are separated at a distance measured
in degrees. At higher latitudes the number of samples reduce that is number
of points for a row reduces.
When distance between points is determined
On Wed, Jan 16, 2013 at 1:49 PM, Frank Warmerdam wrote:
> Folks,
>
> As I often seem to do, I exactly stated my point. I meant write:
Garr, once again missing a keyword.
I meant to say "I exactly stated my point *wrong*."
> "On the other hand, I am *not* denying the possibility that the RPC
>
Folks,
As I often seem to do, I exactly stated my point. I meant write:
"On the other hand, I am *not* denying the possibility that the RPC
DEM interpolation is always off by half a pixel in all cases."
Sorry for that.
On Wed, Jan 16, 2013 at 1:35 PM, Ivan Lucena
wrote:
> Hi Frank,
>
>> On
Hi Frank,
> On the other hand, I am denying the possibility that the RPC DEM
> interpolation is always off by half a pixel. I haven't actually
> looked closely at that code lately and the RPC code is not so very well
> tested and validated.
That is exactly what I understood from Yehiyam on
To be clear, suppose I want to make the red bow in the image below as a
tiff file with transparency. But instead of using RGBA, can tiff create it
with indexed color?
http://d241yswl6yg9sc.cloudfront.net/remove-background2/4.png
Isaac
On Wed, Jan 16, 2013 at 3:40 PM, Isaac Gerg wrote:
> Even,
Even,
I am confused. You said in your first response to me that TIFF does not
support indexed colormaps of RGBA. Am I understanding you correctly -- it
sounds like it is not possible to create an indexed color TIFF that has
background transparency. Is this correct?
Isaac
On Wed, Jan 16, 2013
Le mercredi 16 janvier 2013 21:21:29, Isaac Gerg a écrit :
> I mispoke.
>
> rgb2pct.py will work but only on RGB images -- no colortables. When I use
> it on a RGBA image, the transparency is no longer preservered.
Combine it with the first hints I gave
__
I mispoke.
rgb2pct.py will work but only on RGB images -- no colortables. When I use
it on a RGBA image, the transparency is no longer preservered.
Isaac
On Wed, Jan 16, 2013 at 3:17 PM, Even Rouault
wrote:
> Le mercredi 16 janvier 2013 20:58:51, Isaac Gerg a écrit :
> > Even,
> > Thanks for
rgb2pct.py does not work on tifs with indexed colormaps -- I have already
tried this.
I am already using COMPRESS=LZW on the mosiac.
Isaac
On Wed, Jan 16, 2013 at 3:17 PM, Even Rouault
wrote:
> can also try to gdal_translate -co COMPRESS=LZW on the mosaic, since
> I'm not sure how efficient th
Le mercredi 16 janvier 2013 20:58:51, Isaac Gerg a écrit :
> Even,
> Thanks for your quick response.
>
> I believe I understand that three options you presented me. I believe
> option 1 is viable but like you mentioned will only work with GDAL
> software. Options 2 and 3 are good but, especially
Even,
Thanks for your quick response.
I believe I understand that three options you presented me. I believe
option 1 is viable but like you mentioned will only work with GDAL
software. Options 2 and 3 are good but, especially with option 3, the
resulting tifs are too large.
I have 20 .tif whic
Le mercredi 16 janvier 2013 20:03:14, Isaac Gerg a écrit :
> Hi All,
>
> I have a tiff in which each pixel is a single byte (0-255) which references
> a colortable. Each element of the colortable has 4 values (RGBA).
>
> I would like to convert my "black" color (entry 1 in the color table
> (0,0
Hi All,
I have a tiff in which each pixel is a single byte (0-255) which references
a colortable. Each element of the colortable has 4 values (RGBA).
I would like to convert my "black" color (entry 1 in the color table
(0,0,0,255)) to be transparent (new colortable entry is (0,0,0,0))
Another w
Hi Frank,
I only want to note that the default is bilinear interpolation of the DEM.
Part of the code: const char *pszDEMInterpolation =
CSLFetchNameValueDef( papszOptions, "RPC_DEMINTERPOLATION", "bilinear" );
Best regards,
Dmitriy
16.01.2013 22:47, Frank Warmerdam ?:
Yehiyam,
I d
Yehiyam,
I do not see why you think the AREA_OR_POINT value ought to have any
influence on how DEM values are interpolated.
Note that a PixelIsPoint GeoTIFF file will already result in a GDAL
GeoTransform that is offset by half a pixel. The GDAL GeoTransform always
treats pixels as areas, and GD
On Wed, Jan 16, 2013 at 2:12 PM, Mateusz Loskot wrote:
> On 16 January 2013 16:07, Etienne Tourigny wrote:
>>
>> It might be good to write this somewhere? Not sure where though,
>> perhaps the gdal/ogr wiki page?
>
> It's documented in the comments of gdal_header.h
>
> http://svn.osgeo.org/gdal/t
On 16 January 2013 16:07, Etienne Tourigny wrote:
>
> It might be good to write this somewhere? Not sure where though,
> perhaps the gdal/ogr wiki page?
It's documented in the comments of gdal_header.h
http://svn.osgeo.org/gdal/trunk/gdal/gcore/gdal_version.h
Best regards,
--
Mateusz Loskot, ht
ok merci.
It might be good to write this somewhere? Not sure where though,
perhaps the gdal/ogr wiki page?
Etienne
On Wed, Jan 16, 2013 at 1:40 PM, Even Rouault
wrote:
>
>> The following seems to work using VERSION_NUM:
>>
>> in 1.10dev:
>> >>> gdal.VersionInfo("VERSION_NUM")
>> '110'
>> >>
Hi Ivan,
Look here:
http://www.gdal.org/gdal__alg_8h.html#af4c3c0d4c79218995b3a1f0bac3700a0
You can find such options:
*
RPC_HEIGHT: a fixed height offset to be applied to all points passed
in. In this situation the Z passed into the transformation function
is assumed to be height a
Yehiyam,
For that kind of issue my advise is to run in debugging mode. The GDAL
transformation engine must have an internal pixel geolocation defined.
It is probably CENTER of the pixel, as in AREA. I am not sure. In that
case the returning pixel/line refers to AREA and you might need to do
t
> The following seems to work using VERSION_NUM:
>
> in 1.10dev:
> >>> gdal.VersionInfo("VERSION_NUM")
> '110'
> >>> print( int(gdal.VersionInfo("VERSION_NUM")) >= 1900 )
> True
> >>> print( int(gdal.VersionInfo("VERSION_NUM")) >= 110 )
> True
>
> and in 1.9.2:
> >>> print( int(gdal.Versio
Hi,
Detection of gdal version in python using the following method fails
when using gdal-1.10 .
>>> print gdal.VersionInfo("RELEASE_NAME")
1.10dev
>>> print( gdal.VersionInfo("RELEASE_NAME") >= "1.7" )
False
>>> print( gdal.VersionInfo("RELEASE_NAME") >= "1.10" )
True
What is the recommended wa
Siva,
Is your code working? If not, what were the errors?
On Wed, Jan 16, 2013 at 1:17 PM, SIVA RAMA KRISHNA
wrote:
> Dear All,
>
> I am Trying to remove Dangle Lines from a shape file containing
> OGRLineString (polyline).I am thinking that if a line(2),line(3),line(4)
> crosses a another line(
Hi
I have a question about the RPC transform implemented in gdal_rpc.cpp.
If a dem file is specified in the transform options (RPC_DEM) the file is
sampled to retrieve the elevation of the transformed point.
In the case where the dem file is a DTED file (which defines AREA_OR_POINT to
POINT), sh
On 16 January 2013 10:13, Even Rouault wrote:
> Hi Mateusz,
>
> Looking at NCJP2FileView.cpp, I can see that most accesses to sm_Views are
> protected with CNCSJPCGlobalLock _Lock;
>
> Perhaps it should also be added to CNCSJP2FileView::Shutdown() which seems the
> only place in that file not prot
Hi Mateusz,
Looking at NCJP2FileView.cpp, I can see that most accesses to sm_Views are
protected with CNCSJPCGlobalLock _Lock;
Perhaps it should also be added to CNCSJP2FileView::Shutdown() which seems the
only place in that file not protected by the lock.
Best regards,
Even
___
27 matches
Mail list logo
