Re: [gdal-dev] Unwanted partial transparency when clipping

[Marius Jigmond]

I use QGIS which knows how to interpret the bands. I have no idea how
Photoshop handles the alpha band. You can try specifying -dstnodata:
gdalwarp -crop_to_cutline -cutline mask.shp -dstnodata "0 0 0"
source.tif dest.tif
this should output a RGBA tif with NoData=0 (black) and maybe Photoshop
can interpret the NoData tag.

You might also want to try nearblack:
http://www.gdal.org/nearblack.html

I suppose it would be important to know what the final purpose of these
images is because as far as GIS software goes just about all can read
the cropped tif just fine with proper transparency.

-marius

On Fri, 2011-07-08 at 18:24 -0700, Michael Corey wrote:

> Actually when I opened up your sample file in Photoshop I got the same
> results as I had earlier. What viewer are you using to look at your
> output files?
> 
> Also, I did find a workaround that at least improves the situation for
> me.
> 
> First I translate the source images:
> 
> gdal_translate source1.tif source1-noalpha.tif -b 1 -b 2 -b 3 -mask 4
> -co COMPRESS=JPEG -co PHOTOMETRIC=YCBCR --config
> GDAL_TIFF_INTERNAL_MASK YES
> 
> Then use warp to do my merging and clipping:
> 
> gdalwarp -crop_to_cutline -cutline
> ~/Documents/GIS/usa/California/doq/diablo-fullzoom-cutout.shp
> source1-noalpha.tif source2-noalpha.tif fullzoom-clipped.tif
> 
> I still have to use Photoshop to get rid of the nodata section, but at
> least my transparency isn't affected.
> 
> Any ideas how to get rid of the black and have transparent pixels
> instead, anyone?
> 
> Thanks again,
> 
> Michael Corey
> 
> 
> On 7/8/11 6:12 PM, Marius Jigmond wrote: 
> 
> > 1.8 compiled from source
> > 
> > -marius
> > 
> > On Fri, 2011-07-08 at 18:02 -0700, Michael Corey wrote:
> > 
> > > That certainly could be. I'm running GDAL 1.8 from the kyngchaos
> > > site. Which version are you running?
> > > 
> > > Thanks, 
> > > 
> > > Michael Corey
> > > 
> > > 
> > > On 7/8/11 5:56 PM, Marius Jigmond wrote: 
> > > 
> > > > 
> > > > 
> > > > On Fri, 2011-07-08 at 08:14 -0700, Michael Corey wrote: 
> > > > 
> > > > > OK, I did a little more work on this, and I've narrowed down what's 
> > > > > going on, but I could still use some help in figuring out how to 
> > > > > solve it.
> > > > > 
> > > > > Here's my original image:
> > > > > 
> > > > > http://mikejcorey.com/spatial/diablo-orig-5pct.tif
> > > > > 
> > > > > The original appears to have an RGBA setup (RGB channels and an alpha 
> > > > > channel).
> > > > > When I run this:
> > > > > 
> > > > > gdalwarp -crop_to_cutline -cutline cutout.shp sourceimage.tif 
> > > > > diablo-cutline.tif
> > > > > 
> > > > > Here's what I get:
> > > > > 
> > > > > http://mikejcorey.com/spatial/diablo-cutline-5pct.tif
> > > > > 
> > > > > This comes out as an RGB image with no alpha channel, with each 
> > > > > channel 
> > > > > being semi-transparent.
> > > > > 
> > > > 
> > > > Not in my case. Could there be something wrong with your GDAL
> > > > setup? I drew a shapefile mask and ran the above command but my
> > > > result is RGBA, the alpha band is not lost. See mask and result
> > > > here:
> > > > http://ubuntuone.com/p/13WR/
> > > > 
> > > > the output of gdalinfo:
> > > > marius@mobi:~/Downloads$ gdalinfo diablo_cutl.tif 
> > > > Driver: GTiff/GeoTIFF
> > > > Files: diablo_cutl.tif
> > > > Size is 266, 224
> > > > Coordinate System is:
> > > > PROJCS["NAD83 / UTM zone 10N",
> > > > GEOGCS["NAD83",
> > > > DATUM["North_American_Datum_1983",
> > > > SPHEROID["GRS 1980",6378137,298.2572221010002,
> > > > AUTHORITY["EPSG","7019"]],
> > > > AUTHORITY["EPSG","6269"]],
> > > > PRIMEM["Greenwich",0],
> > > > UNIT["degree",0.0174532925199433],
> > > > AUTHORITY["EPSG","4269"]],
> > > > PROJECTION["Transverse_Mercator"],
> > > > PARAMETER["latitude_of_origin",0],
> > > > PARAMETER["central_meridian",-123],
> > > > PARAMETER["scale_factor",0.9996],
> > > > PARAMETER["false_easting",50],
> > > > PARAMETER["false_northing",0],
> > > > UNIT["metre",1,
> > > > AUTHORITY["EPSG","9001"]],
> > > > AUTHORITY["EPSG","26910"]]
> > > > Origin = (693798.721929854014888,3902305.751849883235991)
> > > > Pixel Size = (20.022668877344305,-20.040546259961307)
> > > > Metadata:
> > > >   AREA_OR_POINT=Area
> > > > Image Structure Metadata:
> > > >   INTERLEAVE=PIXEL
> > > > Corner Coordinates:
> > > > Upper Left  (  693798.722, 3902305.752) (120d52'12.04"W,
> > > > 35d14'42.43"N)
> > > > Lower Left  (  693798.722, 3897816.669) (120d52'15.84"W,
> > > > 35d12'16.81"N)
> > > > Upper Right (  699124.752, 3902305.752) (120d48'41.44"W,
> > > > 35d14'38.67"N)
> > > > Lower Right (  699124.752, 3897816.669) (120d48'45.35"W,
> > > > 35d12'13.05"N)
> > > > Center  (  696461.737, 3900061.211) (120d50'28.67"W,
> > > > 35d13'27.75"N)
> > > > Band 1 Block=266x7 Type=Byte, ColorInterp=Red
> > > >   Mask Flags: PER_DATASET ALPHA 
> > > > Band 2 Block=266x7 Type=Byte, Colo

Re: [gdal-dev] Unwanted partial transparency when clipping

[Marius Jigmond]

1.8 compiled from source

-marius

On Fri, 2011-07-08 at 18:02 -0700, Michael Corey wrote:

> That certainly could be. I'm running GDAL 1.8 from the kyngchaos site.
> Which version are you running?
> 
> Thanks,
> 
> Michael Corey
> 
> 
> On 7/8/11 5:56 PM, Marius Jigmond wrote: 
> 
> > 
> > 
> > On Fri, 2011-07-08 at 08:14 -0700, Michael Corey wrote: 
> > 
> > > OK, I did a little more work on this, and I've narrowed down what's 
> > > going on, but I could still use some help in figuring out how to solve it.
> > > 
> > > Here's my original image:
> > > 
> > > http://mikejcorey.com/spatial/diablo-orig-5pct.tif
> > > 
> > > The original appears to have an RGBA setup (RGB channels and an alpha 
> > > channel).
> > > When I run this:
> > > 
> > > gdalwarp -crop_to_cutline -cutline cutout.shp sourceimage.tif 
> > > diablo-cutline.tif
> > > 
> > > Here's what I get:
> > > 
> > > http://mikejcorey.com/spatial/diablo-cutline-5pct.tif
> > > 
> > > This comes out as an RGB image with no alpha channel, with each channel 
> > > being semi-transparent.
> > > 
> > 
> > Not in my case. Could there be something wrong with your GDAL setup?
> > I drew a shapefile mask and ran the above command but my result is
> > RGBA, the alpha band is not lost. See mask and result here:
> > http://ubuntuone.com/p/13WR/
> > 
> > the output of gdalinfo:
> > marius@mobi:~/Downloads$ gdalinfo diablo_cutl.tif 
> > Driver: GTiff/GeoTIFF
> > Files: diablo_cutl.tif
> > Size is 266, 224
> > Coordinate System is:
> > PROJCS["NAD83 / UTM zone 10N",
> > GEOGCS["NAD83",
> > DATUM["North_American_Datum_1983",
> > SPHEROID["GRS 1980",6378137,298.2572221010002,
> > AUTHORITY["EPSG","7019"]],
> > AUTHORITY["EPSG","6269"]],
> > PRIMEM["Greenwich",0],
> > UNIT["degree",0.0174532925199433],
> > AUTHORITY["EPSG","4269"]],
> > PROJECTION["Transverse_Mercator"],
> > PARAMETER["latitude_of_origin",0],
> > PARAMETER["central_meridian",-123],
> > PARAMETER["scale_factor",0.9996],
> > PARAMETER["false_easting",50],
> > PARAMETER["false_northing",0],
> > UNIT["metre",1,
> > AUTHORITY["EPSG","9001"]],
> > AUTHORITY["EPSG","26910"]]
> > Origin = (693798.721929854014888,3902305.751849883235991)
> > Pixel Size = (20.022668877344305,-20.040546259961307)
> > Metadata:
> >   AREA_OR_POINT=Area
> > Image Structure Metadata:
> >   INTERLEAVE=PIXEL
> > Corner Coordinates:
> > Upper Left  (  693798.722, 3902305.752) (120d52'12.04"W,
> > 35d14'42.43"N)
> > Lower Left  (  693798.722, 3897816.669) (120d52'15.84"W,
> > 35d12'16.81"N)
> > Upper Right (  699124.752, 3902305.752) (120d48'41.44"W,
> > 35d14'38.67"N)
> > Lower Right (  699124.752, 3897816.669) (120d48'45.35"W,
> > 35d12'13.05"N)
> > Center  (  696461.737, 3900061.211) (120d50'28.67"W,
> > 35d13'27.75"N)
> > Band 1 Block=266x7 Type=Byte, ColorInterp=Red
> >   Mask Flags: PER_DATASET ALPHA 
> > Band 2 Block=266x7 Type=Byte, ColorInterp=Green
> >   Mask Flags: PER_DATASET ALPHA 
> > Band 3 Block=266x7 Type=Byte, ColorInterp=Blue
> >   Mask Flags: PER_DATASET ALPHA 
> > Band 4 Block=266x7 Type=Byte, ColorInterp=Alpha
> > 
> > -marius
> > 
> > 
> > > However, if I do this:
> > > 
> > > gdalwarp -dstalpha -crop_to_cutline -cutline cutout.shp sourceimage.tif 
> > > diablo-dstalpha-cutline.tif
> > > 
> > > I get this:
> > > 
> > > http://mikejcorey.com/spatial/diablo-dstalpha-cutline-5pct.tif
> > > 
> > > This one is strange, because it appears to be a grayscale image. But 
> > > when I open it in Photoshop, I see that it actually has 4 alpha 
> > > channels. I suspect that those are just getting set incorrectly as alpha 
> > > and are in fact the RGB channels, but can someone explain that behavior 
> > > or how to fix it?
> > > 
> > > What I want to end up with is a clipped RGB image (or RGBA) image where 
> > > nodata is transparent and the RGB isn't translucent.
> > > 
> > > Thanks again!
> > > 
> > > Michael Corey
> > > 
> > > 
> > > 
> > > On 7/7/11 7:13 AM, Eli Adam wrote:
> > > > Michael,
> > > >
> > >  On 7/6/2011 at 5:35 PM, in message<4e14ff42.50...@cironline.org>, 
> > >  Michael
> > > > Corey  wrote:
> > > >> Sure, I've uploaded samples here.
> > > >>
> > > >> http://www.mikejcorey.com/spatial/diablo-box-sample.tif
> > > >> http://www.mikejcorey.com/spatial/diablo-cutout-sample.tif
> > > > I don't notice the semi-transparency in these scaled down images.  
> > > > Perhaps it is the way your viewer reads the mask?
> > > >
> > > >> These are the same as the images created by the process I described 
> > > >> (but
> > > >> scaled down).
> > > >>
> > > >> To your point about specifying size in the first step -- will that make
> > > >> the process run faster, or does it do the scaling down after it builds
> > > >> the full-resolution image?
> > > >>
> > > >> Also, I notice that my filesize always gets significantly bigger when I
> > > >> do the cutout step, which seems counter-intuitive t

Re: [gdal-dev] Unwanted partial transparency when clipping

[Michael Corey]

That certainly could be. I'm running GDAL 1.8 from the kyngchaos site. 
Which version are you running?


Thanks,

Michael Corey


On 7/8/11 5:56 PM, Marius Jigmond wrote:



On Fri, 2011-07-08 at 08:14 -0700, Michael Corey wrote:

OK, I did a little more work on this, and I've narrowed down what's
going on, but I could still use some help in figuring out how to solve it.

Here's my original image:

http://mikejcorey.com/spatial/diablo-orig-5pct.tif

The original appears to have an RGBA setup (RGB channels and an alpha
channel).
When I run this:

gdalwarp -crop_to_cutline -cutline cutout.shp sourceimage.tif
diablo-cutline.tif

Here's what I get:

http://mikejcorey.com/spatial/diablo-cutline-5pct.tif

This comes out as an RGB image with no alpha channel, with each channel
being semi-transparent.

Not in my case. Could there be something wrong with your GDAL setup? I 
drew a shapefile mask and ran the above command but my result is RGBA, 
the alpha band is not lost. See mask and result here:

http://ubuntuone.com/p/13WR/

the output of gdalinfo:
marius@mobi :~/Downloads$ gdalinfo diablo_cutl.tif
Driver: GTiff/GeoTIFF
Files: diablo_cutl.tif
Size is 266, 224
Coordinate System is:
PROJCS["NAD83 / UTM zone 10N",
GEOGCS["NAD83",
DATUM["North_American_Datum_1983",
SPHEROID["GRS 1980",6378137,298.2572221010002,
AUTHORITY["EPSG","7019"]],
AUTHORITY["EPSG","6269"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433],
AUTHORITY["EPSG","4269"]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",0],
PARAMETER["central_meridian",-123],
PARAMETER["scale_factor",0.9996],
PARAMETER["false_easting",50],
PARAMETER["false_northing",0],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
AUTHORITY["EPSG","26910"]]
Origin = (693798.721929854014888,3902305.751849883235991)
Pixel Size = (20.022668877344305,-20.040546259961307)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left  (  693798.722, 3902305.752) (120d52'12.04"W, 35d14'42.43"N)
Lower Left  (  693798.722, 3897816.669) (120d52'15.84"W, 35d12'16.81"N)
Upper Right (  699124.752, 3902305.752) (120d48'41.44"W, 35d14'38.67"N)
Lower Right (  699124.752, 3897816.669) (120d48'45.35"W, 35d12'13.05"N)
Center  (  696461.737, 3900061.211) (120d50'28.67"W, 35d13'27.75"N)
Band 1 Block=266x7 Type=Byte, ColorInterp=Red
  Mask Flags: PER_DATASET ALPHA
Band 2 Block=266x7 Type=Byte, ColorInterp=Green
  Mask Flags: PER_DATASET ALPHA
Band 3 Block=266x7 Type=Byte, ColorInterp=Blue
  Mask Flags: PER_DATASET ALPHA
Band 4 Block=266x7 Type=Byte, ColorInterp=Alpha

-marius


However, if I do this:

gdalwarp -dstalpha -crop_to_cutline -cutline cutout.shp sourceimage.tif
diablo-dstalpha-cutline.tif

I get this:

http://mikejcorey.com/spatial/diablo-dstalpha-cutline-5pct.tif

This one is strange, because it appears to be a grayscale image. But
when I open it in Photoshop, I see that it actually has 4 alpha
channels. I suspect that those are just getting set incorrectly as alpha
and are in fact the RGB channels, but can someone explain that behavior
or how to fix it?

What I want to end up with is a clipped RGB image (or RGBA) image where
nodata is transparent and the RGB isn't translucent.

Thanks again!

Michael Corey



On 7/7/11 7:13 AM, Eli Adam wrote:
>  Michael,
>
  On 7/6/2011 at 5:35 PM, in message<4e14ff42.50...@cironline.org  
>, Michael
>  Coreymailto:mco...@cironline.org>>   wrote:
>>  Sure, I've uploaded samples here.
>>
>>  http://www.mikejcorey.com/spatial/diablo-box-sample.tif
>>  http://www.mikejcorey.com/spatial/diablo-cutout-sample.tif
>  I don't notice the semi-transparency in these scaled down images.  Perhaps 
it is the way your viewer reads the mask?
>
>>  These are the same as the images created by the process I described (but
>>  scaled down).
>>
>>  To your point about specifying size in the first step -- will that make
>>  the process run faster, or does it do the scaling down after it builds
>>  the full-resolution image?
>>
>>  Also, I notice that my filesize always gets significantly bigger when I
>>  do the cutout step, which seems counter-intuitive to me since in theory
>>  shouldn't there be less information present once the cutout is done?
>  -cutline does not 'discard' any data.  The extent of the data remains the 
same unless you reset those extents.  You can do that with -crop_to_cutline.  Here 
are some details from the gdalwarp page,http://gdal.org/gdalwarp.html  :
>
>  -crop_to_cutline:
>   (GDAL>= 1.8.0) Crop the extent of the target dataset to the extent of 
the cutline.
>
>  Polygon cutlines may be used as a mask to restrict the area of the 
destination file that may be updated, including blending. If the OGR layer 
containing the cutline features has no explicit SRS, the cutline features must be 
in the geor

Re: [gdal-dev] Unwanted partial transparency when clipping

[Marius Jigmond]

On Fri, 2011-07-08 at 08:14 -0700, Michael Corey wrote:

> OK, I did a little more work on this, and I've narrowed down what's 
> going on, but I could still use some help in figuring out how to solve it.
> 
> Here's my original image:
> 
> http://mikejcorey.com/spatial/diablo-orig-5pct.tif
> 
> The original appears to have an RGBA setup (RGB channels and an alpha 
> channel).
> When I run this:
> 
> gdalwarp -crop_to_cutline -cutline cutout.shp sourceimage.tif 
> diablo-cutline.tif
> 
> Here's what I get:
> 
> http://mikejcorey.com/spatial/diablo-cutline-5pct.tif
> 
> This comes out as an RGB image with no alpha channel, with each channel 
> being semi-transparent.
> 

Not in my case. Could there be something wrong with your GDAL setup? I
drew a shapefile mask and ran the above command but my result is RGBA,
the alpha band is not lost. See mask and result here:
http://ubuntuone.com/p/13WR/

the output of gdalinfo:
marius@mobi:~/Downloads$ gdalinfo diablo_cutl.tif 
Driver: GTiff/GeoTIFF
Files: diablo_cutl.tif
Size is 266, 224
Coordinate System is:
PROJCS["NAD83 / UTM zone 10N",
GEOGCS["NAD83",
DATUM["North_American_Datum_1983",
SPHEROID["GRS 1980",6378137,298.2572221010002,
AUTHORITY["EPSG","7019"]],
AUTHORITY["EPSG","6269"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433],
AUTHORITY["EPSG","4269"]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",0],
PARAMETER["central_meridian",-123],
PARAMETER["scale_factor",0.9996],
PARAMETER["false_easting",50],
PARAMETER["false_northing",0],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
AUTHORITY["EPSG","26910"]]
Origin = (693798.721929854014888,3902305.751849883235991)
Pixel Size = (20.022668877344305,-20.040546259961307)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left  (  693798.722, 3902305.752) (120d52'12.04"W, 35d14'42.43"N)
Lower Left  (  693798.722, 3897816.669) (120d52'15.84"W, 35d12'16.81"N)
Upper Right (  699124.752, 3902305.752) (120d48'41.44"W, 35d14'38.67"N)
Lower Right (  699124.752, 3897816.669) (120d48'45.35"W, 35d12'13.05"N)
Center  (  696461.737, 3900061.211) (120d50'28.67"W, 35d13'27.75"N)
Band 1 Block=266x7 Type=Byte, ColorInterp=Red
  Mask Flags: PER_DATASET ALPHA 
Band 2 Block=266x7 Type=Byte, ColorInterp=Green
  Mask Flags: PER_DATASET ALPHA 
Band 3 Block=266x7 Type=Byte, ColorInterp=Blue
  Mask Flags: PER_DATASET ALPHA 
Band 4 Block=266x7 Type=Byte, ColorInterp=Alpha

-marius


> However, if I do this:
> 
> gdalwarp -dstalpha -crop_to_cutline -cutline cutout.shp sourceimage.tif 
> diablo-dstalpha-cutline.tif
> 
> I get this:
> 
> http://mikejcorey.com/spatial/diablo-dstalpha-cutline-5pct.tif
> 
> This one is strange, because it appears to be a grayscale image. But 
> when I open it in Photoshop, I see that it actually has 4 alpha 
> channels. I suspect that those are just getting set incorrectly as alpha 
> and are in fact the RGB channels, but can someone explain that behavior 
> or how to fix it?
> 
> What I want to end up with is a clipped RGB image (or RGBA) image where 
> nodata is transparent and the RGB isn't translucent.
> 
> Thanks again!
> 
> Michael Corey
> 
> 
> 
> On 7/7/11 7:13 AM, Eli Adam wrote:
> > Michael,
> >
>  On 7/6/2011 at 5:35 PM, in message<4e14ff42.50...@cironline.org>, Michael
> > Corey  wrote:
> >> Sure, I've uploaded samples here.
> >>
> >> http://www.mikejcorey.com/spatial/diablo-box-sample.tif
> >> http://www.mikejcorey.com/spatial/diablo-cutout-sample.tif
> > I don't notice the semi-transparency in these scaled down images.  Perhaps 
> > it is the way your viewer reads the mask?
> >
> >> These are the same as the images created by the process I described (but
> >> scaled down).
> >>
> >> To your point about specifying size in the first step -- will that make
> >> the process run faster, or does it do the scaling down after it builds
> >> the full-resolution image?
> >>
> >> Also, I notice that my filesize always gets significantly bigger when I
> >> do the cutout step, which seems counter-intuitive to me since in theory
> >> shouldn't there be less information present once the cutout is done?
> > -cutline does not 'discard' any data.  The extent of the data remains the 
> > same unless you reset those extents.  You can do that with 
> > -crop_to_cutline.  Here are some details from the gdalwarp page, 
> > http://gdal.org/gdalwarp.html :
> >
> > -crop_to_cutline:
> >  (GDAL>= 1.8.0) Crop the extent of the target dataset to the extent of 
> > the cutline.
> >
> > Polygon cutlines may be used as a mask to restrict the area of the 
> > destination file that may be updated, including blending. If the OGR layer 
> > containing the cutline features has no explicit SRS, the cutline features 
> > must be in the georeferenced units of the destination file. When outputing 
> > to a not yet existing target dat

RE: [gdal-dev] Adding a subdataset to a NITF

[Cole, Derek]

Perfect. I guess I missed this, digging around in the API instead of the format 
specification!

Thanks! 

-Original Message-
From: Even Rouault [mailto:even.roua...@mines-paris.org] 
Sent: Friday, July 08, 2011 3:47 PM
To: gdal-dev@lists.osgeo.org
Cc: Cole, Derek
Subject: Re: [gdal-dev] Adding a subdataset to a NITF

Le vendredi 08 juillet 2011 21:41:43, Cole, Derek a écrit :
> Hello list,
> 
> I have been reading through the documentation to see if it is possible 
> to add a subdataset to a format that supports it (NITF). It seems like 
> based on the data model it is possible to read those by extracting the 
> name and then reading it as normal as if that was the file name. Is 
> there any ability to write a subdataset into a file?

You can create a multi image/subdataset file at Create() time with the NUMI 
creation option. See the doc in http://gdal.org/frmt_nitf.html

Then when you open the subdataset in GA_Update mode, you can write the imagery 
in it

> 
> Derek
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL for Python 3.2 on Windows 64bit

[Even Rouault]

Le vendredi 08 juillet 2011 21:55:12, Isaac Gerg a écrit :
> Hi Everyone,
> 
> I am wondering if there is a build (beta or release) of GDAL for Python 3.2
> on the Windows 64bit platform.  I have been browsing around the ticket area
> of the website and there appears to have been code entered in to make
> GDAL compatible with python 3.2.  However, I cannot find where these
> binaries are available for download.

No binaries AFAIK. You have to build them yourself from source, and this is 
new to trunk.

http://vbkto.dyndns.org/sdk/ proposes bindings for 2.6, 2.7 and 3.1. Perhaps 
Tamas would want to add support for 3.2 ?

> 
> Any help would be great appreciated.
> 
> Thanks in advance,
> Isaac
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] GDAL for Python 3.2 on Windows 64bit

[Isaac Gerg]

Hi Everyone,

I am wondering if there is a build (beta or release) of GDAL for Python 3.2
on the Windows 64bit platform.  I have been browsing around the ticket area
of the website and there appears to have been code entered in to make
GDAL compatible with python 3.2.  However, I cannot find where these
binaries are available for download.

Any help would be great appreciated.

Thanks in advance,
Isaac
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Adding a subdataset to a NITF

[Even Rouault]

Le vendredi 08 juillet 2011 21:41:43, Cole, Derek a écrit :
> Hello list,
> 
> I have been reading through the documentation to see if it is possible to
> add a subdataset to a format that supports it (NITF). It seems like based
> on the data model it is possible to read those by extracting the name and
> then reading it as normal as if that was the file name. Is there any
> ability to write a subdataset into a file?

You can create a multi image/subdataset file at Create() time with the NUMI 
creation option. See the doc in http://gdal.org/frmt_nitf.html

Then when you open the subdataset in GA_Update mode, you can write the imagery 
in it

> 
> Derek
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Adding a subdataset to a NITF

[Cole, Derek]

Hello list,

I have been reading through the documentation to see if it is possible to add a 
subdataset to a format that supports it (NITF).
It seems like based on the data model it is possible to read those by 
extracting the name and then reading it as normal as if that was the file name. 
Is there any ability to write a subdataset into a file?

Derek
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Fwd: Re: [Live-demo] Re: Liberal licensing of Project Overviews in LiveDVD, do we want this?

[Even Rouault]

Le vendredi 08 juillet 2011 16:35:52, Frank Warmerdam a écrit :
> On Fri, Jul 8, 2011 at 1:34 AM, Ari Jolma  wrote:
> > Would it be enough to add something to the Doxyfile tag HTML_FOOTER,
> > which states what the documentation is? That way it gets to the bottom
> > of every page of gdal.org. The footer can't be the whole licence,
> > though. MIT licence does not seem to have a definitive web page and the
> > wikipedia page states that "MIT Licence" is ambiguous.
> 
> Ari,
> 
> I would agree having a standard statement in the footer makes sense
> and I would suggest it be url linked to:
> 
> http://trac.osgeo.org/gdal/wiki/FAQGeneral#WhatlicensedoesGDALOGRuse
> 
> which might be clarified a bit (and also the LICENSE file) with regard to
> documentation.
> 
> Best regards,

ok, what do you think of the following (doc/gdal_footer.html) :



The documentation on gdal.org is covered under the terms of the http://trac.osgeo.org/gdal/wiki/FAQGeneral#WhatlicensedoesGDALOGRuse";>X/MIT
 
license - 
Generated for GDAL by 
http://www.doxygen.org/index.html";> $doxygenversion.




Note that not all pages will display this footer since we have quite a lot of 
static HTML pages (the format list page, the driver specific pages, etc...).

Here are some questions :

1) I'm wondering if we should say "The documentation on" or "The content on" 
(in case someone wonders if some content is really documentation ;-)). Should 
we mention "on gdal.org" that will extend to all pages, or use something like 
"The content of this page is covered under the terms of the X/MIT license" 
that only apply to the current page, and not the whole site ? This has the 
advantage to have better control on which pages it apply since it can only be 
content committed in SVN. But pages such as the static HTML ones would still 
be in a grey area.

2) I'm unsure of the status of "Adam's 2.5 D Simple Features Proposal (OGC 
99-402r2)" : http://home.gdal.org/projects/opengis/twohalfdsf.html that is 
linked from http://gdal.org/ogr/ but actually lives on home.gdal.org/ . Same 
question for http://home.gdal.org/projects/opengis/wkt_prop.html .

3) By the way, what about the content on http://home.gdal.org/ ? If we use 
"The documentation on gdal.org is covered...", would it be considered to be 
included by this sentence ? I think that part of it, like 
http://home.gdal.org/projects/ could be good candidate. But some other content 
( http://home.gdal.org/aj/other.html ;-) ) wasn't primarly meant as being 
redistribuable... To my knowledge, Frank being the only one to have write 
access on home.gdal.org, it should be easy to have a clear status on this.

4) I see that http://mapserver.org/documentation.html doesn't display the 
license, but "© Copyright 2011, Regents of the University of Minnesota.". When 
you click on Copyright, you are directed to a page with the mapserver X/MIT 
license. So should we mention a license or a copyright ? If a copyright, what 
would be the appropriate one ?

5) Once decided on what to do exactly, as it touches licensing, I'm wondering 
if we shouldn't decide this through a motion. 

6) Other question, what about the content on trac.osgeo.org/gdal ? It is more 
difficult to determine its licensing in a global way because anybody can add 
content, not only GDAL committers...

Thoughts ?
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Meaning of nPixelSpace/nLineSpace in IRasterIO

[Even Rouault]

Le vendredi 08 juillet 2011 16:09:31, Jorge Arévalo a écrit :
> Hello,
> 
> I'm not sure of the meaning of nPixelSpace, nLineSpace IRasterIO args.
> 
> >From GDAL doc I read:
> nPixelSpace: The byte offset from the start of one pixel value in
> pData to the start of the next pixel value within a scanline. If
> defaulted (0) the size of the datatype eBufType is used.
> 
> nLineSpace: The byte offset from the start of one scanline in pData to
> the start of the next. If defaulted (0) the size of the datatype
> eBufType * nBufXSize is used.
> 
> and
> 
> The nPixelSpace and nLineSpace parameters allow reading into or
> writing from unusually organized buffers. This is primarily used for
> buffers containing more than one bands raster data in interleaved
> format.
> 
> I know there are, basically, 3 interleave formats:
> 
> BSQ (INTERLEAVE=BAND)
> BIL (INTERLEAVE=LINE)
> BIP (INTERLEAVE=PIXEL)
> 
> Assuming a 3-bands (rgb) 4x4 raster, the pData array would look like
> this ("|" used only to mark the end of a row):
> 
> BSQ: r1 r1 r1 r1 | r2 r2 r2 r2 | r3 r3 r3 r3 | r4 r4 r4 r4 | g1 g1 g1
> g1 | g2 g2 g2 g2 | g3 g3 g3 g3 | g4 g4 g4 g4 g4 | b1 b1 b1 b1 | b2 b2
> b2 b2 | b3 b3 b3 b3 | b4 b4 b4 b4

For the sake of simplicity, let's assume that the datatype is byte (if not, 
just multiply all values by GDALGetDataType(eDT) / 8),

Yes, nPixelOffset = 1, nLineOffset = nBufferXSize, nBandOffset = nBufferXSize * 
nBufferYSize.

(nBandOffset is for GDALDatasetRasterIO())

> 
> BIL: r1 r1 r1 r1 | g1 g1 g1 g1 | b1 b1 b1 b1 | r2 r2 r2 r2 | g2 g2 g2
> g2 | b2 b2 b2 b2 | r3 r3 r3 r3 | g3 g3 g3 g3 | b3 b3 b3 b3 | r4 r4 r4
> r4 | g4 g4 g4 g4 | b4 b4 b4 b4

Yes, nPixelOffset = 1, nLineOffset = nBufferXSize * nBands, nBandOffset = 
nBufferXSize

> 
> BIP: r1 g1 b1 r2 | g2 b2 r3 g3 | b3 r4 g4 b4 | r1 g1 b1 r2 | g2 b2 r3
> g3 | b3 r4 g4 b4 | r1 g1 b1 r2 | g2 b2 r3 g3 | b3 r4 g4 b4 | r1 g1 b1
> r2 | g2 b2 r3 g3 | b3 r4 g4 b4

You meant :

r1 g1 b1 r1 g1 b1 r1 g1 b1 r1 g1 b1 |
r2 g2 b2 r2 g2 b2 r2 g2 b2 r2 g2 b2 |
r3 g3 b3 r3 g3 b3 r3 g3 b3 r3 g3 b3 |
r4 g4 b4 r4 g4 b4 r4 g4 b4 r4 g4 b4 |

right ?

And nPixelOffset = nBands, nLineOffset = nBands * nBufferXSize, nBandOffset = 1

> 
> Now my doubt.
> 
> Does "byte offset" mean the byte space between the start of 2 valid
> values in pData?

The maths will speak better...

If you output buffer starts at address pStart, for band b (numbered from 1) the 
value of the pixel at line j (numbered from 0), column i (numbered from 0) of 
the output buffer will be stored at :

pStart + i * nPixelSpace + j * nLineSpace + (b-1) * nBandSpace

So nPixelSpace is the difference between the address of a pixel and the pixel 
at its right on the same line.

> For example, the space between r1 and g1 in BIP
> format. I guess if there's no trailing bits in the array (all the bits
> are payload) the byte offset between the start of 2 valid values is
> always the size of the data type. Then simply r1 = pData[0] and g1 =
> pData[1] (BIP format)

Not sure to follow you, hopefully the above explinations will answer your 
question ;-)

> 
> Isn't it the most common situation? In which situation has sense
> having "gaps" between pixel values, or at the end of a row?

Sometimes you just want to override the values of an allocated buffer with 
greater extent, so you need to provide a so-called "line stride" that is 
greater than nBufferXSize.

> I think I
> don't really understand the sentence: "This is primarily used for
> buffers containing more than one bands raster data in interleaved
> format.".

I guess it means that if you need to read from different bands with multiple 
calls to RasterIO() but in the same buffer, you can tweak nPixelSize and 
nLineOffset to let enough space for data from different bands and match the 
organization of the data as you've designed it.

> 
> Thanks in advance, and best regards.
> Jorge
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Re: GDAL Newbie - Get Height from a DTED

[migelanjel]

It worked!
Thanks a lot for your help Chaitanya.
Seriously, thanks a lot.

--
View this message in context: 
http://osgeo-org.1803224.n2.nabble.com/GDAL-Newbie-Get-Height-from-a-DTED-tp6562549p6562986.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Unwanted partial transparency when clipping

[Michael Corey]

OK, I did a little more work on this, and I've narrowed down what's 
going on, but I could still use some help in figuring out how to solve it.


Here's my original image:

http://mikejcorey.com/spatial/diablo-orig-5pct.tif

The original appears to have an RGBA setup (RGB channels and an alpha 
channel).


When I run this:

gdalwarp -crop_to_cutline -cutline cutout.shp sourceimage.tif 
diablo-cutline.tif


Here's what I get:

http://mikejcorey.com/spatial/diablo-cutline-5pct.tif

This comes out as an RGB image with no alpha channel, with each channel 
being semi-transparent.


However, if I do this:

gdalwarp -dstalpha -crop_to_cutline -cutline cutout.shp sourceimage.tif 
diablo-dstalpha-cutline.tif


I get this:

http://mikejcorey.com/spatial/diablo-dstalpha-cutline-5pct.tif

This one is strange, because it appears to be a grayscale image. But 
when I open it in Photoshop, I see that it actually has 4 alpha 
channels. I suspect that those are just getting set incorrectly as alpha 
and are in fact the RGB channels, but can someone explain that behavior 
or how to fix it?


What I want to end up with is a clipped RGB image (or RGBA) image where 
nodata is transparent and the RGB isn't translucent.


Thanks again!

Michael Corey



On 7/7/11 7:13 AM, Eli Adam wrote:

Michael,


On 7/6/2011 at 5:35 PM, in message<4e14ff42.50...@cironline.org>, Michael

Corey  wrote:

Sure, I've uploaded samples here.

http://www.mikejcorey.com/spatial/diablo-box-sample.tif
http://www.mikejcorey.com/spatial/diablo-cutout-sample.tif

I don't notice the semi-transparency in these scaled down images.  Perhaps it 
is the way your viewer reads the mask?


These are the same as the images created by the process I described (but
scaled down).

To your point about specifying size in the first step -- will that make
the process run faster, or does it do the scaling down after it builds
the full-resolution image?

Also, I notice that my filesize always gets significantly bigger when I
do the cutout step, which seems counter-intuitive to me since in theory
shouldn't there be less information present once the cutout is done?

-cutline does not 'discard' any data.  The extent of the data remains the same 
unless you reset those extents.  You can do that with -crop_to_cutline.  Here 
are some details from the gdalwarp page, http://gdal.org/gdalwarp.html :

-crop_to_cutline:
 (GDAL>= 1.8.0) Crop the extent of the target dataset to the extent of the 
cutline.

Polygon cutlines may be used as a mask to restrict the area of the destination 
file that may be updated, including blending. If the OGR layer containing the 
cutline features has no explicit SRS, the cutline features must be in the 
georeferenced units of the destination file. When outputing to a not yet 
existing target dataset, its extent will be the one of the original raster 
unless -te or -crop_to_cutline are specified.

Best Regards, Eli


Thanks for your help!

Michael Corey


On 7/6/11 5:01 PM, Chaitanya kumar CH wrote:

Michael,

Can you provide screenshots of
diablo-combined-center-utm10-70pct-box.tif and
diablo-combined-center-utm10-70pct-cutout.tif for comparison?

By the way, you can perform the actions of the two gdal_translate
commands in the first step with the gdal_merge.py script itself unless
you want to use a specific resampling algorithm.

On Thu, Jul 7, 2011 at 4:28 AM, Michael Coreymailto:mco...@cironline.org>>  wrote:

 Hi all:

 I'm using a shapefile as a clipping mask to cut out the shoreline
 from some DOQ files that I have merged together. But when I do the
 clipping step, I end up with unwanted semitransparency in the
 non-clipped areas.

 I'm pretty sure the problem is only with my gdalwarp step at the end.

 Here's my process:

 gdal_merge.py -init "255" -o diablo-combined-center-utm10.tif file
 file file file

 gdal_translate -outsize 70% 70% diablo-combined-center-utm10.tif
 diablo-combined-center-utm10-70pct.tif

 ogrinfo -al ./diablo_canyon_detail_clipper.shp
 //Extent: (, ) - (, )

 gdal_translate -projwin    
 diablo-combined-center-utm10-70pct.tif
 diablo-combined-center-utm10-70pct-box.tif

 gdalwarp -co COMPRESS=DEFLATE -cutline
 ./diablo_canyon_detail_clipper.shp
 diablo-combined-center-utm10-70pct-box.tif
 diablo-combined-center-utm10-70pct-cutout.tif

 Can anyone help?

 Thanks!

 --
 Michael Corey

 ___
 gdal-dev mailing list
 gdal-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/gdal-dev




--
Best regards,
Chaitanya kumar CH.
/t?a???nj?/ /k?m?r/
+91-9494447584
17.2416N 80.1426E

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Fwd: Re: [Live-demo] Re: Liberal licensing of Project Overviews in LiveDVD, do we want this?

[Frank Warmerdam]

On Fri, Jul 8, 2011 at 1:34 AM, Ari Jolma  wrote:
> Would it be enough to add something to the Doxyfile tag HTML_FOOTER, which
> states what the documentation is? That way it gets to the bottom of every
> page of gdal.org. The footer can't be the whole licence, though. MIT licence
> does not seem to have a definitive web page and the wikipedia page states
> that "MIT Licence" is ambiguous.

Ari,

I would agree having a standard statement in the footer makes sense
and I would suggest it be url linked to:

http://trac.osgeo.org/gdal/wiki/FAQGeneral#WhatlicensedoesGDALOGRuse

which might be clarified a bit (and also the LICENSE file) with regard to
documentation.

Best regards,
-- 
---+--
I set the clouds in motion - turn up   | Frank Warmerdam, warmer...@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Software Developer
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] export 3D shapefile to 2D (-lco dim=2 not is not used by the shp driver)

[G. Allegri]

Great! thanks Chaitanya, -nlt POLYGON did the work ;)

giovanni

2011/7/8 Chaitanya kumar CH 

> Giovanni,
>
> If your shapefile contains only one type of geometry, you can use the -nlt
> option in ogr2ogr. Using a geometry type without the '25D' postfix should
> remove the Z values.
>
> On Fri, Jul 8, 2011 at 6:19 PM, G. Allegri  wrote:
>
>> Looking at the shp driver I see that the -lco dim option is not used.
>> Is there another way to tranform a 3D polygon to 2D thorugh ogr2ogr?
>>
>> thanks,
>> giovanni
>>
>> ___
>> gdal-dev mailing list
>> gdal-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>
>
>
> --
> Best regards,
> Chaitanya kumar CH.
>
> +91-9494447584
> 17.2416N 80.1426E
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Meaning of nPixelSpace/nLineSpace in IRasterIO

[Jorge Arévalo]

Hello,

I'm not sure of the meaning of nPixelSpace, nLineSpace IRasterIO args.
>From GDAL doc I read:

nPixelSpace: The byte offset from the start of one pixel value in
pData to the start of the next pixel value within a scanline. If
defaulted (0) the size of the datatype eBufType is used.

nLineSpace: The byte offset from the start of one scanline in pData to
the start of the next. If defaulted (0) the size of the datatype
eBufType * nBufXSize is used.

and

The nPixelSpace and nLineSpace parameters allow reading into or
writing from unusually organized buffers. This is primarily used for
buffers containing more than one bands raster data in interleaved
format.

I know there are, basically, 3 interleave formats:

BSQ (INTERLEAVE=BAND)
BIL (INTERLEAVE=LINE)
BIP (INTERLEAVE=PIXEL)

Assuming a 3-bands (rgb) 4x4 raster, the pData array would look like
this ("|" used only to mark the end of a row):

BSQ: r1 r1 r1 r1 | r2 r2 r2 r2 | r3 r3 r3 r3 | r4 r4 r4 r4 | g1 g1 g1
g1 | g2 g2 g2 g2 | g3 g3 g3 g3 | g4 g4 g4 g4 g4 | b1 b1 b1 b1 | b2 b2
b2 b2 | b3 b3 b3 b3 | b4 b4 b4 b4

BIL: r1 r1 r1 r1 | g1 g1 g1 g1 | b1 b1 b1 b1 | r2 r2 r2 r2 | g2 g2 g2
g2 | b2 b2 b2 b2 | r3 r3 r3 r3 | g3 g3 g3 g3 | b3 b3 b3 b3 | r4 r4 r4
r4 | g4 g4 g4 g4 | b4 b4 b4 b4

BIP: r1 g1 b1 r2 | g2 b2 r3 g3 | b3 r4 g4 b4 | r1 g1 b1 r2 | g2 b2 r3
g3 | b3 r4 g4 b4 | r1 g1 b1 r2 | g2 b2 r3 g3 | b3 r4 g4 b4 | r1 g1 b1
r2 | g2 b2 r3 g3 | b3 r4 g4 b4

Now my doubt.

Does "byte offset" mean the byte space between the start of 2 valid
values in pData? For example, the space between r1 and g1 in BIP
format. I guess if there's no trailing bits in the array (all the bits
are payload) the byte offset between the start of 2 valid values is
always the size of the data type. Then simply r1 = pData[0] and g1 =
pData[1] (BIP format)

Isn't it the most common situation? In which situation has sense
having "gaps" between pixel values, or at the end of a row? I think I
don't really understand the sentence: "This is primarily used for
buffers containing more than one bands raster data in interleaved
format.".

Thanks in advance, and best regards.
Jorge

-- 
Jorge Arévalo
Internet & Mobility Division, DEIMOS
jorge.arev...@deimos-space.com
http://es.linkedin.com/in/jorgearevalo80
http://mobility.grupodeimos.com/
http://gis4free.wordpress.com
http://geohash.org/ezjqgrgzz0g
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL Newbie - Get Height from a DTED

[Chaitanya kumar CH]

Migel,

You have the corner coordinates. Now you need to know the pixel value at a
particular position. You can calculate the pixel value from the projection
coordinates using the affine transformation coordinates. You can get the
these coordinates using GDALDataset::GetGeoTransform() method. Knowing the
pixel/line information, you can read the pixel value using
GDALDataset::RasterIO().

You can check out the code [1] of the gdallocationinfo utility [2].

[1]: http://trac.osgeo.org/gdal/browser/trunk/gdal/apps/gdallocationinfo.cpp
[2]: http://www.gdal.org/gdallocationinfo.html

On Fri, Jul 8, 2011 at 7:15 PM, migelanjel  wrote:

> Hello there!
> First let me you that i'm quite new in this, so if there's anything that
> you
> may is basic, please let me know anyway, cause to me it may be the puzzle
> piece i'm missing.
>
> So, here's what i need to do. I have a DTED file (dt2), and i'm trying to
> get the elevation data to map it over a jpg image, and show it in the
> screen
> so i can know the elevation of the point the mouse is over in any moment.
> I've loaded the DTED file, and i've been able to read the coordinates of
> the
> corners of te raster band, but i don't if i can get the elevation data in a
> numeric way. I've been reading the doc in the GDAL website but all i could
> find about this was "How to draw the data to images".
>
> Could anyone tell me how to get the numeric elevation data?
>
> I'm using the C# inteface (because i'll be using XNA to do all the
> drawing),
> but i can understand C, and a little bit of C++ too, so don't worry about
> that.
>
> Thanks a lot for reading this!
>
> --
> View this message in context:
> http://osgeo-org.1803224.n2.nabble.com/GDAL-Newbie-Get-Height-from-a-DTED-tp6562549p6562549.html
> Sent from the GDAL - Dev mailing list archive at Nabble.com.
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>



-- 
Best regards,
Chaitanya kumar CH.

+91-9494447584
17.2416N 80.1426E
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] export 3D shapefile to 2D (-lco dim=2 not is not used by the shp driver)

[Chaitanya kumar CH]

Giovanni,

If your shapefile contains only one type of geometry, you can use the -nlt
option in ogr2ogr. Using a geometry type without the '25D' postfix should
remove the Z values.

On Fri, Jul 8, 2011 at 6:19 PM, G. Allegri  wrote:

> Looking at the shp driver I see that the -lco dim option is not used.
> Is there another way to tranform a 3D polygon to 2D thorugh ogr2ogr?
>
> thanks,
> giovanni
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>



-- 
Best regards,
Chaitanya kumar CH.

+91-9494447584
17.2416N 80.1426E
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] GDAL Newbie - Get Height from a DTED

[migelanjel]

Hello there!
First let me you that i'm quite new in this, so if there's anything that you
may is basic, please let me know anyway, cause to me it may be the puzzle
piece i'm missing.

So, here's what i need to do. I have a DTED file (dt2), and i'm trying to
get the elevation data to map it over a jpg image, and show it in the screen
so i can know the elevation of the point the mouse is over in any moment.
I've loaded the DTED file, and i've been able to read the coordinates of the
corners of te raster band, but i don't if i can get the elevation data in a
numeric way. I've been reading the doc in the GDAL website but all i could
find about this was "How to draw the data to images".

Could anyone tell me how to get the numeric elevation data?

I'm using the C# inteface (because i'll be using XNA to do all the drawing),
but i can understand C, and a little bit of C++ too, so don't worry about
that.

Thanks a lot for reading this!

--
View this message in context: 
http://osgeo-org.1803224.n2.nabble.com/GDAL-Newbie-Get-Height-from-a-DTED-tp6562549p6562549.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] export 3D shapefile to 2D (-lco dim=2 not is not used by the shp driver)

[G. Allegri]

Looking at the shp driver I see that the -lco dim option is not used.
Is there another way to tranform a 3D polygon to 2D thorugh ogr2ogr?

thanks,
giovanni
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] to create a rectangle polygon

[Chaitanya kumar CH]

Ahmet,

You can clip a shapefile using ogr2ogr using the option -spat [1]. There are
more options to control the clipping of polygons intersecting the border.

[1]: http://www.gdal.org/ogr2ogr.html

2011/7/8 ahmet temiz 

> hello
>
> Is it possible to create a rectangle polygon shp file from known minx,
> miny, maxx, maxy values using ogr2ogr ?
>
> regards
>
> --
> Ahmet Temiz
> Jeoloji Müh.
> Afet ve Acil Durum Yönetimi Başkanlığı
> Planlama ve Zarar Azaltma Dairesi Başkanlığı
> Bilgi ve CBS grubu
> Eskişehir Yolu 10. km.
> Lodumlu / Ankara
> Tel : 0 312 2872680 / 1535
> 
>
> Ahmet Temiz
> Geological Eng.
> Information Systems - GIS Group
> Disaster and Emergency Management
> of Presidency
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>



-- 
Best regards,
Chaitanya kumar CH.

+91-9494447584
17.2416N 80.1426E
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Re: gdal compile question

[George C]

ahhh ok, so "ar" is a valid command, a command that's probably not on my path.  
I'll have to check that out.

Thanks,
George





From: Frank Warmerdam 
To: George C 
Sent: Fri, July 8, 2011 1:17:56 AM
Subject: Re: gdal compile question

On Thu, Jul 7, 2011 at 3:47 PM, George C  wrote:
> /bin/sh: ar: not found

George,

For whatever reason it does not appear that ar, the archive (library)
manager is in the path.  Sometimes it lives in a funky spot on solaris.
It is needed to build GDAL.

Best regards,
-- 
---+--
I set the clouds in motion - turn up   | Frank Warmerdam, warmer...@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] RPC and DEM = Too many points (441 out of 441) failed to transform

[Goo Creations]

Hi,

I've tried that, but without any success. I have no problem warping the
image, that works fine. The problem comes in when I try to warp with the
DEM.

Chris



On Fri, Jul 8, 2011 at 1:12 PM, Chaitanya kumar CH
wrote:

> Chris,
>
> This could happen when you try to transform an image that is outside the
> defined area of the destination projection.
> Cut the raster to the destination projection's extents and try again.
>
> There is a thread with exactly the same error message in the archives[1]. I
> am not sure that it can help with your case, but try it anyway.
>
> http://lists.osgeo.org/pipermail/gdal-dev/2010-June/024846.html
>
> On Fri, Jul 8, 2011 at 1:08 PM, Goo Creations wrote:
>
>> Hi,
>>
>> I've seen that there are quite a lot of messages on this problem, but none
>> of them helped. When running the following command:
>>
>>   gdalwarp -rpc raw.tif out.tif
>>
>> with a raw.tif and raw.rpb file, the image "orthorectifies" correctly. The
>> moment I run:
>>
>>   gdalwarp -rpc -to RPC_DEM=dem.tif raw.tif out.tif
>>
>> I get the following error:
>>
>>   ERROR 1: Too many points (441 out of 441) failed to transform,
>> unable to compute output bounds.
>>
>> I've attached the info of raw.tif. Does anyone know what went wrong, and
>> is this beacuse of DEM, or is it another problem?
>>
>> Thanks
>> Chris
>>
>>
>>
>>
>>
>>
>>
>> Driver: GTiff/GeoTIFF
>> Files: raw.tif
>>raw.rpb
>> Size is 9628, 8447
>> Coordinate System is:
>> GEOGCS["WGS 84",
>> DATUM["WGS_1984",
>> SPHEROID["WGS 84",6378137,298.257223563,
>> AUTHORITY["EPSG","7030"]],
>> AUTHORITY["EPSG","6326"]],
>> PRIMEM["Greenwich",0],
>> UNIT["degree",0.0174532925199433],
>> AUTHORITY["EPSG","4326"]]
>> Origin = (30.913295622484902,-24.802523524387549)
>> Pixel Size = (0.67480021901,-0.67480021901)
>> Metadata:
>>   AREA_OR_POINT=Area
>> Image Structure Metadata:
>>   INTERLEAVE=PIXEL
>> RPC Metadata:
>>   LINE_OFF=4080
>>   SAMP_OFF=4576.5
>>   LAT_OFF=-25.0395787325761
>>   LONG_OFF=31.1554993454694
>>   HEIGHT_OFF=0
>>   LINE_SCALE=3914.5
>>   SAMP_SCALE=4294
>>   LAT_SCALE=1
>>   LONG_SCALE=1
>>   HEIGHT_SCALE=4.5035996273705e+15
>>   LINE_NUM_COEFF=-0.145866801707571 -1.10329711280747 -3.86239597262447
>> +2.58933660668099e-10 -28.872773220706 +2.68554381444917e-11
>> +2.66066678274063e-13 +0.233414015098293 -1.76613654297724
>> +6.43648576886715e-14 +1.49832649397565e-14 -0.206809394779316
>> +0.550008018810227 +5.15954998919738e-15 +4.01585276272362 +5.22420802294871
>> -1.73715368640512e-16 +1.01499936423132e-19 -3.38302233536952e-25 +0
>>   LINE_DEN_COEFF=+1 +7.63015898979327 +0.544533603046993 +0
>> -0.173000384439342 +0 +0 -1.00151575139611 -1.37010848384519 +0 +0
>> -0.202476730291588 +0.437634611086632 +0 -0.87007813002919
>> -0.375773326407855 +0 +0 +0 +0
>>   SAMP_NUM_COEFF=-0.231718719424942 +1.76982471507257 -0.14795750431688
>> -4.73119373784374e-10 +2.13811836283462 -3.85268609241549e-12
>> -2.35309943560894e-12 +25.3990915415468 +0.254311877067769
>> -2.89679792247779e-14 -8.37241260945736e-14 -2.08642871782854
>> -2.73075356366074 -3.49988405044981e-16 +0.172374026544827
>> -0.0126270588964211 -1.11561975938353e-16 +1.4727767628272e-19
>> +5.24269370859074e-25 +0
>>   SAMP_DEN_COEFF=+1 +7.29237513919745 +0.620858828859381 +0
>> +0.081413241118419 +0 +0 -0.640261879817039 -0.844565609956026 +0 +0
>> +0.357196796854916 +0.0314112080522133 +0 +0.0594674065444518
>> +0.355916093810033 +0 +0 +0 +0
>> Corner Coordinates:
>> Upper Left  (  30.9132956, -24.8025235) ( 30d54'47.86"E, 24d48' 9.08"S)
>> Lower Left  (  30.9132956, -25.3725273) ( 30d54'47.86"E, 25d22'21.10"S)
>> Upper Right (  31.5629933, -24.8025235) ( 31d33'46.78"E, 24d48' 9.08"S)
>> Lower Right (  31.5629933, -25.3725273) ( 31d33'46.78"E, 25d22'21.10"S)
>> Center  (  31.2381444, -25.0875254) ( 31d14'17.32"E, 25d 5'15.09"S)
>> Band 1 Block=9628x1 Type=UInt16, ColorInterp=Gray
>> Band 2 Block=9628x1 Type=UInt16, ColorInterp=Undefined
>> Band 3 Block=9628x1 Type=UInt16, ColorInterp=Undefined
>>
>>
>> ___
>> gdal-dev mailing list
>> gdal-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>
>
>
> --
> Best regards,
> Chaitanya kumar CH.
>
> +91-9494447584
> 17.2416N 80.1426E
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] to create a rectangle polygon

[ahmet temiz]

hello

Is it possible to create a rectangle polygon shp file from known minx,
miny, maxx, maxy values using ogr2ogr ?

regards

-- 
Ahmet Temiz
Jeoloji Müh.
Afet ve Acil Durum Yönetimi Başkanlığı
Planlama ve Zarar Azaltma Dairesi Başkanlığı
Bilgi ve CBS grubu
Eskişehir Yolu 10. km.
Lodumlu / Ankara
Tel : 0 312 2872680 / 1535


Ahmet Temiz
Geological Eng.
Information Systems - GIS Group
Disaster and Emergency Management
of Presidency
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] RPC and DEM = Too many points (441 out of 441) failed to transform

[Chaitanya kumar CH]

Chris,

This could happen when you try to transform an image that is outside the
defined area of the destination projection.
Cut the raster to the destination projection's extents and try again.

There is a thread with exactly the same error message in the archives[1]. I
am not sure that it can help with your case, but try it anyway.

http://lists.osgeo.org/pipermail/gdal-dev/2010-June/024846.html

On Fri, Jul 8, 2011 at 1:08 PM, Goo Creations wrote:

> Hi,
>
> I've seen that there are quite a lot of messages on this problem, but none
> of them helped. When running the following command:
>
>   gdalwarp -rpc raw.tif out.tif
>
> with a raw.tif and raw.rpb file, the image "orthorectifies" correctly. The
> moment I run:
>
>   gdalwarp -rpc -to RPC_DEM=dem.tif raw.tif out.tif
>
> I get the following error:
>
>   ERROR 1: Too many points (441 out of 441) failed to transform,
> unable to compute output bounds.
>
> I've attached the info of raw.tif. Does anyone know what went wrong, and is
> this beacuse of DEM, or is it another problem?
>
> Thanks
> Chris
>
>
>
>
>
>
>
> Driver: GTiff/GeoTIFF
> Files: raw.tif
>raw.rpb
> Size is 9628, 8447
> Coordinate System is:
> GEOGCS["WGS 84",
> DATUM["WGS_1984",
> SPHEROID["WGS 84",6378137,298.257223563,
> AUTHORITY["EPSG","7030"]],
> AUTHORITY["EPSG","6326"]],
> PRIMEM["Greenwich",0],
> UNIT["degree",0.0174532925199433],
> AUTHORITY["EPSG","4326"]]
> Origin = (30.913295622484902,-24.802523524387549)
> Pixel Size = (0.67480021901,-0.67480021901)
> Metadata:
>   AREA_OR_POINT=Area
> Image Structure Metadata:
>   INTERLEAVE=PIXEL
> RPC Metadata:
>   LINE_OFF=4080
>   SAMP_OFF=4576.5
>   LAT_OFF=-25.0395787325761
>   LONG_OFF=31.1554993454694
>   HEIGHT_OFF=0
>   LINE_SCALE=3914.5
>   SAMP_SCALE=4294
>   LAT_SCALE=1
>   LONG_SCALE=1
>   HEIGHT_SCALE=4.5035996273705e+15
>   LINE_NUM_COEFF=-0.145866801707571 -1.10329711280747 -3.86239597262447
> +2.58933660668099e-10 -28.872773220706 +2.68554381444917e-11
> +2.66066678274063e-13 +0.233414015098293 -1.76613654297724
> +6.43648576886715e-14 +1.49832649397565e-14 -0.206809394779316
> +0.550008018810227 +5.15954998919738e-15 +4.01585276272362 +5.22420802294871
> -1.73715368640512e-16 +1.01499936423132e-19 -3.38302233536952e-25 +0
>   LINE_DEN_COEFF=+1 +7.63015898979327 +0.544533603046993 +0
> -0.173000384439342 +0 +0 -1.00151575139611 -1.37010848384519 +0 +0
> -0.202476730291588 +0.437634611086632 +0 -0.87007813002919
> -0.375773326407855 +0 +0 +0 +0
>   SAMP_NUM_COEFF=-0.231718719424942 +1.76982471507257 -0.14795750431688
> -4.73119373784374e-10 +2.13811836283462 -3.85268609241549e-12
> -2.35309943560894e-12 +25.3990915415468 +0.254311877067769
> -2.89679792247779e-14 -8.37241260945736e-14 -2.08642871782854
> -2.73075356366074 -3.49988405044981e-16 +0.172374026544827
> -0.0126270588964211 -1.11561975938353e-16 +1.4727767628272e-19
> +5.24269370859074e-25 +0
>   SAMP_DEN_COEFF=+1 +7.29237513919745 +0.620858828859381 +0
> +0.081413241118419 +0 +0 -0.640261879817039 -0.844565609956026 +0 +0
> +0.357196796854916 +0.0314112080522133 +0 +0.0594674065444518
> +0.355916093810033 +0 +0 +0 +0
> Corner Coordinates:
> Upper Left  (  30.9132956, -24.8025235) ( 30d54'47.86"E, 24d48' 9.08"S)
> Lower Left  (  30.9132956, -25.3725273) ( 30d54'47.86"E, 25d22'21.10"S)
> Upper Right (  31.5629933, -24.8025235) ( 31d33'46.78"E, 24d48' 9.08"S)
> Lower Right (  31.5629933, -25.3725273) ( 31d33'46.78"E, 25d22'21.10"S)
> Center  (  31.2381444, -25.0875254) ( 31d14'17.32"E, 25d 5'15.09"S)
> Band 1 Block=9628x1 Type=UInt16, ColorInterp=Gray
> Band 2 Block=9628x1 Type=UInt16, ColorInterp=Undefined
> Band 3 Block=9628x1 Type=UInt16, ColorInterp=Undefined
>
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>



-- 
Best regards,
Chaitanya kumar CH.

+91-9494447584
17.2416N 80.1426E
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Change the spatial reference of a shapeile

[Chaitanya kumar CH]

Solimyr,

For shapefiles just copying and renaming the .prj file might be enough.
Extents can be computed and stored using the ogr2ogr utility.

If copying the .prj file didn't work, you can use the -s_srs option in the
ogr2ogr utility. You can get the SRS WKT from the ogrinfo output.

Of course, you can do this programatically using OGRDataSource::CopyLayer()
method. The spatial reference has to be set to each layer in a datasource.
There is no GeoTransform. You can force calculation of extent using
OGRLayer::GetExtent() method.

http://www.gdal.org/ogr_utilities.html
http://www.gdal.org/ogr/ogr_arch.html
http://www.gdal.org/ogr/annotated.html


On Fri, Jul 8, 2011 at 3:48 PM, Solimyr  wrote:

> Hi guys,
> I have two shapefile with same features but one miss the extent and the
> projection. What I want to do is copy the extent and the projection from
> the
> first and set to the second. I did something  similar with two images using
> these step:
>
> inputimg = gdal.Open(str(fileName), GA_ReadOnly)
> gdalformat= inputimg.GetDriver().ShortName
> geoinput = inputimg.GetGeoTransform()
> projinput= inputimg.GetProjection()
> ..
> outimg = gdal.Open(str(result), GA_Update)
> outimg.SetProjection(projinput)
> outimg.SetGeoTransform(geoinput)
>
>
> Do you know if there is something similar to this but for shapefile? Do you
> have any suggests?
> thx
>
> --
> View this message in context:
> http://osgeo-org.1803224.n2.nabble.com/Change-the-spatial-reference-of-a-shapeile-tp6561998p6561998.html
> Sent from the GDAL - Dev mailing list archive at Nabble.com.
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>



-- 
Best regards,
Chaitanya kumar CH.

+91-9494447584
17.2416N 80.1426E
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Change the spatial reference of a shapeile

[Solimyr]

Hi guys,
I have two shapefile with same features but one miss the extent and the
projection. What I want to do is copy the extent and the projection from the
first and set to the second. I did something  similar with two images using
these step:

inputimg = gdal.Open(str(fileName), GA_ReadOnly) 
gdalformat= inputimg.GetDriver().ShortName
geoinput = inputimg.GetGeoTransform()
projinput= inputimg.GetProjection()
..
outimg = gdal.Open(str(result), GA_Update)
outimg.SetProjection(projinput)
outimg.SetGeoTransform(geoinput)


Do you know if there is something similar to this but for shapefile? Do you
have any suggests?
thx

--
View this message in context: 
http://osgeo-org.1803224.n2.nabble.com/Change-the-spatial-reference-of-a-shapeile-tp6561998p6561998.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Fwd: Re: [Live-demo] Re: Liberal licensing of Project Overviews in LiveDVD, do we want this?

[Ari Jolma]

On 07/08/2011 07:55 AM, Even Rouault wrote:

Hi,

below Simon's answer to my answers to his post on the live-demo list :
http://lists.osgeo.org/pipermail/live-demo/2011-July/003653.html

Do you have opinions on how we should handle the licence of documentation on
gdal.org ?


Would it be enough to add something to the Doxyfile tag HTML_FOOTER, 
which states what the documentation is? That way it gets to the bottom 
of every page of gdal.org. The footer can't be the whole licence, 
though. MIT licence does not seem to have a definitive web page and the 
wikipedia page states that "MIT Licence" is ambiguous.


Regards,

Ari


Best regards,

Even


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] installing gdal for iOS development

[Paul Lohr]

I have the build_for_iphoneos.sh script from pseudogreen.com along with 
gdal-1.8.0. I am trying to get GDAL installed so I can start learning how to 
use 

it with iOS devices (iPhone, iPad).

Xcode is version 3.2.5 and the iOS SDK is version 4.2. I have Xcode 4.2 and iOS 
5.0 installed but they are not in the same folders as the earlier versions.

I am getting at least two error messages. When I run build_for_iphoneos.sh, 
this 

is the first error that is returned in the config.log file: "conftest.c:59:22: 
error: dbmalloc.h: No such file or directory". I read somewhere to find the 
earliest error message and deal with that first.

While the build_for_iphoneos.sh script is running in the terminal window, it 
stops running after this message appears: 
"/Developer4.2/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk/usr/include/architecture/arm/math.h:475:

error: expected initializer before ‘__AVAILABILITY_INTERNAL__IPHONE_3_2’
make[3]: *** [../o/ogrsqlitedatasource.lo] Error 1
make[2]: *** [sqlite-target] Error 2
make[1]: *** [sublibs] Error 2
make: *** [ogr-target] Error 2"

The build_for_iphoneos.sh script can be found here:
http://pseudogreen.org/bzr/sandbox/iphone/build_for_iphoneos

Should I deal with the dbmalloc.h error first? Any ideas what to do to correct 
this?

Thank you for any help,
Paul Lohr
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] RPC and DEM = Too many points (441 out of 441) failed to transform

[Goo Creations]

Hi,

I've seen that there are quite a lot of messages on this problem, but none
of them helped. When running the following command:

  gdalwarp -rpc raw.tif out.tif

with a raw.tif and raw.rpb file, the image "orthorectifies" correctly. The
moment I run:

  gdalwarp -rpc -to RPC_DEM=dem.tif raw.tif out.tif

I get the following error:

  ERROR 1: Too many points (441 out of 441) failed to transform,
unable to compute output bounds.

I've attached the info of raw.tif. Does anyone know what went wrong, and is
this beacuse of DEM, or is it another problem?

Thanks
Chris







Driver: GTiff/GeoTIFF
Files: raw.tif
   raw.rpb
Size is 9628, 8447
Coordinate System is:
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433],
AUTHORITY["EPSG","4326"]]
Origin = (30.913295622484902,-24.802523524387549)
Pixel Size = (0.67480021901,-0.67480021901)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  INTERLEAVE=PIXEL
RPC Metadata:
  LINE_OFF=4080
  SAMP_OFF=4576.5
  LAT_OFF=-25.0395787325761
  LONG_OFF=31.1554993454694
  HEIGHT_OFF=0
  LINE_SCALE=3914.5
  SAMP_SCALE=4294
  LAT_SCALE=1
  LONG_SCALE=1
  HEIGHT_SCALE=4.5035996273705e+15
  LINE_NUM_COEFF=-0.145866801707571 -1.10329711280747 -3.86239597262447
+2.58933660668099e-10 -28.872773220706 +2.68554381444917e-11
+2.66066678274063e-13 +0.233414015098293 -1.76613654297724
+6.43648576886715e-14 +1.49832649397565e-14 -0.206809394779316
+0.550008018810227 +5.15954998919738e-15 +4.01585276272362 +5.22420802294871
-1.73715368640512e-16 +1.01499936423132e-19 -3.38302233536952e-25 +0
  LINE_DEN_COEFF=+1 +7.63015898979327 +0.544533603046993 +0
-0.173000384439342 +0 +0 -1.00151575139611 -1.37010848384519 +0 +0
-0.202476730291588 +0.437634611086632 +0 -0.87007813002919
-0.375773326407855 +0 +0 +0 +0
  SAMP_NUM_COEFF=-0.231718719424942 +1.76982471507257 -0.14795750431688
-4.73119373784374e-10 +2.13811836283462 -3.85268609241549e-12
-2.35309943560894e-12 +25.3990915415468 +0.254311877067769
-2.89679792247779e-14 -8.37241260945736e-14 -2.08642871782854
-2.73075356366074 -3.49988405044981e-16 +0.172374026544827
-0.0126270588964211 -1.11561975938353e-16 +1.4727767628272e-19
+5.24269370859074e-25 +0
  SAMP_DEN_COEFF=+1 +7.29237513919745 +0.620858828859381 +0
+0.081413241118419 +0 +0 -0.640261879817039 -0.844565609956026 +0 +0
+0.357196796854916 +0.0314112080522133 +0 +0.0594674065444518
+0.355916093810033 +0 +0 +0 +0
Corner Coordinates:
Upper Left  (  30.9132956, -24.8025235) ( 30d54'47.86"E, 24d48' 9.08"S)
Lower Left  (  30.9132956, -25.3725273) ( 30d54'47.86"E, 25d22'21.10"S)
Upper Right (  31.5629933, -24.8025235) ( 31d33'46.78"E, 24d48' 9.08"S)
Lower Right (  31.5629933, -25.3725273) ( 31d33'46.78"E, 25d22'21.10"S)
Center  (  31.2381444, -25.0875254) ( 31d14'17.32"E, 25d 5'15.09"S)
Band 1 Block=9628x1 Type=UInt16, ColorInterp=Gray
Band 2 Block=9628x1 Type=UInt16, ColorInterp=Undefined
Band 3 Block=9628x1 Type=UInt16, ColorInterp=Undefined
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] SetAttributeFilter has no effect ?

[Even Rouault]

Selon ahmet temiz :

GetFeature(n) returns the feature such as feature.GetFID() == n, so attribute or
spatial filter are not taken into account.

If you want to iterate over the feature of the layers, and take into account
filters, you have to use GetNextFeature(), until it returns null.

> hello
>
> I tried to implement SetAttributeFilter with a critaria.
>  There seems to have no effect on getting data.
>
> what might be wrong ?
>
> I am still getting all data
>
> here is the code fragment.
>
> ly2.SetAttributeFilter("il='kastamonu'");
>
>
>   for (int i = 0;i<1244; i++) {
>   Feature f = ly2.GetFeature(i);
>   System.out.print(f.GetFID());
>   System.out.println(" " + f.GetFieldAsString("il"));
>   System.out.println(" " + f.GetFieldAsString("ilce"));
>   System.out.println(" " + f.GetFieldAsString("koy"));
>   System.out.println(" " + 
> f.GetFieldAsString("etkili_nak"));
>   //System.out.println(" " + f.GetFieldAsString("lkod"));
>
>
>   out.print(f.GetFID());
>   out.print(" " + f.GetFieldAsString("il"));
>   out.println(" " + f.GetFieldAsString("koy"));
>
>   }
>
>
> regards
> --
> Ahmet Temiz
> Jeoloji Müh.
> Afet ve Acil Durum Yönetimi Baþkanlýðý
> Planlama ve Zarar Azaltma Dairesi Baþkanlýðý
> Bilgi ve CBS grubu
> Eskiþehir Yolu 10. km.
> Lodumlu / Ankara
> Tel : 0 312 2872680 / 1535
> 
>
> Ahmet Temiz
> Geological Eng.
> Information Systems - GIS Group
> Disaster and Emergency Management
> of Presidency
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev