Re: [gdal-dev] gdal_calc.py: produce median raster

2014-11-25 Thread Chris Yesson
Dear Simen,

You can refer to each band explicitly using the --A_band option.
Try something like this

gdal_calc.py -A infile --A_band 1 -B infile --B_band 2 -C infile --C_band 3
 --outfile outfile --calc median(A,B,C)

- Chris

*Dr Chris Yesson*
*Institute of Zoology, Zoological Society of London*
*Tel: 020 7449 6267*

*email: chris.yes...@ioz.ac.uk chris.yes...@ioz.ac.uk**web:
http://www.zsl.org/chrisyesson/
http://www.zsl.org/chrisyesson/*
*Note: I work Mon-Thurs and do not check email on Fri*

On 25 November 2014 at 07:44, Simen Langseth simlan...@gmail.com wrote:

 Dear Respected Authors:

 I would be grateful if you could share any hints on it.


 On Tue, Nov 25, 2014 at 4:33 PM, Simen Langseth simlan...@gmail.com
 wrote:

 Dear Marius Jigmond:

 Thanks for your attempt.

 Unfortunately, it is producing 3 band outfile, rather than 1 band median
 image.

 I could not figure out what this code computed, all the resulted 3 bands
 images are also different.

 I hope someone can help me.

 On Tue, Nov 25, 2014 at 12:09 PM, Marius Jigmond 
 mariusjigm...@hotmail.com wrote:

 Does the following work:

 gdal_calc.py -A infile --allBands=A --outfile=outfile --calc=median(A)


 --
 Date: Mon, 24 Nov 2014 19:14:06 +0900
 From: simlan...@gmail.com
 To: gdal-dev@lists.osgeo.org
 Subject: [gdal-dev] gdal_calc.py: produce median raster


 I have one GeoTiff file with 3 bands. I want to produce a raster file
 computing pixel wise median value for the three raster bands. How can I do
 that?

 I tried as follows:

 gdal_calc.py -A infile --allBands --outfile outfile --calc median(A)

 But could not get any out file.



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





 This message has been scanned for viruses by MailControl
 http://www.mailcontrol.com/, a service from BlackSpider Technologies
 http://www.blackspider.com/.

 Click here https://www.mailcontrol.com/sr/MZbqvYs5QwJvpeaetUwhCQ== to
 report this email as spam.


 The Zoological Society of London is incorporated by Royal Charter
 Principal Office England. Company Number RC000749
 Registered address:
 Regent's Park, London, England NW1 4RY
 Registered Charity in England and Wales no. 208728

 _
 This e-mail has been sent in confidence to the named addressee(s).
 If you are not the intended recipient, you must not disclose or distribute
 it in any form, and you are asked to contact the sender immediately.
 Views or opinions expressed in this communication may not be those
 of The Zoological Society of London and, therefore, The Zoological
 Society of London does not accept legal responsibility for the contents
 of this message. The recipient(s) must be aware that e-mail is not a
 secure communication medium and that the contents of this mail may
 have been altered by a third party in transit.
 If you have any issues regarding this mail please contact:
 administra...@zsl.org.
 ___

 This message has been scanned for viruses by MailControl
 http://www.mailcontrol.com/, a service from BlackSpider Technologies
 http://www.blackspider.com/.

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

Re: [gdal-dev] gdal_calc.py: produce median raster

2014-11-25 Thread Simen Langseth
Dear Dr Chris Yesson

Thanks for your quick response.

I got the following error:

