Re: [gdal-dev] How to-- gdal_calc.py

2011-12-20 Thread Stephen Mather
the val_repl.py sample to convert a image to a numpy array(s) > http://svn.osgeo.org/gdal/trunk/gdal/swig/python/samples/val_repl.py > > Numpy Stuff: > > http://www.scipy.org/Numpy_Example_List#head-7eb5ca476fca411db1db64bc024b7c0c94e42143 > > Regards > > > On 20

[gdal-dev] How to-- gdal_calc.py

2011-12-20 Thread Stephen Mather
Hi All, Is there any casting (for lack of a better word) needed when using gdal_calc to take, e.g. a series of 16-bit images and perform float functions against them? Best, Steve ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo

Re: [gdal-dev] Re: Slope in gdaldem

2011-12-15 Thread Stephen Mather
> > Steve, there are more things I do not understand either. What is > 'psData->scale'? Is it the grid cell size? > So, if 'pafLocalMin' is on one of the 4 corners the distance is not cell > size (let's call it DX) but instead sqrt(DX*DX + DX*DX). > And what if data is in geogs? Than DX is clearly

Re: [gdal-dev] Re: Slope in gdaldem

2011-12-15 Thread Stephen Mather
Hmm. I don't follow? The revision would be this: float GDALSlopeHydroAlg (float* afWin, float fDstNoDataValue, void* pData) { // Hydrologic Slope is the max // local slope btw center cell and adjacent cells const double radiansToDegrees = 180.0 / M_PI; GDALSlopeAlgData* psData

Re: [gdal-dev] Re: Slope in gdaldem

2011-12-15 Thread Stephen Mather
Here's what I've settled on. Let me know your thoughts. The algorithm now correctly calculates angle to lowest nearby point. If it's a local minima, it instead calculates angle to the nearest high point, which will be a negative number, so if the user wants to nullify these or use them in additi

Re: [gdal-dev] Re: Slope in gdaldem

2011-12-15 Thread Stephen Mather
hould calculate the > slope in the direction of hydrologic flow; i.e. the slope from the > center cell to surrounding cell with the *minimum* elevation. > > > - matt > > On Thu, Dec 15, 2011 at 10:29 AM, Stephen Mather > wrote: > > I already see a flaw-- the

[gdal-dev] Re: Slope in gdaldem

2011-12-15 Thread Stephen Mather
Apologies for the flurry, one more change: float GDALSlopeHydroAlg (float* afWin, float fDstNoDataValue, void* pData) { // Hydrologic Slope is the max // local slope btw center cell and adjacent cells const double radiansToDegrees = 180.0 / M_PI; GDALSlopeAlgData* psData = (GDALS

[gdal-dev] Re: Slope in gdaldem

2011-12-15 Thread Stephen Mather
; } On Thu, Dec 15, 2011 at 11:49 AM, Stephen Mather wrote: > Hi All, > A colleague tipped me off to an article in Forestry Source entitled > "When GIS Slope Isn't What You Think" showing differences between field > measured slope values and GIS results. The di

[gdal-dev] Slope in gdaldem

2011-12-15 Thread Stephen Mather
9; k++) { if (afWin[k] > pafLocalMax) { pafLocalMax=afWin[k]; } } return pafLocalMax - afWin[4]; } Any critques? Reasons to not add? Best, Steve Stephen Mather GIS Manager Cleveland Metroparks 4101 Fulton Pkwy Cleveland, OH 44144 ___

Re: [gdal-dev] gdal_translate -scale with PNG

2011-07-28 Thread Stephen Mather
I thought I'd tried that and it failed, but it looks to be just a problem of stale statistics. Thanks Marius. Steve On Wed, Jul 27, 2011 at 10:16 PM, Marius Jigmond wrote: > On 07/27/2011 04:16 PM, Stephen Mather wrote: > > Hi All, > I'm using gdal_translate (v

[gdal-dev] gdal_translate -scale with PNG

2011-07-27 Thread Stephen Mather
Hi All, I'm using gdal_translate (version 1.6.3 on Ubuntu) with a scale factor to stretch float values to 16-bit integer values. It works fine with tif output, but with PNG it stretches the values to 8-bit: gdal_translate -of PNG -scale 0 1550 0 65535 N2140615.txt N2140615.png Is this a kno

[gdal-dev] RE: Mosaic the output of gdal2tiles (iomeneandrei)

2011-01-03 Thread Stephen Mather
> > Hi all, > I have a folder with a gdal2tiles output: 6 levels of zoom (and folders), > with subfolders and the .png tiles. > > Is there a gdal tool to merge in a single geotiff file these .png tiles? > > Hi Andrea, Probably the simplest way to handle this is with a virtual dataset. Rather

Re: [gdal-dev] Problem with gdal 1.8 -- segmentation fault on large image with gdaladdo

2011-01-01 Thread Stephen Mather
Seems large enough for me. Stephen Mather On Jan 1, 2011, at 5:47 AM, Even Rouault wrote: >> >> What's the new ceiling on image size for overview calculation? > > The same as before hopefully. I'm not sure what the limit is. From a quick > look > a

Re: [gdal-dev] Problem with gdal 1.8 -- segmentation fault on large image with gdaladdo

2010-12-31 Thread Stephen Mather
Seems to have done the trick, thanks Even. What's the new ceiling on image size for overview calculation? Steve On Fri, Dec 31, 2010 at 11:38 AM, Even Rouault wrote: > Stephen, > > this should be fixed now in SVN. > > This was indeed something wrong in a recent optimization in overview > com

[gdal-dev] Problem with gdal 1.8 -- segmentation fault on large image with gdaladdo

2010-12-31 Thread Stephen Mather
Hi All, Testing out gdal 1.8; really excited by http://www.gdal.org/gdallocationinfo.html. Below is a comparison of doing the same process in 1.7.3 and then 1.8dev, released 2010/01/19 $ gdaladdo --version GDAL 1.7.3, released 2010/11/10 $ gdalbuildvrt LEAP_Tree_Height_low_res_test.vrt *.png