That is a good news !
On Wed, Jan 5, 2011 at 5:02 PM, Ralf Suhr ralf.s...@itc-halle.de wrote:
Hi Chris,
if you have a newer gdal version (1.8). ogrinfo will produce:
Layer name: AddressPoint
Geometry: Point
Feature Count: 1
Extent: (405525.60, 628349.00) - (405525.60,
Dear all,
I try to convert a SAGA grid (SAGA), from a ETRS 89 / ETRS-LAEA to WGS84
CRS , but I get the following error message:
gdalwarp -s_srs +proj=laea +lat_0=52 +lon_0=10 +x_0=4321000 +y_0=321
+ellps=GRS80 +units=m +no_defs -t_srs +proj=longlat +ellps=WGS84
+datum=WGS84 +no_defs -r near
On 01/06/2011 01:18 AM, Tamas Szekeres wrote:
Chris,
Good points below, but having the compiled gdal binaries (and the
binaries of the dependent libraries) in hand, which is the right way
to install those files on Windows? (Assuming we don't provide
python.exe and the related files in the
2011/1/6 Ari Jolma ari.jo...@gmail.com
GDAL is available but again typically as MS compiler builds - which should
not be a problem in theory because the bindings use it through the C API.
I've tried to use those a couple of times without luck (compiling the
bindings in MinGW was the
Three months ago I put an announcement on the MapServer-Users list about
a shell script I wrote to compile the whole MapServer-GDAL-PostGIS-PLR
suite, with and without PHP/Python, in a separate user directory using
only two commands. Separate installations can coexist in separate
directory
Jason,
I appreciate the expertise for all of you along with this thread, I could
already gather quite some useful information from here for this reason. I
must mention that my programming practice in Python can be considered as
zero, this is the main reason that my issues may have trivial
This seems to me like an integer overflow - looking at the GDAL 1.7.2
sources I see, that the WriteHeader() method of sagadataset.cpp is using
GInt16 nXSize, GInt16 nYSize
Most likely this should be changed to
int nXSize, int nYSize
Best regards,
Volker
Am 06.01.2011 10:48, schrieb
On 01/06/2011 01:38 PM, Tamas Szekeres wrote:
2011/1/6 Ari Jolma ari.jo...@gmail.com mailto:ari.jo...@gmail.com
GDAL is available but again typically as MS compiler builds -
which should not be a problem in theory because the bindings use
it through the C API. I've tried to use
2011/1/6 Ari Jolma ari.jo...@gmail.com
By the age I meant that the SDK packages are old releases (from 1310 to
1600 and not trunk for example - do I understand the release names
correctly?)
Ari,
Those numbers are MSVC compiler numbers (according to
On 01/06/2011 03:25 PM, Tamas Szekeres wrote:
Assuming we install the gdal-perl modules in a standard location (not
sure where it is), do we have a common mechanism in the perl runtime
to find the dependent dlls without having to violate system wide
settings (like the PATH environment
Ari
The only wokaround which is satisfactory to me is to set the required
enviroment at run time before the gdal bindings are used. In csharp we can
do something like:
string path =
Environment.GetEnvironmentVariable(PATH);
if
Tamas,
Apologies in advance for repeating stuff below that you already know.
Assuming we have the scenario of a Windows Python programmer wants to use
GDAL from Python like he uses other Python packages, and is not interested
in running GDAL command-line utilities or accessing GDAL by
2011/1/6 Jason Roberts jason.robe...@duke.edu
2.Build an installation package as above. Have it install the GDAL
DLLs as a subdirectory of the osgeo directory, e.g.
C:\PythonXY\Lib\site-packages\osgeo\bin. Modify gdal.py to set
os.environ['PATH'] = os.environ['PATH'] + ';' gdalInstallDir
On 06/01/11 16:53, Mohammed Rashad wrote:
Anyone plea se provide a source code of just a simple shapefile viewer
in C/C++ or python
http://www.codeproject.com/KB/openGL/RenderSHP.aspx
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
Member
i checked it. Its not working properly and uses openGL
On Thu, Jan 6, 2011 at 10:31 PM, Mateusz Loskot mate...@loskot.net wrote:
On 06/01/11 16:53, Mohammed Rashad wrote:
Anyone plea se provide a source code of just a simple shapefile viewer
in C/C++ or python
On 06/01/11 16:58, Mohammed Rashad wrote:
i checked it. Its not working properly and uses openGL
You didn't mention it can not be based on OpenGL or any other rendering
API. No idea what you mean not working properly,
The code provides good example on how to read vectors from Shapefile
and
Tamas,
I think with either option #2 or #3, gdal.py will have to be modified in
order for everything to be invisible to the user. In #2, gdal.py would have
to modify the PATH variable. In #3, it would have to import the
_gdal_dll_helper module. In either case, it would just be a few lines of
On Thu, Jan 6, 2011 at 10:45 PM, Mateusz Loskot mate...@loskot.net wrote:
On 06/01/11 17:06, Mohammed Rashad wrote:
when the window resize the size of shapefile is also changed. by not
working I mean its not displaying shapefile correctly.
This is a very simple example, it does not have
On 1/6/11 9:19 AM, Mohammed Rashad wrote:
Instead of looking for code, I'd rather suggest to sit down and think
what you need. I assure you, all you need you have in OGR tutorial
on gdal.org/ogr http://gdal.org/ogr website. The only thing you
need more is to pass vector
Rashad,
I assume you are looking for a simple viewer for non-changing shapefiles.
You can use the GDAL library and the code from the gdal_rasterize utility.
On Thu, Jan 6, 2011 at 11:17 PM, Mohammed Rashad mohammedrasha...@gmail.com
wrote:
On Thu, Jan 6, 2011 at 11:09 PM, Christopher Barker
Le jeudi 06 janvier 2011 13:27:01, Volker Wichmann a écrit :
This seems to me like an integer overflow - looking at the GDAL 1.7.2
sources I see, that the WriteHeader() method of sagadataset.cpp is using
GInt16 nXSize, GInt16 nYSize
Most likely this should be changed to
int nXSize, int
Lots of stuff in this thread, I'll try to contribute what I can inline:
On 1/6/11 2:15 AM, Ari Jolma wrote:
When I started there was only ActivePerl for Windows that was usable,
but it turned out impossible for me to use because they use MS
compilers. Now there is Strawberry Perl, which I might
Hi,
I just updated the older version of gdal (1.4.2) with the latest
version of gdal (1.7.3) on x64 RedHat. Got an error when using
gdal_polygonize.py for a test image
gdal_polyzonize.py t2.tif -f ESRI Shapefile pt2
gdal.Polyzonize() not available. You are likely using old gen bindings
or
Tamas,
In Perl the programmer can postpone loading the external DLL required by
a module. Thus a similar approach is viable in Perl. But that's not how
it's usually done. If you have a DLL in a system that is meant for
shared use then it should be in the system PATH. Thus I believe the
Hi,
For those running the GDAL autotest suite, I just wanted to notify that I have
added a mechanism to add 'slow' tests that aren't normaly run to avoid making
a run of the autotest suite to last for too long. If the environment variable
GDAL_RUN_SLOW_TESTS is set to YES when running the
On 1/6/11 12:13 PM, Ari Jolma wrote:
If you have a DLL in a system that is meant for
shared use then it should be in the system PATH. Thus I believe the
policy should be to set the PATH if GDAL is installed into a system
I notice on my system, the dll is gdal17.dll
That is, the version is
Chris,
Here are some comments on specific parts of your mail:
me neither, with Python (or anything Windows, for that matter). Maybe
Jason knows better, but I *think* we should be OK with a standard
location for GDAL. But could you have:
Program Files\GDAL\1.6\gdal.dll
and
Program
On 1/6/11 12:31 PM, Jason Roberts wrote:
Here are some comments on specific parts of your mail:
Program Files\GDAL\1.6\gdal.dll
and
Program Files\GDAL\1.6\gdal.dll
Those would be reasonable locations for GDAL to live if the GDAL team
decided to distribute the GDAL binaries using an
2011/1/6 Christopher Barker chris.bar...@noaa.gov
I notice on my system, the dll is gdal17.dll
That is, the version is part of the file name, so there shouldn't be a
problem with different versions installed in the PATH.
WE could even use a longer filename, like *nix systems, we're not
On 11-01-06 04:42 PM, Christopher Barker wrote:
On 1/6/11 12:31 PM, Jason Roberts wrote:
Here are some comments on specific parts of your mail:
Program Files\GDAL\1.6\gdal.dll
and
Program Files\GDAL\1.6\gdal.dll
Those would be reasonable locations for GDAL to live if the GDAL team
decided
On 1/6/11 1:51 PM, Tamas Szekeres wrote:
2011/1/6 Christopher Barker chris.bar...@noaa.gov
This is where a typical dll hell problem is starting. The application is
happy to load a common dll let's say a gdal17.dll, zlib1.dll,
libcurl.dll whatever, but is not the same at it is expected to be (for
Frank,
Thanks for sharing your opinion. I do have one question that I hope you will
weigh in on. Which of the following two options seems better to you:
1. The GDAL libraries (possibly accompanied with executable programs) are
installed as a separately from the GDAL Python bindings. The
2011/1/6 Christopher Barker chris.bar...@noaa.gov
yup -- it seems long, descriptive file names would help, but that doesn't
seem to be the Windows way...
It would be true, but it's not a common practice of the libraries currently
(assuming we keep the original dll name of each dependency).
On 11-01-06 05:10 PM, Jason Roberts wrote:
Frank,
Thanks for sharing your opinion. I do have one question that I hope you will
weigh in on. Which of the following two options seems better to you:
1. The GDAL libraries (possibly accompanied with executable programs) are
installed as a
2011/1/6 Jason Roberts jason.robe...@duke.edu
So #3 is not better by virtue of not having to modify the bindings; it does
have to modify the bindings. But #3 is appealing because setting the PATH
from Python code sometimes has weird issues. For example, when I tried it in
my code, it
On 06-01-2011 21:42, Christopher Barker wrote:
On 1/6/11 12:31 PM, Jason Roberts wrote:
Here are some comments on specific parts of your mail:
Program Files\GDAL\1.6\gdal.dll
and
Program Files\GDAL\1.6\gdal.dll
Those would be reasonable locations for GDAL to live if the GDAL team
decided
Frank,
Thanks for your thoughts. Based on them, I'd recommend the following two
things be created.
1. GDAL windows installation program, or at minimum, a wiki page that says
how to install the GDAL libraries and utilities (executables and Python
scripts) to \Program Files\GDAL\... Perhaps a
1.Modify the makefiles for your SDK so that it runs
release--dev\gdal\swig\python\setup.py with the bdist
--formats=wininst option. This will produce an installation program such as
gdal-1.7.3.win32-py2.5.exe. This is what the user will run to install the
Python bindings together with a
Hi Frank,
On Thu, 06. Jan 2011 at 17:00:31 -0500, Frank Warmerdam wrote:
I have no objection to using \Program Files\GDAL\major.minor\ as a
standard location for GDAL stuff on windows. If this is done, the GDAL
data search location should be compiled in for this location on windows,
much as
That's a shame. I just might have to write my own GDAL tool to accomplish
this then (should be a fun way to learn the GDAL library as well). I've
tried converting to RGB and going from there, but the resulting file sizes
become very large in comparison and take hours to merge.
On Wed, Jan 5, 2011
On 1/6/11 3:03 PM, Joaquim Luis wrote:
Also a word about the best practice on Windows. I really don't see
anything not even good in that practice to put them in Program Files.
Having directories with blanks in their name give nothing but future
problems when running command line programs (I have
Perhaps that's why the standard place for Python is NOT in Program
Files
Yes, there is wisdom.
That being said, Program Files does seem to work fine for me most of
the time.
And for the (1 - most) times that it didn't work you knew how to fix
it (enclosing the full path with ) but
Windows 7 might actually be different - perhaps they now even now use
symlinks
to point a localized path to a hidden Program Files.
Good point. In Vista, Microsoft introduced a virtualization feature that
silently redirects write attempts to Program Files. This is part of the very
complicated,
On 11-01-06 06:43 PM, Jason Roberts wrote:
Frank,
Thanks for your thoughts. Based on them, I'd recommend the following two
things be created.
1. GDAL windows installation program, or at minimum, a wiki page that says
how to install the GDAL libraries and utilities (executables and Python
Xiaodong,
Check again after setting the environment variable PYTHONPATH to the path to
the new python bindings.
On Fri, Jan 7, 2011 at 12:55 AM, Xiaodong Zhang xiaodong.zha...@und.eduwrote:
Hi,
I just updated the older version of gdal (1.4.2) with the latest version
of gdal (1.7.3) on x64
On 11-01-05 04:09 PM, Michael Buchoff wrote:
We are trying to convert a 16-bit img into an 8-bit tif. Unfortunately, the
colors appear VERY dark (not downconverted, but just plain dark). I suspect
that this has something to do with the histogram. The gdalinfo of the original
image can be found
Hi Frank,
On Thu, 06. Jan 2011 at 22:55:34 -0500, Frank Warmerdam wrote:
I would suggest building it as an installer .exe, perhaps using NSIS as
I did for FWTools, or perhaps the method mentioned by Jurgen produces
a nice installer.
Man, I'm really tempted to leap into this myself but I have
Jürgen,
I think this is a terrific start!
To bring this up to the capabilities that I already use from FWTools, how would
an end user like myself add in support for additional formats (e.g. JPEG2000,
MrSID) and .NET bindings?
Thanks,
Jonathan
From:
48 matches
Mail list logo