ValueError: The truth value of an array with more than one element is
ambiguous.
Use a.any() or a.all()`

Perhaps the expression for calc seems to be revised...


On Tue, Nov 25, 2014 at 4:59 PM, Chris Yesson chris.yesson@gmail.com
wrote:

 Dear Simen,

 You can refer to each band explicitly using the --A_band option.
 Try something like this

 gdal_calc.py -A infile --A_band 1 -B infile --B_band 2 -C infile --C_band
 3  --outfile outfile --calc median(A,B,C)

 - Chris

 *Dr Chris Yesson*
 *Institute of Zoology, Zoological Society of London*
 *Tel: 020 7449 6267*

 *email: chris.yes...@ioz.ac.uk chris.yes...@ioz.ac.uk**web: 
 http://www.zsl.org/chrisyesson/
 http://www.zsl.org/chrisyesson/*
 *Note: I work Mon-Thurs and do not check email on Fri*

 On 25 November 2014 at 07:44, Simen Langseth simlan...@gmail.com wrote:

 Dear Respected Authors:

 I would be grateful if you could share any hints on it.


 On Tue, Nov 25, 2014 at 4:33 PM, Simen Langseth simlan...@gmail.com
 wrote:

 Dear Marius Jigmond:

 Thanks for your attempt.

 Unfortunately, it is producing 3 band outfile, rather than 1 band median
 image.

 I could not figure out what this code computed, all the resulted 3 bands
 images are also different.

 I hope someone can help me.

 On Tue, Nov 25, 2014 at 12:09 PM, Marius Jigmond 
 mariusjigm...@hotmail.com wrote:

 Does the following work:

 gdal_calc.py -A infile --allBands=A --outfile=outfile --calc=median(A)


 --
 Date: Mon, 24 Nov 2014 19:14:06 +0900
 From: simlan...@gmail.com
 To: gdal-dev@lists.osgeo.org
 Subject: [gdal-dev] gdal_calc.py: produce median raster


 I have one GeoTiff file with 3 bands. I want to produce a raster file
 computing pixel wise median value for the three raster bands. How can I do
 that?

 I tried as follows:

 gdal_calc.py -A infile --allBands --outfile outfile --calc median(A)

 But could not get any out file.



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





 This message has been scanned for viruses by MailControl
 http://www.mailcontrol.com/, a service from BlackSpider Technologies
 http://www.blackspider.com/.

 Click here https://www.mailcontrol.com/sr/MZbqvYs5QwJvpeaetUwhCQ== to
 report this email as spam.


 The Zoological Society of London is incorporated by Royal Charter
 Principal Office England. Company Number RC000749
 Registered address:
 Regent's Park, London, England NW1 4RY
 Registered Charity in England and Wales no. 208728

 _
 This e-mail has been sent in confidence to the named addressee(s).
 If you are not the intended recipient, you must not disclose or distribute
 it in any form, and you are asked to contact the sender immediately.
 Views or opinions expressed in this communication may not be those
 of The Zoological Society of London and, therefore, The Zoological
 Society of London does not accept legal responsibility for the contents
 of this message. The recipient(s) must be aware that e-mail is not a
 secure communication medium and that the contents of this mail may
 have been altered by a third party in transit.
 If you have any issues regarding this mail please contact:
 administra...@zsl.org.

 ___

 This message has been scanned for viruses by MailControl
 http://www.mailcontrol.com/, a service from BlackSpider Technologies
 http://www.blackspider.com/.



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

Re: [gdal-dev] Call for discussion on RFC 51: RasterIO() improvements : resampling and progress callback

2014-11-25 Thread Mike Toews
On 25 November 2014 at 05:34, Even Rouault even.roua...@spatialys.com wrote:
 Otherwise I have not much to say about this RFC. Blurring has two r's,

 Fixed

Gaussian blur also has another complexity, since it's output
dimensions depend on the fftconvolve mode (using scipy.signal docs
http://docs.scipy.org/doc/scipy-0.14.0/reference/generated/scipy.signal.fftconvolve.html).

For example, to blur a DTM and maintain the same output dimensions
and geotransform, the mode would need to use a 'valid' convolution
with a padded input array. This padded array would also have a mode
(similarly from numpy docs
http://docs.scipy.org/doc/numpy/reference/generated/numpy.pad.html),
such as 'symmetric'.
http://gis.stackexchange.com/a/10467/1872

Someone else may want to blur a DTM without using a padded array, and
just return a smaller array with modified geotransform.

And a different blur would expand the output dimension and modify
the geotransform using a 'full' fftconvolve mode, using a 'constant'=0
padded array. An example of this is to blur a polygon that barely
extends to the shape's extent, but maintain the blur beyond the
initial extent. The constant value would also need to be supplied, as
a value of 0 for numpy is default.
http://gis.stackexchange.com/a/104338/1872

So in summary, I'm not sure how GDAL could best cover all combinations
of padding and convolution modes, except to offer a few prepared
use-cases, or somehow provide extra parameters. Or just provide a
single use case, similar to Gaussian blur routines in various raster
editing software.

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


Re: [gdal-dev] GDAL Driver for MongoDB

2014-11-25 Thread Even Rouault
Shuai,

I may have the opportunity to integrate your driver in the future. I just 
wanted to make sure you had the right to contribute this work under the X/MIT 
license. From some headers like in https://github.com/mongogis/mongodb-gdal-
driver/blob/master/mongo/ogr_mongo.h, I see Nanjing University mentionned, 
and/but you above email is @illinois.edu. If this work was done for your 
studies, you'd likely check with your supervisor if it can be released under 
the X/MIT license. See the Legal section of 
https://trac.osgeo.org/gdal/wiki/rfc3_commiters

If you confirm that everything is OK, please answer back to the list stating 
so.

Thanks,

Even

 Hi there,
 
 I wrote a GDAL driver for mongodb, and uploaded it in the
 githubhttps://github.com/mongogis/mongodb-gdal-driver. Feel free to grab
 and use the driver.
 
 Just let me know if you have any questions or suggestions.
 Thanks,
 shuai

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev


Re: [gdal-dev] Call for discussion on RFC 51: RasterIO() improvements : resampling and progress callback

2014-11-25 Thread Even Rouault
Mike,

The gaussian resampling is the one already available for gdaladdo, that was 
added per
http://trac.osgeo.org/gdal/ticket/2137
and
http://trac.osgeo.org/gdal/changeset/15323

Basically :
- for a downscaling of factor between 1 and 2 (and for upscaling as well), it 
will use a 3x3 kernel
- for a downscaling of factor between 2 and 4, it will use a 5x5 kernel
- beyond it will use a 7x7 kernel.

I understand that gaussian blur can/could be parametrized in more complex 
ways. If there are improvements in that area, additional parameters could 
likely be passed through the GDALRasterIOExtraArg structure.

I've also wondered if the resampling algorithm couldn't be specified as a 
string instead of an enumerated value. In which case you could have had things 
like gauss_x_y with x and y as parameters. I don't have strong preference 
for one way or the other one. And both already exist in GDAL : the GDAL 
warping API uses an enumerated value, the GDAL overview API uses a string...

Even

 On 25 November 2014 at 05:34, Even Rouault even.roua...@spatialys.com 
wrote:
  Otherwise I have not much to say about this RFC. Blurring has two r's,
  
  Fixed
 
 Gaussian blur also has another complexity, since it's output
 dimensions depend on the fftconvolve mode (using scipy.signal docs
 http://docs.scipy.org/doc/scipy-0.14.0/reference/generated/scipy.signal.fft
 convolve.html).
 
 For example, to blur a DTM and maintain the same output dimensions
 and geotransform, the mode would need to use a 'valid' convolution
 with a padded input array. This padded array would also have a mode
 (similarly from numpy docs
 http://docs.scipy.org/doc/numpy/reference/generated/numpy.pad.html),
 such as 'symmetric'.
 http://gis.stackexchange.com/a/10467/1872
 
 Someone else may want to blur a DTM without using a padded array, and
 just return a smaller array with modified geotransform.
 
 And a different blur would expand the output dimension and modify
 the geotransform using a 'full' fftconvolve mode, using a 'constant'=0
 padded array. An example of this is to blur a polygon that barely
 extends to the shape's extent, but maintain the blur beyond the
 initial extent. The constant value would also need to be supplied, as
 a value of 0 for numpy is default.
 http://gis.stackexchange.com/a/104338/1872
 
 So in summary, I'm not sure how GDAL could best cover all combinations
 of padding and convolution modes, except to offer a few prepared
 use-cases, or somehow provide extra parameters. Or just provide a
 single use case, similar to Gaussian blur routines in various raster
 editing software.
 
 -Mike

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev


Re: [gdal-dev] gdal_calc.py: produce median raster

2014-11-25 Thread Marius Jigmond
That's because numpy.median expects one array and keyword arguments, not three 
arrays. It's unclear to me what gdal_calc.py does under the hood (I admit I did 
not read it) but the correct way to get the median of the three bands would be:
--calc median([A,B,C], 0)
The strange part is that--calc median([A,B,C])works as well and generates a 
different output. When axis is not specified median should return a single 
value. At this point I suggest you take three 2D arrays, calculate their median 
as a 2D array, convert the three arrays to rasters, run gdal_calc.py and 
compare results.
-marius

Date: Tue, 25 Nov 2014 17:56:46 +0900
From: simlan...@gmail.com
To: chris.yes...@ioz.ac.uk
CC: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] gdal_calc.py: produce median raster

Dear Dr Chris Yesson

Thanks for your quick response.

I got the following error:

ValueError: The truth value of an array with more than one element is 
ambiguous. 
Use a.any() or a.all()`

