[gdal-dev] Building GDAL with FileGDB support

2012-02-22 Thread Stuart Edwards 

Hi - 

I am trying to build GDAL with FileGDB support on Ubuntu 10.4 using the recipe 
on the GDAL wiki.  I have installed GDAL 1.9.0 in /usr/local/ and have placed 
FileGDB_API from the ArcGIS resource center at /usr/local.  Configure 
--with-fgdb produces a config summary that shows 'yes' for 'with fgdb support'. 
 However, after 'make' and 'make install', the tests for ogrinfo fail - no 
FileGDB format is acknowledged.  I have put the FileGDB_API directory in the 
GDAL_DRIVER_PATH.  

Any ideas on what I may have done incorrectly would be much appreciated.

thx

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

Re: [gdal-dev] Re: learning GDAL with C/C++

2012-02-22 Thread Frank Warmerdam 
On Wed, Feb 22, 2012 at 7:12 PM, joseph.nalluri
 wrote:
> Thanks.
> I have a .bil file with an associated .hdr file with metadata. Do I have to
> read in the .hdr file and manually prepare the variables or is there a
> specified function? I could not find much info. about .hdr file.
> I am not sure what should the values be for pixel height and pixel width. I
> am using a 16 bit resolution camera.
> Can you advise me on what steps I need to undertake when creating a C prog
> which would be inputted with a .bil file?
>

Joseph,

GDAL should automatically read the .hdr file if you call
GDALOpen() on the .bil file.

You can test in advance with gdalinfo by running gdalinfo
against your .bil file.

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

[gdal-dev] Re: learning GDAL with C/C++

2012-02-22 Thread joseph.nalluri 

Frank Warmerdam wrote
> 
> Joseph,
> 
> I'd start with http://www.gdal.org/gdal_tutorial.html, the general purpose
> API tutorial.  It isn't comprehensive, but I think it is fairly good for
> the
> areas covered.
> 
> Note that GDAL does not directly help with distributed processing.  I
> assume this is what you mean by running on a cluster.  You could
> take care of farming out chunks yourself or have each process on the
> cluster use GDAL to read chunks, but be cautious about writing to
> one file from multiple processes.
> 
> Best regards,
> Frank
> 
> On Tue, Feb 21, 2012 at 11:50 AM, joseph.nalluri
>  wrote:
>> Hello All,
>>
>>  I am very pleased to find this forum. This is my first post. Please bear
>> with me. In my project, I am trying to read in .bil file (hyperspectral
>> image) into my C/C++ code. ( I haven't done this yet, because I am still
>> trying to see, how can I do it).
>>  After I read in, I run some image processing algorithms on it and
>> perform
>> this on a cluster. Is there a good tutorial/guide on this aspect, which
>> could help me out.
>>  Any help would be greatly appreciated. I am just starting out on this.
>>
>> Thanks,
>> Joseph
>>
>> --
>> View this message in context:
>> http://osgeo-org.1560.n6.nabble.com/gdal-dev-learning-GDAL-with-C-C-tp4492722p4492722.html
>> Sent from the GDAL - Dev mailing list archive at Nabble.com.
>> ___
>> gdal-dev mailing list
>> gdal-dev@.osgeo
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
> 
> 
> 
> -- 
> ---+--
> I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@
> 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@.osgeo
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
> 

Thanks. 
I have a .bil file with an associated .hdr file with metadata. Do I have to
read in the .hdr file and manually prepare the variables or is there a
specified function? I could not find much info. about .hdr file.
I am not sure what should the values be for pixel height and pixel width. I
am using a 16 bit resolution camera.
Can you advise me on what steps I need to undertake when creating a C prog
which would be inputted with a .bil file?

Sincerely,
Joseph


--
View this message in context: 
http://osgeo-org.1560.n6.nabble.com/gdal-dev-learning-GDAL-with-C-C-tp4492722p4497346.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] SetSpatialFilter

2012-02-22 Thread Even Rouault 
Le jeudi 23 février 2012 00:31:55, Ethan Alpert a écrit :
> Is it still true that the geometry used for SetSpatialFilter must have
> the same CRS as the layer?

Yes, the only OGR driver that does the reprojection that I'm aware of  is the 
FileGDB driver. Other drivers will happily ignore any CRS set on the geometry 
passed to SetSpatialFilter

> 
> 
> This electronic communication and any attachments may contain confidential
> and proprietary information of DigitalGlobe, Inc. If you are not the
> intended recipient, or an agent or employee responsible for delivering
> this communication to the intended recipient, or if you have received this
> communication in error, please do not print, copy, retransmit, disseminate
> or otherwise use the information. Please indicate to the sender that you
> have received this communication in error, and delete the copy you
> received. DigitalGlobe reserves the right to monitor any electronic
> communication sent or received by its employees, agents or
> representatives.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] SetSpatialFilter

2012-02-22 Thread Ethan Alpert 
Is it still true that the geometry used for SetSpatialFilter must have
the same CRS as the layer?


This electronic communication and any attachments may contain confidential and 
proprietary 
information of DigitalGlobe, Inc. If you are not the intended recipient, or an 
agent or employee 
responsible for delivering this communication to the intended recipient, or if 
you have received 
this communication in error, please do not print, copy, retransmit, disseminate 
or 
otherwise use the information. Please indicate to the sender that you have 
received this 
communication in error, and delete the copy you received. DigitalGlobe reserves 
the 
right to monitor any electronic communication sent or received by its 
employees, agents 
or representatives.

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

Re: [gdal-dev] gdaladdo, overviews and NODATA

2012-02-22 Thread Armin Burger 



On 21/02/2012 22:36, Frank Warmerdam wrote:

On Tue, Feb 21, 2012 at 1:17 PM, Armin Burger  wrote:

Then I tried to set the NODATA value to 0 using Gdal-Python, and afterwards
they had

Band 1 Block=3000x1 Type=Byte, ColorInterp=Red
  NoData Value=0
Band 2 Block=3000x1 Type=Byte, ColorInterp=Green
  NoData Value=0
