Hello,
Is there any rough estimate on when GDAL/OGR 1.9 will be released ?
Thanks,
Silas
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Hi,
This has started happening to me also. When i call any function from gdal
library i get this error:
Unhandled exception at 0x7264082a (msvcr90d.dll) in test.exe: 0xC005:
Access violation reading location 0x6973762f.
Error happens at iosfwd file at this function
static int
Joaquim,
nearneighbor is not really a good thing to use. Grid it with surface.
What do you mean by grid it with surface? In my GDAL (1.8.1), I only
have the following choices:
Available resampling methods:
near (default), bilinear, cubic, cubicspline, lanczos.
thanks for your
Hi,
Hróbjartur Þorsteinsson explained to me a near-hidden feature of GDAL,
namely to reproject one image onto the coverage of another.
Given two images:
imageA.tiff
imageB.tiff
Then an empty image can be created from image A with e.g.
$ gdal_translate -ot Float32 -scale 0 0 999 999 -a_nodata
On 15 December 2011 11:49, mrym meryem...@gmail.com wrote:
Hi,
This has started happening to me also. When i call any function from gdal
library i get this error:
Unhandled exception at 0x7264082a (msvcr90d.dll) in test.exe: 0xC005:
Access violation reading location 0x6973762f.
Error
Here is my command line:
/Od /I E:\BELGIS\gdal-1.7.2\libecwj2-3.3\Source\include /I
C:\mrym\warmerda\bld\include /D WIN32 /D _DEBUG /D _WINDOWS /D
_USRDLL /D BELGDAL_EXPORTS /D _WINDLL /D _UNICODE /D UNICODE /Gm
/EHsc /RTC1 /MDd /FoDebug\\ /FdDebug\vc90.pdb /W3 /nologo /c /ZI /Gd /TP
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 differences can be
substantial. The short and long of it is that local hydrologic slope is
closer to
On 15 December 2011 15:33, mrym meryem...@gmail.com wrote:
And i have changed flags and built it in this way
nmake -f makefile.vc clean
nmake -f makefile.vc MSVC_VER=1500 DEBUG=1
Edit nmake.opt
In debug version of OPTFLAGS flags, replace /MD with /MDd
Rebuild GDAL
Rebuild your library and
Hi all,
I am trying to use gdal_translate to convert a .grd file
(Northwood/VerticalMapper format) to TIFF. However, the colors in the
translated file don't seem to be interpolated correctly based on the
color scheme, for values near the end of the range.
Here is a link to the original
Hi,
I'm having problems with GDAL inserting leading spaces when writing from a
numpy array to ESRI ASCII Grid format.
The problem occurs whenever there are integers in the array (even though the
array itself is floating point).
E.g., if I try to write a 3x3 grid that ArcGIS can read, it needs
Andreas
I think thats referring to my suggestion of GMT to do part of the work
On Thu, 2011-12-15 at 14:00 +0100, Andreas H. wrote:
Joaquim,
nearneighbor is not really a good thing to use. Grid it with surface.
What do you mean by grid it with surface? In my GDAL (1.8.1), I only
Sorry for the noise that I introduced by mixing the GDAL and GMT's
lists. I already replied to Andreas only because I though my message
went only to him, but since it didn't here is a copy of it.
Joaquim
Andreas,
I'm very sorry but I sent that message to you by mistake as it was meant
as a
If you need complete control, and your data are not too massive in
number, I have had good results pushing pixel coordinates as points
into postgis and then using spatial queries to aggregate in various
ways (eg averages a hexagonal grid). It seems round-about, but it
works. I've actually done it
I already see a flaw-- the function should be more like:
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*
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 =
Stephen,
It'd be great to see local hydrologic slope in gdaldem.
I've seen a similar discrepancy between field slope and most
GIS-derived slopes. The local max hydrologic slope seems to correspond
much better to our perceived slope on the ground. The integrated slope
used in most GIS, however,
For what it's worth,
What do you consider large and what kind of method for downscaling you
wish to use?
I do this in GRASS using the r.neighbors command,
http://grass.fbk.eu/grass64/manuals/html64_user/r.neighbors.html. I've
done an averaging method to convert a 20 ft elevation grid (
Le jeudi 15 décembre 2011 18:21:11, bhmcrae a écrit :
Hi,
I'm having problems with GDAL inserting leading spaces when writing from a
numpy array to ESRI ASCII Grid format.
The problem occurs whenever there are integers in the array (even though
the array itself is floating point).
Brad,
E.g., if I try to write a 3x3 grid that ArcGIS can read, it needs to look
something like this:
ncols 3
nrows 3
xllcorner 100.
yllcorner 100.
cellsize 0.1000
1.0 1.4809201955795288 1.4809201955795288
Le jeudi 15 décembre 2011 18:08:26, mlade...@distributel.net a écrit :
Hi all,
I am trying to use gdal_translate to convert a .grd file
(Northwood/VerticalMapper format) to TIFF. However, the colors in the
translated file don't seem to be interpolated correctly based on the
color scheme,
Hi Even and Eli,
Thanks much for your responses. As soon as I sent that email I
realized I might eat my words on the inability to open the ASCII grids
in ArcMap. This problem did crop up when we released a version of our
code that used GDAL a few years back. A user reported intermittent
errors
I agree both have their place. Sometimes we get a more consistent or more
interesting answer from our analyses than from our field measurements.
As to the approach, I agree with your assessment, I was thinking
backwards-- one caveat-- how best to handle local minima? Insert a null?
I'm afraid I
Hi,
I'm using gdal_translate to chip out TIFFs from a NITF using the
command line:
gdal_translate -ot Int32 -of Gtiff -strict -outsize 3000 3000 -srcwin
0 0 3000 3000 c:\data\image.ntf c:\data\output_image.tiff
Tiffinfo (which throws an error) has a problem with the resolution
field-
Sometimes I think GRASS can do anything...
In my case I was using a 1km equal area grid over North and South America
and needed to implement an interpolation scheme not pre-packaged anywhere I
had looked, so I worked with large tables of points. Not highly recommended
unless you have other things
Mike,
Can you provide the output of tiffinfo, and tiffdump on the
file produced by gdal_translate? GDAL does have support
for setting the resolution fields if particular source metadata
is provided but normally that metadata is not available and
no resolution fields should be written at all.
Forwarding private response back to the group.
-- Forwarded message --
From: Frank Warmerdam warmer...@pobox.com
Date: Thu, Dec 15, 2011 at 1:56 PM
Subject: Re: [gdal-dev] gdal_translate and TIFF resolutions(?)
To: Mike O'Malley mike.omal...@nextcentury.com
On Thu, Dec 15, 2011
Wow, that was fast. Thanks!
I see that the fix is in 1.8.2... Do you know will this be a separate
release or will the fixes be merged into 1.9.0? I ask because I see
some recent discussions suggesting that 1.9.0 may be released by the
end of the year.
Thanks again for the quick
Le jeudi 15 décembre 2011 23:32:14, mlade...@distributel.net a écrit :
Wow, that was fast. Thanks!
I see that the fix is in 1.8.2... Do you know will this be a separate
release or will the fixes be merged into 1.9.0? I ask because I see
some recent discussions suggesting that 1.9.0 may be
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
float pafLocalMin = afWin[0];
float pafLocalMax = afWin[0];
for ( int k = 1; k 9; k++)
{
if (afWin[k] pafLocalMin)
{
pafLocalMin=afWin[k];
}
if (afWin[k] pafLocalMax)
{
pafLocalMax=afWin[k];
}
}
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*
On 16-12-2011 03:31, Stephen Mather wrote:
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
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
Thanks. I've done things you have written, but it's still same.
--
View this message in context:
http://osgeo-org.1803224.n2.nabble.com/Runtime-error-on-executing-OGRRegisterAll-function-tp4453903p7099963.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
34 matches
Mail list logo