Perhaps the expression for calc seems to be revised...

On Tue, Nov 25, 2014 at 4:59 PM, Chris Yesson chris.yesson@gmail.com 
wrote:
Dear Simen,
You can refer to each band explicitly using the --A_band option.Try something 
like this
gdal_calc.py -A infile --A_band 1 -B infile --B_band 2 -C infile --C_band 3  
--outfile outfile --calc median(A,B,C)
- ChrisDr Chris Yesson
Institute of Zoology, Zoological Society of LondonTel: 020 7449 6267
email: chris.yes...@ioz.ac.uk
web: http://www.zsl.org/chrisyesson/

Note: I work Mon-Thurs and do not check email on Fri


On 25 November 2014 at 07:44, Simen Langseth simlan...@gmail.com wrote:
Dear Respected Authors:
I would be grateful if you could share any hints on it.

On Tue, Nov 25, 2014 at 4:33 PM, Simen Langseth simlan...@gmail.com wrote:
Dear Marius Jigmond:

Thanks for your attempt.

Unfortunately, it is producing 3 band outfile, rather than 1 band median image.

I could not figure out what this code computed, all the resulted 3 bands images 
are also different.

I hope someone can help me.

On Tue, Nov 25, 2014 at 12:09 PM, Marius Jigmond mariusjigm...@hotmail.com 
wrote:



Does the following work:
gdal_calc.py -A infile --allBands=A --outfile=outfile --calc=median(A)

Date: Mon, 24 Nov 2014 19:14:06 +0900
From: simlan...@gmail.com
To: gdal-dev@lists.osgeo.org
Subject: [gdal-dev] gdal_calc.py: produce median raster

I have one GeoTiff file with 3 bands. I want to produce a raster file computing 
pixel wise median value for the three raster bands. How can I do that?
I tried as follows:
gdal_calc.py -A infile --allBands --outfile outfile --calc median(A)
But could not get any out file.
 

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







This message has been scanned for viruses by MailControl, a service from 
BlackSpider Technologies.
Click here to report this email as spam.



The Zoological Society of London is incorporated by Royal Charter
Principal Office England. Company Number RC000749
Registered address: 
Regent's Park, London, England NW1 4RY
Registered Charity in England and Wales no. 208728 

_
This e-mail has been sent in confidence to the named addressee(s).
If you are not the intended recipient, you must not disclose or distribute
it in any form, and you are asked to contact the sender immediately.
Views or opinions expressed in this communication may not be those
of The Zoological Society of London and, therefore, The Zoological
Society of London does not accept legal responsibility for the contents
of this message. The recipient(s) must be aware that e-mail is not a
secure communication medium and that the contents of this mail may
have been altered by a third party in transit.
If you have any issues regarding this mail please contact:
administra...@zsl.org.
___


This message has been scanned for viruses by MailControl, a service from 
BlackSpider Technologies.





___
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