Hi Even,
I have 4gb of ram on this machine and task manager reported max usage
was around 2gb. I wasn't using gdal_merge because in the past that
hasn't produced a seamless mosaic. That was some years ago though so I
should probably try again.
I tried again specifying 300 instead of 500 for memo
Bruce,
> I don't know how ESRI gets GDAL.dll to run on all systems unless they
> include files from the c++ redistribution patch in their installation
> because in addition to the above headaches I also have to apply a
> Microsoft patch to the computers to get even the most basic GDAL program
Steve:
One word of caution is to make sure you build all of the supporting
modules (expat, xerces, geos etc) in the same mode. I spent
considerable time over that past week chasing bizarre crashes that gave
heap errors and other crashes down in Microsoft space only to find that
one of the lower
The only idea I have is pretty obvious and I guess you'd already have it, you
probably require more memory than available. The --config GDAL_CACHEMAX
500 -wm 500 options require at least 1 GB. Otherwise it's a more subtle bug.
Unfortunately it's not very practical to try to reproduce it as your
It looks like a good plan, I hope I can attend.
Currently I don't have any pending additions which would block the
release process, however I volunteer to extend the windows slaves of
the buildbot configuration by adding further drivers to be compiled
in, and alter the autotest to use SWIG python w
Dear gdal-dev,
I'm mosaicking a series of DEMs with gdalwarp and getting a series of
errors in the form:
ERROR 2: Out of memory allocatint 428788524 byte destination buffer.
My command is (wrapped for legibility):
gdalwarp -r bilinear -multi --config GDAL_CACHEMAX 500 -wm 500
-ot uin
Hi,
I am trying to use the GDALDataset::RasterIO method to read all the
bands into a chunk of memory, and be able to access a pixel's values in
all bands by using a [] operator on the memory.
I got the sizes of the data types in all the bands, sum up to get the
total data type size, then
I won't be able to attend. FYI, I don't plan personally any new features that
would delay the release process.
Recently I think I hit #2621 while using gdal in an app. As I was writing my
code against trunk, I've corrected it to work around (close and re-open)
without realizing it was a regress
2008/10/23 Mullins, Steven <[EMAIL PROTECTED]>:
> Thanks everyone for the pointers. I assume the Linux version compiles with
> GCC. From what I read, Visual Studio is needed for a win32 compile, which I
> do not have.
You can download and install the Visual Studio Express for free:
http://www
Thanks for the response Phil.
When I looked more closely at my linux system I learned that using
synaptic to install gdal on ubuntu from source
http://archive.canonical.com/ubuntu (hardy) gave me version 1.4.4. I
hadn't noticed the version installed was out of date. I installed 1.6
by compiling s
Kai Behncke wrote:
Dear Frank,
thank you for that hint.
I imagine there is an issue with how the datum shifting is being done.
It looks to me that by default EPSG:31467 does not have datum shift
parameters supplied with it (as expected by GDAL/OGR).
Is there a possibility to put this datum s
Thanks everyone for the pointers. I assume the Linux version compiles with
GCC. From what I read, Visual Studio is needed for a win32 compile, which I do
not have. Any chance I could do this with GCC in win32?
Thanks again,
Steve
-Original Message-
From: Frank Warmerdam [mailto:[EM
Mullins, Steven wrote:
I am interested in using OGR to read data from an ArcSDE (9.2-9.3) database.
The manual page at http://www.gdal.org/ogr/drv_sde.html indicates that GDAL
must be compiled "with the ESRI provided ArcSDE client libraries".
Before I sink a lot a time into this, can anyone shar
Steve,
If you require a Windows based build, you should identify the location
of your SDE client lib and header files and modify your gdal nmake.opt
accordingly:
SDE_ENABLED = YES
SDE_VERSION=92
SDE_PLUGIN = YES
SDE_SDK = C:\arcgis\arcsde
SDE_INC = $(SDE_SDK)\include
SDE_LIB = $(SDE_SDK)\lib\pe$(
I am interested in using OGR to read data from an ArcSDE (9.2-9.3) database.
The manual page at http://www.gdal.org/ogr/drv_sde.html indicates that GDAL
must be compiled "with the ESRI provided ArcSDE client libraries".
Before I sink a lot a time into this, can anyone share their experience
On Thu, Oct 23, 2008 at 11:27 AM, Bernhard Höfle <[EMAIL PROTECTED]> wrote:
> Is this patch (ticket #1983), posted 1 year ago, the latest state for
> building with GRASS support for windows?
I have added a comment there:
http://trac.osgeo.org/gdal/ticket/1983#comment:2
Markus
Dear users:
I did it in the following way: With gdalwarp I projected an air image to 31467.
With ogr2ogr I transformed a shape from 4326 to 31467.
To have a comparison I transformed my data also with ArcGIS.
Then I loaded the data (in Quantum GIS and in ArcGIS)- everything looked fine,
so I hav
Hi!
I have seen ticket #1983 (http://trac.osgeo.org/gdal/ticket/1983). I would like to compile GDAL (on
Windows) with GRASS support using Visual Studio (i.e. nmake). Unfortunately, I cannot give it a try
because the link to the VC GRASS built (within QGIS SVN?:
https://svn.qgis.org/trac/browse
Dear Frank,
thank you for that hint.
> I imagine there is an issue with how the datum shifting is being done.
> It looks to me that by default EPSG:31467 does not have datum shift
> parameters supplied with it (as expected by GDAL/OGR).
Is there a possibility to put this datum shift parameters m
19 matches
Mail list logo