Band 3 Block=3000x1 Type=Byte, ColorInterp=Blue
  NoData Value=0

But the result was the same, when using "-r average" a 1-2 pixel area of the
original NODATA values along the border to the DATA areas seem to have got
pixels with higher values than 0 (at least in Mapserver they cannot any more
be "hidden" with OFFSITE). Is there a simple way to write out the overviews
to separate Tiff files so that I can check them directly?


Armin,

You can use the gdal/apps/dumpoverviews app to write out overviews.  It may
not be built and installed by default.   If you confirm the overviews are built
wrong then please file a ticket, and provide with it a small sample file with
which you encounter the problem.

Best regards,


Frank

I checked the overviews after dumping them into Tiff files. I could not 
see anything strange with them along the border DATA-NODATA. The 
supposed NODATA pixels all had value 0 in all bands. So the problem 
seems a bit related how Mapserver handles the files. Strangely enough 
that the problem does not appear when the OV are created with nearest 
resampling. Being somehow more related to Mapserver I filed a ticket there


http://trac.osgeo.org/mapserver/ticket/4210

But the ticket owner are already you anyway ;-)

I could not upload a small test image due to file size restrictions (the 
zip has 3 MB). Should I send the file to you or someone else via mail?


I discovered an additional strange effect when using the layer 
processing parameter

  PROCESSING "RESAMPLE=BILINEAR"

which will create partially colored effects along the DATA-NODATA line. 
All of this happens just in the case that this line is not exactly 
horizontal or vertical but oblique due to image warping. I will create 
another ticket for this. So far it seems that I can use no "smoothing" 
via resampling, neither with overviews nor with the layer definition 
without having some "border effects".


Thanks

Armin

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

Re: [gdal-dev] compiling gdal on Ubuntu via Parallels

2012-02-22 Thread Stuart Edwards 
that seems to have taken care of the problem - thanks!

Stu

On Feb 22, 2012, at 11:41 AM, Kyle Shannon wrote:

> On newer Ubuntu releases /usr/local/lib is not in the LD_LIBRARY_PATH.  
> Either set it in your login script (export 
> LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH or add /usr/local/lib to 
> /etc/ld.so.conf 
> 
> If you do the latter method, run sudo ldconfig after you are done and it 
> should work.
> 
> -Original Message-
> From: gdal-dev-boun...@lists.osgeo.org 
> [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Stuart Edwards
> Sent: Wednesday, February 22, 2012 9:33 AM
> To: Even Rouault
> Cc: gdal-dev@lists.osgeo.org
> Subject: Re: [gdal-dev] compiling gdal on Ubuntu via Parallels
> 
> 
> On Feb 22, 2012, at 10:16 AM, Even Rouault wrote:
> 
>> Selon Stuart Edwards :
>> 
>>> Hi
>>> 
>>> This seems to be an old problem  (see
>>> http://www.osgeo.org/pipermail/gdal-dev/2009-October/022308.html) but 
>>> when I try to compile GDAL 1.9.0 from source using Ubuntu 10.04 
>>> through Parallels Desktop 6.0.12106 on OS X 10.6.8 (don't ask why 
>>> this convoluted approach - long ESRI related story)  I get the following 
>>> message during 'make':
>>> 
>>> ar:   /usr/local/gdal/frmts/o/aaigriddataset.o:   No such file or directory.
>>> 
>>> and indeed,
>>> 
>>> ls  /usr/local/gdal/frmts/o
>>> 
>>> produces a listing for aaigriddataset.lo , but unlike the other files 
>>> in the directory, no corresponding aaigriddataset.o
>> 
>> Perhaps try ./configure --without-libtool . But no promise this will 
>> help
> 
> seemed to compile without problem, but then gdalinfo gives ' gedalinfo: error 
> while loading shared libraries: libgdal.so: cannot open shared object file: 
> No such file or directory'
> 
> thx for the help
> 
> Stu
> 
> ___
> 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

RE: [gdal-dev] compiling gdal on Ubuntu via Parallels

2012-02-22 Thread Kyle Shannon 
On newer Ubuntu releases /usr/local/lib is not in the LD_LIBRARY_PATH.  Either 
set it in your login script (export 
LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH or add /usr/local/lib to 
/etc/ld.so.conf 

If you do the latter method, run sudo ldconfig after you are done and it should 
work.

-Original Message-
From: gdal-dev-boun...@lists.osgeo.org 
[mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Stuart Edwards
Sent: Wednesday, February 22, 2012 9:33 AM
To: Even Rouault
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] compiling gdal on Ubuntu via Parallels


On Feb 22, 2012, at 10:16 AM, Even Rouault wrote:

> Selon Stuart Edwards :
> 
>> Hi
>> 
>> This seems to be an old problem  (see
>> http://www.osgeo.org/pipermail/gdal-dev/2009-October/022308.html) but 
>> when I try to compile GDAL 1.9.0 from source using Ubuntu 10.04 
>> through Parallels Desktop 6.0.12106 on OS X 10.6.8 (don't ask why 
>> this convoluted approach - long ESRI related story)  I get the following 
>> message during 'make':
>> 
>> ar:   /usr/local/gdal/frmts/o/aaigriddataset.o:   No such file or directory.
>> 
>> and indeed,
>> 
>> ls  /usr/local/gdal/frmts/o
>> 
>> produces a listing for aaigriddataset.lo , but unlike the other files 
>> in the directory, no corresponding aaigriddataset.o
> 
> Perhaps try ./configure --without-libtool . But no promise this will 
> help

seemed to compile without problem, but then gdalinfo gives ' gedalinfo: error 
while loading shared libraries: libgdal.so: cannot open shared object file: No 
such file or directory'

thx for the help

Stu

___
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

Re: [gdal-dev] compiling gdal on Ubuntu via Parallels

2012-02-22 Thread Even Rouault 
Selon Stuart Edwards :

>
> On Feb 22, 2012, at 10:16 AM, Even Rouault wrote:
>
> > Selon Stuart Edwards :
> >
> >> Hi
> >>
> >> This seems to be an old problem  (see
> >> http://www.osgeo.org/pipermail/gdal-dev/2009-October/022308.html) but when
> I
> >> try to compile GDAL 1.9.0 from source using Ubuntu 10.04 through Parallels
> >> Desktop 6.0.12106 on OS X 10.6.8 (don't ask why this convoluted approach -
> >> long ESRI related story)  I get the following message during 'make':
> >>
> >> ar:   /usr/local/gdal/frmts/o/aaigriddataset.o:   No such file or
> directory.
> >>
> >> and indeed,
> >>
> >> ls  /usr/local/gdal/frmts/o
> >>
> >> produces a listing for aaigriddataset.lo , but unlike the other files in
> the
> >> directory, no corresponding aaigriddataset.o
> >
> > Perhaps try ./configure --without-libtool . But no promise this will help
>
> seemed to compile without problem, but then gdalinfo gives ' gedalinfo: error
> while loading shared libraries: libgdal.so: cannot open shared object file:
> No such file or directory'

You need to set the LD_LIBRARY_PATH to point to the directory where libgdal.so
is, or alternatively 'make install' (and make sure that the ${prefix_root}/lib
is in the searchable library path)

>
> thx for the help
>
> Stu
>
>


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

Re: [gdal-dev] compiling gdal on Ubuntu via Parallels

2012-02-22 Thread Stuart Edwards 

On Feb 22, 2012, at 10:16 AM, Even Rouault wrote:

> Selon Stuart Edwards :
> 
>> Hi
>> 
>> This seems to be an old problem  (see
>> http://www.osgeo.org/pipermail/gdal-dev/2009-October/022308.html) but when I
>> try to compile GDAL 1.9.0 from source using Ubuntu 10.04 through Parallels
>> Desktop 6.0.12106 on OS X 10.6.8 (don't ask why this convoluted approach -
>> long ESRI related story)  I get the following message during 'make':
>> 
>> ar:   /usr/local/gdal/frmts/o/aaigriddataset.o:   No such file or directory.
>> 
>> and indeed,
>> 
>> ls  /usr/local/gdal/frmts/o
>> 
>> produces a listing for aaigriddataset.lo , but unlike the other files in the
>> directory, no corresponding aaigriddataset.o
> 
> Perhaps try ./configure --without-libtool . But no promise this will help

seemed to compile without problem, but then gdalinfo gives ' gedalinfo: error 
while loading shared libraries: libgdal.so: cannot open shared object file: No 
such file or directory'

thx for the help

Stu

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

Re: [gdal-dev] gdalwarp extent issues

2012-02-22 Thread Joaquim Luis 

On 22-02-2012 00:54, Jay L. wrote:

List,

I am attempting to reproject 8 gtiffs, each in a local equirectangular 
projection, back to gcs for use in geoserver.  I immediately went to 
gdalwarp to perform this task and am having an issue.  The input files 
are stored in positive longitude, while the output SRS is in negative 
longitude.  The "shift" to negative longitude is a primary reason for 
wishing to perform the warp.


The input images which cover 0-90 north and 0-90 south are warping 
correctly.  The others are not.


The other warped output images have an extent of -180 180, when the 
should cover 90 degrees.  The images which remain in positive 
longitude are drawing correctly, but have the remained of the extent 
filled in black.  Meaning the image which spans 90-180n and 90-180s 
renders, but has an extent of -180 to 180.  The input image which are 
shifted to negative longitude have a global extent and 
are completely black.


Jay,

I crossed what seams to be the same problem a couple of days ago and 
opened this ticket

http://trac.osgeo.org/gdal/ticket/4523
With a bit more of experimenting after that report I found that the, at 
least with global grids, the problem is when they span [0 360]. If they 
are in [-180 180] gdalwarp works fine.
if you are interested, I have one Mirone solution to warp from [0 360] 
to [-180 180].


Joaquim



I have tried the following without success:

gdalwarp -t_srs moon2000.prf input output_warped.tif

gdalwarp -s_srs  -t_srs 
moon2000.prf input.tif output.tif


gdalwarp -t_srs moon2000.prf -te ymax> input.tif output.tif


Where moon2000.prf is:

GEOGCS["Moon 2000",
DATUM["D_Moon_2000",
SPHEROID["Moon_2000_IAU_IAG",1737400.0,0.0]],
PRIMEM["Greenwich",0],
UNIT["Decimal_Degree",0.0174532925199433]]

Any insight would be greatly appreciated.
Jay

Here is the projection info as output by gdalinfo:

Coordinate System is:
PROJCS["EQUIRECTANGULAR MOON",
GEOGCS["GCS_MOON",
DATUM["D_MOON",
SPHEROID["MOON_localRadius",1737400,0]],
PRIMEM["Reference_Meridian",0],
UNIT["degree",0.0174532925199433]],
PROJECTION["Equirectangular"],
PARAMETER["latitude_of_origin",0],
PARAMETER["central_meridian",0],
PARAMETER["standard_parallel_1",0],
PARAMETER["false_easting",0],
PARAMETER["false_northing",0],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]]]
Origin = (100.000,1819400.000)
Pixel Size = (100.000,-100.000)

The coordinate information:
Corner Coordinates:
Upper Left  ( 100.000, 1819400.000) (  0d 0'11.87"E, 59d59'59.88"N)
Lower Left  ( 100.000,-100.000) (  0d 0'11.87"E,  0d 0'11.87"S)
Upper Right ( 2729200.000, 1819400.000) ( 90d 0'11.69"E, 59d59'59.88"N)
Lower Right ( 2729200.000,-100.000) ( 90d 0'11.69"E,  0d 0'11.87"S)
Center  ( 1364650.000,  909650.000) ( 45d 0'11.78"E, 29d59'54.00"N)

Oddly the central meridian and standard_parallel_1 parameters do not 
change with each input file.  Since I know that gdal can see the s_srs 
from within the files I have tried using:





___
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

Re: [gdal-dev] compiling gdal on Obuntu via Parallels

2012-02-22 Thread Even Rouault 
Selon Stuart Edwards :

> Hi
>
> This seems to be an old problem  (see
> http://www.osgeo.org/pipermail/gdal-dev/2009-October/022308.html) but when I
> try to compile GDAL 1.9.0 from source using Obuntu 10.04 through Parallels
> Desktop 6.0.12106 on OS X 10.6.8 (don't ask why this convoluted approach -
> long ESRI related story)  I get the following message during 'make':
>
> ar:   /usr/local/gdal/frmts/o/aaigriddataset.o:   No such file or directory.
>
> and indeed,
>
> ls  /usr/local/gdal/frmts/o
>
> produces a listing for aaigriddataset.lo , but unlike the other files in the
> directory, no corresponding aaigriddataset.o

Perhaps try ./configure --without-libtool . But no promise this will help
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Using SWIG from a Driver

2012-02-22 Thread Even Rouault 
Selon Michael Speth :

> Greetings GDAL devs,
>I am interested in developing a GDAL driver that calls out to a Java
> library that accesses a database that we are developing using SWIG's
> Java Bindings.  Are there any examples of existing GDAL drivers using
> the SWIG bindings?

Not that I am aware of, and not in GDAL source tree for sure.

> If not, how might I use the SWIG library from a new
> GDAL driver?
>
> I've noticed there are 2 usages of Java from a GDAL driver.  Frank
> pointed out to me (ogr/ogrsf_frmts/ili) and mdb (ogr/ogrsf_frmts/mdb).
> Both of these driver's use JNI.  The reason I want to use SWIG is to
> avoid having to deal with the added configuration of JNI (since SWIG
> handles that already).

I'm not sure if you can call Java code with SWIG. Perhaps, but that's perhaps
more a question for a SWIG mailing list. I don't see how the code of the GDAL
SWIG bindings could help you since you will use a dedicated API for your Java
library.

>
> Thanks!
>
> --
> Michael Speth
> Research Systems Developer
> Landcare Research
>
> ___
> 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

Re: [gdal-dev] gdalwarp extent issues

2012-02-22 Thread Jay L. 
I can confirm that gdal_retile.py also exhibits this behavior.  I am
testing the shift to negative longitude now to see if that "fixes" the
issue.

Should I also post to the ticket concerning the persistance of this error
in gdal_retile?

Jay

On Wed, Feb 22, 2012 at 9:48 AM, J Luis  wrote:

>
>
> On Wed, Feb 22, 2012 at 12:54 AM, Jay L.  wrote:
>
>> List,
>>
>> I am attempting to reproject 8 gtiffs, each in a local equirectangular
>> projection, back to gcs for use in geoserver.  I immediately went to
>> gdalwarp to perform this task and am having an issue.  The input files are
>> stored in positive longitude, while the output SRS is in negative
>> longitude.  The "shift" to negative longitude is a primary reason for
>> wishing to perform the warp.
>>
>> The input images which cover 0-90 north and 0-90 south are warping
>> correctly.  The others are not.
>>
>> The other warped output images have an extent of -180 180, when the
>> should cover 90 degrees.  The images which remain in positive longitude are
>> drawing correctly, but have the remained of the extent filled in black.
>>  Meaning the image which spans 90-180n and 90-180s renders, but has an
>> extent of -180 to 180.  The input image which are shifted to negative
>> longitude have a global extent and are completely black.
>>
>
> Jay,
>
> I crossed what seams to be the same problem a couple of days ago and
> opened this ticket
> http://trac.osgeo.org/gdal/ticket/4523
> With a bit more of experimenting after that report I found that the, at
> least with global grids, the problem is when they span [0 360]. If they are
> in [-180 180] gdalwarp works fine.
> if you are interested, I have one Mirone solution to warp from [0 360] to
> [-180 180].
>
> Joaquim
>
>
>>
>> I have tried the following without success:
>>
>> gdalwarp -t_srs moon2000.prf input output_warped.tif
>>
>> gdalwarp -s_srs  -t_srs
>> moon2000.prf input.tif output.tif
>>
>> gdalwarp -t_srs moon2000.prf -te 
>> input.tif output.tif
>>
>> Where moon2000.prf is:
>>
>> GEOGCS["Moon 2000",
>> DATUM["D_Moon_2000",
>> SPHEROID["Moon_2000_IAU_IAG",1737400.0,0.0]],
>> PRIMEM["Greenwich",0],
>> UNIT["Decimal_Degree",0.0174532925199433]]
>>
>> Any insight would be greatly appreciated.
>> Jay
>>
>> Here is the projection info as output by gdalinfo:
>>
>> Coordinate System is:
>> PROJCS["EQUIRECTANGULAR MOON",
>> GEOGCS["GCS_MOON",
>> DATUM["D_MOON",
>> SPHEROID["MOON_localRadius",1737400,0]],
>> PRIMEM["Reference_Meridian",0],
>> UNIT["degree",0.0174532925199433]],
>> PROJECTION["Equirectangular"],
>> PARAMETER["latitude_of_origin",0],
>> PARAMETER["central_meridian",0],
>> PARAMETER["standard_parallel_1",0],
>> PARAMETER["false_easting",0],
>> PARAMETER["false_northing",0],
>> UNIT["metre",1,
>> AUTHORITY["EPSG","9001"]]]
>> Origin = (100.000,1819400.000)
>> Pixel Size = (100.000,-100.000)
>>
>> The coordinate information:
>> Corner Coordinates:
>> Upper Left  ( 100.000, 1819400.000) (  0d 0'11.87"E, 59d59'59.88"N)
>> Lower Left  ( 100.000,-100.000) (  0d 0'11.87"E,  0d 0'11.87"S)
>> Upper Right ( 2729200.000, 1819400.000) ( 90d 0'11.69"E, 59d59'59.88"N)
>> Lower Right ( 2729200.000,-100.000) ( 90d 0'11.69"E,  0d 0'11.87"S)
>> Center  ( 1364650.000,  909650.000) ( 45d 0'11.78"E, 29d59'54.00"N)
>>
>> Oddly the central meridian and standard_parallel_1 parameters do not
>> change with each input file.  Since I know that gdal can see the s_srs from
>> within the files I have tried using:
>>
>>
>>
>> ___
>> 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

Re: [gdal-dev] comparing two rasters

2012-02-22 Thread Chaitanya kumar CH 
Try this Derek,

for r in range(rows1):
data1 = ds1.GetRasterBand(1).ReadAsArray(0, r, cols1, 1)
print "data1: " + str(data1)
data2 = ds2.GetRasterBand(1).ReadAsArray(0, r, cols2, 1)
print "data2: " + str(data2)
result_bools = np.logical_and((data1 > 0), (data2 > 0))
result_ints = np.array(result_bools, dtype=int)
print "result_ints: " + str(result_ints)
dst_ds.GetRasterBand(1).WriteArray(result_ints, 0, r)
dst_ds = None

On Wed, Feb 22, 2012 at 5:26 PM, jdmorgan  wrote:

>  Hi Chaitanya,
> I am using data1[data1>0]=1 to convert any of the values in the row of
> data that is greater than 0 to a one.  I am doing this because the values
> are varied, but I am only interested in the fact that there is a value at
> all.  My end goal is to compare the two input rasters for places where they
> have any data (not zero).  But, as I mentioned I am certainly stuck
> somewhere getting results that I don't expect.
>
> Thanks,
> Derek
>
>
> On 2/21/2012 11:33 PM, Chaitanya kumar CH wrote:
>
> Derek,
>
> Can you explain the following lines towards the bottom of the script?
> data1[data1>0]=1
> ...
> data2[data2>0]=1
>
>
> On Wed, Feb 22, 2012 at 8:46 AM, jdmorgan  wrote:
>
>>  Hello GDAL guru’s,
>>
>> I am working on a python script where I read in two rasters of similar
>> extent and resolution.  Then I re-assign any values that are greater
>> that zero to a 1.  Next, I compare to the rasters and attempt to create
>> a third resulting raster which has 1’s everywhere that the two input
>> rasters match up.  However, my results are not exactly as expected.  The
>> third raster only has the values of the second raster. Any help would be
>> greatly appreciated.  Here is the script as it is now:
>>
>> #!/usr/bin/python
>>
>> from osgeo import gdal, osr, gdalconst
>>
>> import os, sys, time
>>
>> import struct
>>
>> import numpy as np
>>
>> np.set_printoptions(threshold='nan')
>>
>> gdal.AllRegister()
>>
>> print 'Raster Source 1--'
>>
>> ds1 = gdal.Open('C:\Data\TE300by300.img', gdal.GA_ReadOnly)
>>
>> cols1 = ds1.RasterXSize
>>
>> rows1 = ds1.RasterYSize
>>
>> bands1 = ds1.RasterCount
>>
>> print "Columns: " + str(cols1)
>>
>> print "Rows: " + str(rows1)
>>
>> print "Bands: " + str(bands1)
>>
>> gt1 = ds1.GetGeoTransform()
>>
>> width = ds1.RasterXSize
>>
>> height = ds1.RasterYSize
>>
>> minx = gt1[0]
>>
>> print "Left(minx): "+ str(minx)
>>
>> miny = gt1[3] + width*gt1[4] + height*gt1[5]
>>
>> print "Bottom(miny): "+ str(miny)
>>
>> maxx = gt1[0] + width*gt1[1] + height*gt1[2]
>>
>> print "Right(maxx): "+ str(maxx)
>>
>> maxy = gt1[3]
>>
>> print "Top(maxy): "+ str(maxy)
>>
>> pixWidth = gt1[1]
>>
>> print "Pixel Width " + str(pixWidth)
>>
>> pixHeight = gt1[5]
>>
>> print "Pixel Height " + str(pixHeight)
>>
>> xOrigin = gt1[0]
>>
>> yOrigin = gt1[3]
>>
>> print 'Raster Source 2--'
>>
>> ds2 = gdal.Open('C:\Data\LowElev300by300.img', gdal.GA_ReadOnly)
>>
>> cols2 = ds2.RasterXSize
>>
>> rows2 = ds2.RasterYSize
>>
>> bands2 = ds2.RasterCount
>>
>> print "Columns: " + str(cols2)
>>
>> print "Rows: " + str(rows2)
>>
>> print "Bands: " + str(bands2)
>>
>> gt2 = ds2.GetGeoTransform()
>>
>> width = ds2.RasterXSize
>>
>> height = ds2.RasterYSize
>>
>> minx = gt2[0]
>>
>> print "Left(minx): "+ str(minx)
>>
>> miny = gt2[3] + width*gt2[4] + height*gt2[5]
>>
>> print "Bottom(miny): "+ str(miny)
>>
>> maxx = gt2[0] + width*gt2[1] + height*gt2[2]
>>
>> print "Right(maxx): "+ str(maxx)
>>
>> maxy = gt2[3]
>>
>> print "Top(maxy): "+ str(maxy)
>>
>> pixWidth = gt2[1]
>>
>> print "Pixel Width " + str(pixWidth)
>>
>> pixHeight = gt2[5]
>>
>> print "Pixel Height " + str(pixHeight)
>>
>> xOrigin = gt2[0]
>>
>> yOrigin = gt2[3]
>>
>>
>>
>>
>>
>> format = "HFA"
>>
>> dst_file = "out.img"
>>
>> dst_driver = gdal.GetDriverByName(format)
>>
>> dst_ds = dst_driver.Create(dst_file, width, height, 1, gdal.GDT_Byte )
>> #driver.Create( outfile, outwidth, outheight, numbands, gdaldatatype)
>>
>> empty = np.empty([height, width], np.uint8 )
>>
>> srs = osr.SpatialReference()
>>
>> dst_ds.SetProjection(ds2.GetProjection())
>>
>> dst_ds.SetGeoTransform(ds2.GetGeoTransform())
>>
>> dst_ds.GetRasterBand(1).WriteArray(empty)
>>
>>
>>
>>
>>
>> #This is a way to go through a given raster band
>>
>> #one-by-one as an array by row, getting all of the columns for
>>
>> for r in range(rows1):
>>
>> data1 = ds1.GetRasterBand(1).ReadAsArray(0, r, cols1, 1)
>>
>> data1[data1>0]=1
>>
>> print "data1: " + str(data1)
>>
>> data2 = ds2.GetRasterBand(1).ReadAsArray(0, r, cols2, 1)
>>
>> data2[data2>0]=1
>>
>> print "data2: " + str(data2)
>>
>> result_bools = np.logical_and(np.logical_and(data1 != 0, data2 !=
>> 0), data1 == data2)
>>
>> result_ints = np.array(result_bools, dtype=int)
>>
>> print "result_ints: " + str(result_ints)
>>
>> dst_ds.GetRasterBand(1).WriteArray(result_ints, 0, r)
>>
>> dst_ds = None
>>
>>
>>
>> Cheers,
>>
>> Derek
>>
>> _

Re: [gdal-dev] Re: Hillshade + Topographic Map??

2012-02-22 Thread Norman Vine 

On Feb 22, 2012, at 8:42 AM, tim martin wrote:

> Hi Donovan and board
> 
> Yes that Tim Sutton tutorial is very good.
> 
> I also found this one
> 
> http://dirkraffel.com/2011/07/05/best-way-to-merge-color-relief-with-shaded-relief-map/
>  
> 
> 
> I ended up following this procedure and it has worked v well. I just setup a 
> loop to use ImageMagik and combine the two images. And then reapplied the 
> georeferencing using gdal_translate + world file. 
> 
> Thanks to all helped, it has made me aware of lots of other options that I 
> may use in the future
> 
> thanks again
> 
> Tim

another option is ossim see

http://trac.osgeo.org/ossim/wiki/ossim-dem

Norman

> 
> On 21 February 2012 19:52, Donovan Cameron  wrote:
> Have you reviewed the article from Tim Sutton: "A workflow for creating 
> beautiful relief shaded dems using GDAL"[1]?
> 
> It has some valuable pointers.
> 
> [1]  
> http://linfiniti.com/2010/12/a-workflow-for-creating-beautiful-relief-shaded-dems-using-gdal/
>  
> 
> 
> 
> 
> Donovan
> 
> On Tue, Feb 21, 2012 at 12:29 PM, Joaquim Luis  wrote:
> 
> 
> 5) Looked at GMT and I cannot find the options to load two rasters on top of 
> each other.
> 
> Tim,
> 
> You don't load the two grids on top of one-another. Illumination is NOT like 
> transparency. It uses the gradients of the grid, projects it into the 
> direction of light and than change the color in the HSV space (the 
> S(aturation) component) and converts back to RGB
> 
> 
> The links that I sent you have the scripts used to produce the figures. You 
> can also look at this one for a very simple illumination in bw, but the 
> procedure for color illumination is exactly the same.
> 
> http://gmt.soest.hawaii.edu/gmt/html/GMT_Docs.html#x1-137.5
> 
> 
> 6) MIRONE - again cannot see how to do this from within the application.
> 
> Well, I can give you a 'click-recipe' if you want, but Mirone won't be able 
> to deal with the such big grids as yours.
> Anyway, here is a step-by-step example
> https://sites.google.com/site/mironehowtos/basic/shade-illuminations
> 
> 
> ___
> 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 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] Error when importing/exporting to FileGDB

2012-02-22 Thread tim martin 
Hi gdalers

I have installed OSGeo4W and have checked the ogr formats and see that
FileGDB is there.

So I then tested a simple ESRI shapefile using the following command

ogr2ogr -f "FileGDB" region.gdb region.shp

this worked and I can see the data in ArcMap.

I then tried a folder of shapefiles using

FOR %%A in (C:\data\*.shp) do (ogr2ogr -f FileGDB data.gdb %%A)

All worked well.

Now when I try to export from PostGIS or try to load data in using python I
get the following error

ERROR 1: Error: Failed at creating table for \Text (General Function
failure)

I then get errors for the other tables etc

I have done a search and found something about using -nlt POINT on gis
stack exchange, however that did not help.

There is also a post about stating the EPSG code, which I tried using
-a_srs EPSG:27700

Neither have helped and now a bit stuck,

Anyone else seen this error or know what is causing it

thanks

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

Re: [gdal-dev] Re: Hillshade + Topographic Map??

2012-02-22 Thread tim martin 
Hi Donovan and board

Yes that Tim Sutton tutorial is very good.

I also found this one

http://dirkraffel.com/2011/07/05/best-way-to-merge-color-relief-with-shaded-relief-map/



I ended up following this procedure and it has worked v well. I just setup
a loop to use ImageMagik and combine the two images. And then reapplied the
georeferencing using gdal_translate + world file.

Thanks to all helped, it has made me aware of lots of other options that I
may use in the future

thanks again

Tim

On 21 February 2012 19:52, Donovan Cameron  wrote:

> Have you reviewed the article from Tim Sutton: "A workflow for creating
> beautiful relief shaded dems using GDAL"[1]?
>
> It has some valuable pointers.
>
> [1]
> http://linfiniti.com/2010/12/a-workflow-for-creating-beautiful-relief-shaded-dems-using-gdal/
>
>
>
>
>
> Donovan
>
> On Tue, Feb 21, 2012 at 12:29 PM, Joaquim Luis  wrote:
>
>>
>>
>>  5) Looked at GMT and I cannot find the options to load two rasters on
>>> top of each other.
>>>
>>
>> Tim,
>>
>> You don't load the two grids on top of one-another. Illumination is NOT
>> like transparency. It uses the gradients of the grid, projects it into the
>> direction of light and than change the color in the HSV space (the
>> S(aturation) component) and converts back to RGB
>>
>>
>> The links that I sent you have the scripts used to produce the figures.
>> You can also look at this one for a very simple illumination in bw, but the
>> procedure for color illumination is exactly the same.
>>
>> http://gmt.soest.hawaii.edu/**gmt/html/GMT_Docs.html#x1-**137.5
>>
>>
>>  6) MIRONE - again cannot see how to do this from within the application.
>>>
>>
>> Well, I can give you a 'click-recipe' if you want, but Mirone won't be
>> able to deal with the such big grids as yours.
>> Anyway, here is a step-by-step example
>> https://sites.google.com/site/**mironehowtos/basic/shade-**illuminations
>>
>>
>> __**_
>> 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 mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Multi image segments in NITF file

2012-02-22 Thread Even Rouault 
Selon Livneh Yehiyam :

>
> Hi
> Another NITF question.
> I want to create an NITF file with more than one image segment. I used the
> INUM create option to specify the number of image segments.
> Gdalinfo reports the correct number of sub datasets.
> I've noticed that all of the sub-datasets are created in the same size and
> pixel format as the main dataset, while the NITF specification permits
> different size and pixel format.
> Is there a way to specify these parameters for sub-datasets (image segments),
> either when creating the file, or afterwards?

No, there's no convenient interface in GDAL for doing that, so this is indeed a
limitation of the driver. Should probably be doable with a specific syntax of a
new creation option though.

>
> Another question is how do I write data to these sub-datasets? Just use
> Gdal.Open with the sub-dataset name and rasterIO as usual?

Yes, that should work.

>
> Thanks
> Yehiyam Livneh
>
>
**
> This message (including any attachments) issued by RAFAEL- ADVANCED DEFENSE
> SYSTEMS LTD.
> (hereinafter "RAFAEL") contains confidential information intended for a
> specific individual and purpose, may
> constitute information that is privileged or confidential or otherwise
> protected from disclosure. If you are not
> the intended recipient, you should contact us immediately and thereafter
> delete this message from your
> system. You are hereby notified that any disclosure, copying, dissemination,
> distribution or forwarding of this
> message, or the taking of any action based on it, is strictly prohibited. If
> you have received this e-mail in error,
> please notify us immediately by e-mail mailto:law...@rafael.co.il and
> completely delete or destroy any and all
> electronic or other copies of the original message and any attachments
> thereof.
>
**




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

Re: [gdal-dev] comparing two rasters

2012-02-22 Thread jdmorgan 

Hi Chaitanya,
I am using data1[data1>0]=1 to convert any of the values in the row of 
data that is greater than 0 to a one.  I am doing this because the 
values are varied, but I am only interested in the fact that there is a 
value at all.  My end goal is to compare the two input rasters for 
places where they have any data (not zero).  But, as I mentioned I am 
certainly stuck somewhere getting results that I don't expect.


Thanks,
Derek

On 2/21/2012 11:33 PM, Chaitanya kumar CH wrote:

Derek,

Can you explain the following lines towards the bottom of the script?
data1[data1>0]=1
...
data2[data2>0]=1


On Wed, Feb 22, 2012 at 8:46 AM, jdmorgan > wrote:


Hello GDAL guru’s,

I am working on a python script where I read in two rasters of
similar extent and resolution.Then I re-assign any values that are
greater that zero to a 1.Next, I compare to the rasters and
attempt to create a third resulting raster which has 1’s
everywhere that the two input rasters match up.However, my results
are not exactly as expected.  The third raster only has the values
of the second raster. Any help would be greatly appreciated.Here
is the script as it is now:

#!/usr/bin/python

from osgeo import gdal, osr, gdalconst

import os, sys, time

import struct

import numpy as np

np.set_printoptions(threshold='nan')

gdal.AllRegister()

print 'Raster Source 1--'

ds1 = gdal.Open('C:\Data\TE300by300.img', gdal.GA_ReadOnly)

cols1 = ds1.RasterXSize

rows1 = ds1.RasterYSize

bands1 = ds1.RasterCount

print "Columns: " + str(cols1)

print "Rows: " + str(rows1)

print "Bands: " + str(bands1)

gt1 = ds1.GetGeoTransform()

width = ds1.RasterXSize

height = ds1.RasterYSize

minx = gt1[0]

print "Left(minx): "+ str(minx)

miny = gt1[3] + width*gt1[4] + height*gt1[5]

print "Bottom(miny): "+ str(miny)

maxx = gt1[0] + width*gt1[1] + height*gt1[2]

print "Right(maxx): "+ str(maxx)

maxy = gt1[3]

print "Top(maxy): "+ str(maxy)

pixWidth = gt1[1]

print "Pixel Width " + str(pixWidth)

pixHeight = gt1[5]

print "Pixel Height " + str(pixHeight)

xOrigin = gt1[0]

yOrigin = gt1[3]

print 'Raster Source 2--'

ds2 = gdal.Open('C:\Data\LowElev300by300.img', gdal.GA_ReadOnly)

cols2 = ds2.RasterXSize

rows2 = ds2.RasterYSize

bands2 = ds2.RasterCount

print "Columns: " + str(cols2)

print "Rows: " + str(rows2)

print "Bands: " + str(bands2)

gt2 = ds2.GetGeoTransform()

width = ds2.RasterXSize

height = ds2.RasterYSize

minx = gt2[0]

print "Left(minx): "+ str(minx)

miny = gt2[3] + width*gt2[4] + height*gt2[5]

print "Bottom(miny): "+ str(miny)

maxx = gt2[0] + width*gt2[1] + height*gt2[2]

print "Right(maxx): "+ str(maxx)

maxy = gt2[3]

print "Top(maxy): "+ str(maxy)

pixWidth = gt2[1]

print "Pixel Width " + str(pixWidth)

pixHeight = gt2[5]

print "Pixel Height " + str(pixHeight)

xOrigin = gt2[0]

yOrigin = gt2[3]

format = "HFA"

dst_file = "out.img"

dst_driver = gdal.GetDriverByName(format)

dst_ds = dst_driver.Create(dst_file, width, height, 1,
gdal.GDT_Byte ) #driver.Create( outfile, outwidth, outheight,
numbands, gdaldatatype)

empty = np.empty([height, width], np.uint8 )

srs = osr.SpatialReference()

dst_ds.SetProjection(ds2.GetProjection())

dst_ds.SetGeoTransform(ds2.GetGeoTransform())

dst_ds.GetRasterBand(1).WriteArray(empty)

#This is a way to go through a given raster band

#one-by-one as an array by row, getting all of the columns for

for r in range(rows1):

data1 = ds1.GetRasterBand(1).ReadAsArray(0, r, cols1, 1)

data1[data1>0]=1

print "data1: " + str(data1)

data2 = ds2.GetRasterBand(1).ReadAsArray(0, r, cols2, 1)

data2[data2>0]=1

print "data2: " + str(data2)

result_bools = np.logical_and(np.logical_and(data1 != 0, data2 !=
0), data1 == data2)

result_ints = np.array(result_bools, dtype=int)

print "result_ints: " + str(result_ints)

dst_ds.GetRasterBand(1).WriteArray(result_ints, 0, r)

dst_ds = None

Cheers,

Derek


___
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



--
Derek @ NEMAC

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

Re: [gdal-dev] Postgis Raster driver improvements.

2012-02-22 Thread Jorge Arévalo 
Hello,

I confirm the driver is called "PostGIS Raster" instead of "WKT
Raster". The old name just remains in testing scripts. The rest is ok.
And I'm in contact with David for everything related with the driver.

Best regards,
Jorge

On Tue, Feb 21, 2012 at 10:48 PM, David Zwarg  wrote:
> Hi Frank,
>
> Yes, I am modernizing some of the testing scripts for PostGISRaster, and
> adding write support in the near future.  I've been in touch with and am
> coordinating with Jorge.
>
> I think it was just the test script that used the old name, btw. The driver
> is truly called "PostGISRaster", just the test script wasn't up-to-date.
>
> Thanks,
> Zwarg
>
>
> On Tue, Feb 21, 2012 at 2:19 PM, Frank Warmerdam 
> wrote:
>>
>> On Tue, Feb 21, 2012 at 10:38 AM, David Zwarg 
>> wrote:
>> > Hello,
>> >
>> > I would like to help add write support and more to the Postgis Raster
>> > driver.  Currently, there is a loader script in the autotest/data
>> > directory
>> > for the driver -- when write support is complete, will that script no
>> > longer
>> > be necessary? I don't see any corresponding test loading scripts for any
>> > of
>> > the other types of drivers.
>> >
>> > Also, in many places the driver is "WKTRaster" -- would it be possible
>> > to
>> > update the name of the driver to PostgisRaster, or pgRaster, or
>> > something
>> > similar? WKTRaster was the name of the spike branch, but raster support
>> > was
>> > renamed from WKTRaster when it was brought into Postgis trunk.
>>
>> David,
>>
>> Renaming the driver at this point should be ok.  The
>> driver name is mainly used for creation operations so
>> if we don't yet support creation it isn't going to break
>> existing scripts when it changes.
>>
>> If it would break a lot of stuff, I'd have suggested registering
>> it twice - once under each name.
>>
>> I'm looking forward to improvements.  I presume you are
>> in communication with Jorge who has done most of the
>> previous work, right?  I think he mentioned the two of you
>> are collaborating.
>>
>> 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



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

[gdal-dev] Multi image segments in NITF file

2012-02-22 Thread Livneh Yehiyam 

Hi
Another NITF question.
I want to create an NITF file with more than one image segment. I used the INUM 
create option to specify the number of image segments.
Gdalinfo reports the correct number of sub datasets.
I've noticed that all of the sub-datasets are created in the same size and 
pixel format as the main dataset, while the NITF specification permits 
different size and pixel format.
Is there a way to specify these parameters for sub-datasets (image segments), 
either when creating the file, or afterwards?

Another question is how do I write data to these sub-datasets? Just use 
Gdal.Open with the sub-dataset name and rasterIO as usual?

Thanks
Yehiyam Livneh

**
This message (including any attachments) issued by RAFAEL- ADVANCED DEFENSE 
SYSTEMS LTD. 
(hereinafter "RAFAEL") contains confidential information intended for a 
specific individual and purpose, may 
constitute information that is privileged or confidential or otherwise 
protected from disclosure. If you are not 
the intended recipient, you should contact us immediately and thereafter delete 
this message from your 
system. You are hereby notified that any disclosure, copying, dissemination, 
distribution or forwarding of this 
message, or the taking of any action based on it, is strictly prohibited. If 
you have received this e-mail in error, 
please notify us immediately by e-mail mailto:law...@rafael.co.il and 
completely delete or destroy any and all 
electronic or other copies of the original message and any attachments thereof.
**___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] gdaladdo, overviews and NODATA

2012-02-22 Thread Ralf Suhr 
Hi Armin,

you can work around with removing the nodata value first, build the overviews 
and setting the nodata value again with gdal_edit.py. The script can be found 
in source directory gdal/swig/python/samples.


Gr
Ralf

On Dienstag 21 Februar 2012 21:36:19 Armin Burger wrote:
> Hi all
> 
> I have a question regarding the gdaladdo tool and NODATA pixels:
> 
> When using resampling like "average" it seems that along the border of
> DATA and NODATA pixels there happens an averaging also of some of the
> original NODATA pixels (looks like 1-2 pixel width). This way in the
> overviews they get values higher than 0 (0 is defined as NODATA). Using
> this type of data in mapserver leads to small black borders when the
> overviews are taken since the tag
>OFFSITE 0 0 0
> does not work anymore for the small border of now only "nearly-black"
> pixels.
> 
> I tried to set the metadata NODATA of the images to 0 for each band but
> it had no effect. Only when I use resampling "nearest" then every NODATA
> pixel of the overviews retains the full black 0 0 0.
> 
> Is there a way to force to exclude NODATA pixels during the "average"
> resampling so that they retain their NODATA values?
> 
> Thanks
> Armin
> 
> ___
> 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