date:20110106


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 package)? I mean which install 
actions should be done in detail?





2011/1/5 Christopher Barker:


Windows binaries built in MinGW are available at:

http://map.hut.fi/files/Geoinformatica/win32/

The Geoinformatica-yy-mm-dd.zip contains GDAL (usually a
development version), Perl-GDAL, Perl, and many other things.


good for MinGW users, I suppose -- I remember them not working for
me, tough I can't recall how or why not. They also suffer from
perhaps trying to be too much (though if it all worked, I wouldn't
care, I have a fast network and large hard drive)



I found it impossible to deliver a Windows binary solution, which would 
depend on the three main packages (Perl, GTK+, and GDAL) to be retrieved 
as binaries from some standard location - that's why I bundle them all 
together into a quite large (32MB) package.


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 try again (or pay 
someone to try). It is good because it uses MinGW.


There are binary installers for GTK+ for Windows, which install them 
into a shared location - but there are problems still and some pieces 
are missing that I need (Glade for example). The official GTK+ site has 
a long list of zips containing binaries. Despite the shared nature of 
GTK+, many projects include own binaries of them in Windows due to 
version mismatches etc.


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 problem). Maybe I should try 
again using binaries from Tamas' site.


I agree that there could be a one main site for GDAL Windows binaries 
(something like http://www.gtk.org/download-windows.html). Tamas' site 
looks good but I'd like to have dev packages also (the SDK packages 
there look old) - just the header files should be enough.


Then there could also be a more end-user type Windows installation 
package project for GDAL, which installs the stuff into some standard 
location (c:\Program Files\share?). For GTK+ that's provided by some 
folks at http://sourceforge.net/projects/gtk-win/


It would be neat to be able to just put to the Geoinformatica Windows 
installer subinstallations, which go and get Perl, GTK+ and GDAL for the 
user if she does not yet have them or has too old ones. In fact 
Geoinformatica should be simply installable through Perl's cpan 
application - but that does not even work in Linux yet :( (the reason is 
that the GDAL Perl module installation script is not intelligent enough 
and the version of the module in CPAN is horribly old and I really suck 
at managing that)


Best regards,

Ari

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

Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

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 problem). Maybe I should try again using binaries
 from Tamas' site.

 I agree that there could be a one main site for GDAL Windows binaries
 (something like http://www.gtk.org/download-windows.html). Tamas' site
 looks good but I'd like to have dev packages also (the SDK packages there
 look old) - just the header files should be enough.


Ari,

The SDK packages from http://vbkto.dyndns.org/sdk/ are exactly the same
which have been used to compile the daily builds, so it should be up to
date. The only thing may have to be done is to download the required version
of the gdal sources in the root folder, because not all of the versions
included in the package in order to keep the size as small as possible.

BTW: What is the desired practice to install the gdal files + bindings along
with a pre-installed perl runtime on Windows? Something like we have been
discussing for python in this thread, do we have some desired install
locations, environment settings or packaging conventions?


Best regards,

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

Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

2011-01-06 Thread Jan Hartmann

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 trees and all parameters of all programs can be adapted for 
eacht installation. Apache, PHP, PostGIS and Python are installed for 
each installation separately. The binaries can be transported to 
computers with the same system libraries. Since then,I tried it out on 
dozens of Virtual Machines in a Cloud virtual environment on Suse, 
Fedora and (prefered) Debian virtual machines, and it works for me 
without glitches. It's something like a low-level replacement for 
FWTools (actually, I wrote it when I heard from Frank that FWTools 
wasn't supported at the moment). It's Linux-only, although porting it to 
Windows should be possible with a msys/cygwin shell, even for native 
compiles.


Since then I got no (zero) replies, so I don't know whether it doesn't 
work, isn't interesting, or people just didn't look at it. If it's worth 
your time and answers some of the questions from this discussion, please 
have a look and let me know what you think of it. And that includes 
doesn't work, not interesting, not adaptable enough, downright stupid. 
Here is the MS-Users posting:


http://lists.osgeo.org/pipermail/mapserver-users/2010-October/066898.html

Cheers,

Jan

On 01/05/11 23:32, Frank Warmerdam wrote:

Folks,

Wow, what a lot of discussion.

From my perspective, I'm pleased with Tamas' provided binaries as a 
source

for developers who want a GDAL SDK for a particular compiler version and
choice of win32/win64.

I like Jurgen's idea of building a stock GDAL binaries package with an
installer (similar to FWTools) from OSGeo4W packages.

Like some others, I'm also confused by the correct way of providing
python binaries.  I'm inclined to provide an included python in a self
installer similar to FWTools, but I'd be pleased if the hardcore
Pythonistas can get the magic ways of producing python binaries for any
Python version working.

Is there someone that wants to take on producing official GDAL binaries
from OSGeo4W with a self installer sort of similar to FWTools, likely
using the mechanism Jurgen described?  I'm interested, but interest 
hasn't

turned into action over quite a few months of interest.

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

Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

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 solutions for
the hardcore pythonists but not trivial to me. Apologies for this
inconvenience :-)

Getting back to the original topic, you mention that the gdal binaries
should be installed somewhere an set PATH, GDAL_DATA, PROJ_LIB and
GDAL_DRIVER_PATH as a systemwide setting. This is where the problems of mine
are starting. Modifying the PATH globally is a bad practice in 99% of the
cases. The only case I'm aware of which may not be a problem when we make
sure that only one version of such files (dll-s and executables) will ever
be installed to a particular system. But this is not the case with the gdal
binaries as I would expect at least a development or a stable version (and
their x86/x64 variants) to coexist which should be used by the same user.
The same problem may arise when we would like to install multiple versions
to the site packages directory, how the versions of the files are maintained
by the python runtime? In this regard I could mention something like what
have been done with the .NET framework with the multiple versions of the
packages installed simultaneously in the global assembly cache. The
individual packages may specify the required minimum version of the referred
packages loaded by the .NET runtime. Is this something that can be done with
the python environment as well?

(As opposed to this, the dumb solution of having a starting script to open a
command prompt (and setting PYTHONPATH properly) would ensure multiple
versions to be used at the same time, since those settings are applyed to
the cmd process solely.)

Best regards,

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

Re: [gdal-dev] SAGA: problem to convert grid from ETRS 89 / ETRS-LAEA to WGS84 CRS

2011-01-06 Thread Volker Wichmann

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 Clément Tisseuil:

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 -of SAGA hdr.sdat ./tmp/hdr.sdat

Creating output file that is 39901P x 15248L.
ERROR 1: Invalid dataset dimensions : -25635 x 15248

Any ideas ?

Thanks in advance.

--
Clément



___
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

Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0


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 those a couple of times
without luck (compiling the bindings in MinGW was the problem).
Maybe I should try again using binaries from Tamas' site.

I agree that there could be a one main site for GDAL Windows
binaries (something like
http://www.gtk.org/download-windows.html). Tamas' site looks good
but I'd like to have dev packages also (the SDK packages there
look old) - just the header files should be enough.


Ari,

The SDK packages from http://vbkto.dyndns.org/sdk/ are exactly the 
same which have been used to compile the daily builds, so it should be 
up to date. The only thing may have to be done is to download the 
required version of the gdal sources in the root folder, because not 
all of the versions included in the package in order to keep the size 
as small as possible.


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?)




BTW: What is the desired practice to install the gdal files + bindings 
along with a pre-installed perl runtime on Windows? Something like we 
have been discussing for python in this thread, do we have some 
desired install locations, environment settings or packaging conventions?


CPAN has only sources, thus cpan application which is the standard to 
download and install perl modules expects you to have a compiler.


ActivePerl (in fact ActiveState, the company) maintains a repository of 
perl modules in binary versions, from where they can be simply 
downloaded and installed with another program. ActivePerl has tools for 
developing those binary packages. That's very similar to what Python 
has. I think ActiveState maintains its repository by itself - so if I 
just make the CPAN module intelligent enough it may end up there 
eventually. I think my Geo::Shapelib module was/is there.


I think it would not make sense to include GDAL into such a binary perl 
module package. Thus GDAL would need to be separately installable - the 
module installer could probably be made to offer install it for the user 
if it existed somewhere.


In short /me thinks the requirements are: 1) /me develop the perl 
bindings configure  make procedure better 2) we make GDAL-dev.msi 
available at an URL.


Ari




Best regards,

Tamas



___
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

Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

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
http://trac.osgeo.org/gdal/browser/trunk/gdal/nmake.opt) not gdal version
numbers.

CPAN has only sources, thus cpan application which is the standard to
 download and install perl modules expects you to have a compiler.

 ActivePerl (in fact ActiveState, the company) maintains a repository of
 perl modules in binary versions, from where they can be simply downloaded
 and installed with another program. ActivePerl has tools for developing
 those binary packages. That's very similar to what Python has. I think
 ActiveState maintains its repository by itself - so if I just make the CPAN
 module intelligent enough it may end up there eventually. I think my
 Geo::Shapelib module was/is there.

 I think it would not make sense to include GDAL into such a binary perl
 module package. Thus GDAL would need to be separately installable - the
 module installer could probably be made to offer install it for the user if
 it existed somewhere.


This is also the case with python and the other bindings: the gdal dll-s and
dependencies should also be installed somewhere. 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 variable)?

Best regards,

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

Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0


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 variable)?


:) I'm not completely satisfied (I'm also not sure I really understand 
the whole f* issue) with how Perl searches for dll's - especially dll 
import libs - in Windows.


But that's configure/compile time issue. In compile time a Perl GDAL dll 
(for the bindings) is created and put into some location, which is known 
to Perl and Perl knows how to find it in runtime.


Assuming I've built the binaries, then in runtime (when the GDAL module 
is called for) I think somebody (because the Perl GDAL module dll has a 
link to GDAL dll that was put there in compile time) asks for the GDAL 
dll's and they simply need to be available. Thus, if there is GDAL in 
the system (for example in c:\Program Files\Share\GDAL\bin) then that 
path needs to be in the PATH - I don't think there is a way around that. 
The PATH may be a temporary PATH set by somebody for Perl programs, but 
I think the policy should be that when you run GDAL.msi, the system 
default PATH is modified to have the path to the GDAL binaries.


Best regards,

Ari

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

Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

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 (!path.Contains(gdal_bin_path))
{
Environment.SetEnvironmentVariable(PATH,
gdal_bin_path + ; + path);
}
Gdal.SetConfigOption(GDAL_DRIVER_PATH,
gdal_driver_path);

But it requires that loading the gdal dll is happening when the interface is
used actually (in Gdal.SetConfigOption with the code above). This is the
case with the .NET runtime,  but I'm not sure how do we stand with the other
bindings in this regard.

Futher problem with this solution is that this startup code should be placed
in the user's script and not sure how this could be implemented in the gdal
bindings itself.

Best regards,

Tamas




2011/1/6 Ari Jolma ari.jo...@gmail.com

 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 variable)?


 :) I'm not completely satisfied (I'm also not sure I really understand the
 whole f* issue) with how Perl searches for dll's - especially dll import
 libs - in Windows.

 But that's configure/compile time issue. In compile time a Perl GDAL dll
 (for the bindings) is created and put into some location, which is known to
 Perl and Perl knows how to find it in runtime.

 Assuming I've built the binaries, then in runtime (when the GDAL module is
 called for) I think somebody (because the Perl GDAL module dll has a link to
 GDAL dll that was put there in compile time) asks for the GDAL dll's and
 they simply need to be available. Thus, if there is GDAL in the system (for
 example in c:\Program Files\Share\GDAL\bin) then that path needs to be in
 the PATH - I don't think there is a way around that. The PATH may be a
 temporary PATH set by somebody for Perl programs, but I think the policy
 should be that when you run GDAL.msi, the system default PATH is modified to
 have the path to the GDAL binaries.

 Best regards,

 Ari


 ___
 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

RE: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

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 other means,
then all he needs is the GDAL Python bindings coupled with the GDAL DLLs and
associated supporting files. He doesn't really care about those DLLs and
supporting files; he just wants the Python bindings to work with a minimum
of steps. Ideally, he would just be able to start the GDAL installer, click
Next the next button four times, accepting all the default choices like he
does with any other Python package installer, watch the progress bar, and
then be able to import the osgeo modules from Python when it is complete.

 

In this scenario, Python is already installed. Multiple versions of it may
be installed. Python supports side-by-side installation of any number and
combination of versions. The default installation location is C:\PythonXY
where XY are the major and minor version numbers. If the user accepted the
defaults when he installed Python itself, that's where it will be. (That
somewhat violates Microsoft's best practice of storing programs in
C:\Program Files. I'm sure there's a long thread on that somewhere in the
Python mailing list archives, but I've never seen it.) Certain applications
that embed Python may choose a different location. For example, ArcGIS 10
includes a copy of Python 2.6 and ESRI decided to store it in
C:\Python26\ArcGIS10.0. I'm not sure what that was done, but it doesn't
really matter.

 

Python's installer maintains a list of which versions are installed and the
installation locations in the Windows Registry (a system-wide database of
config info). When a package installation program runs, assuming it was
built with the standard Python distutils technology I mentioned, it prompts
the user with a list of installed Python instances and asks which one he
wants to install he package to. The user picks one and the package files are
installed to the site-packages directory within that Python instance. This
will be, for example, C:\Python26\Lib\site-packages.

 

If a Python package includes extension modules, i.e. Python modules written
in C/C++ rather than Python, they are compiled by Python to .pyd files.
These are actually DLLs; they just have the extension .pyd rather than .dll
and must contain a certain entry point that Python can call after loading
them. GDAL includes several of these, such as _gdal.pyd, _gdal_array.pyd,
and so on. These modules implicltly link to the GDAL DLLs such as
gdal17.dll. Therefore, in order for Python to successfully load _gdal.pyd
when the Python program imports the osgeo.gdal package, gdal17.dll has to be
locatable by Windows, along with the other modules that gdal17.dll itself
depends on.

 

There are several ways that gdal17.dll might be locatable. Here is what
Windows does:
http://msdn.microsoft.com/en-us/library/7d83bc18%28v=vs.80%29.aspx.
Unfortunately, none of those are optimal for GDAL's Python bindings. Under
the first option, the executable module will typically but not always be
C:\PythonXY\python.exe. If an embedding application loads the Python
interpreter, it will be whatever executable that program is (e.g. C:\Program
Files\ArcGIS\bin\ArcMap.exe). So this is not a good choice.

 

The second choice, the current directory, might be something to try. The
GDAL Python bindings, e.g. gdal.py, could be modified to call a Python
function to change the current directory to wherever the GDAL DLLs are, then
import the _gdal.pyd, then change directory back.

 

The Windows system directory (C:\Windows\system32) and Windows directory
(C:\Windows) are probably not good. You guys don't want to put all of your
DLLs in there.

 

The directories listed in the PATH environment variable are the typical
solution. This is probably what most Python programmers do these days, based
on instructions from the GDAL team. They put GDAL in C:\gdal17 or something
and use the Windows Control Panel to modify the system PATH variable, so
that all Windows processes will have C:\gdal17 in the PATH. But in our
scenario, the Python programmer doesn't really care about the GDAL DLLs.
He's not planning to build something in another language that links to them.
He just wants his Python stuff to work with a minimum of fuss. So this is
less than optimal from his point of view.

 

Here are some possible alternatives:

 

1.The minimum case: build an installation package for the Python
bindings but still require the user to manually store the GDAL binaries
someplace and set PATH, PROJ_LIB, GDAL_DATA, etc. This will at least give a
GUI installer to get the bindings installed, even if they still have to
manually install GDAL.

 

2.Build an installation package as above. Have it install the GDAL DLLs
as a subdirectory of the osgeo directory, e.g.

Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

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 to modify the
PATH to include that directory prior to importing _gdal.pyd. The PATH will
be modified for the running process only, for the duration of that process.

3.Same as #2 but rather than modifying gdal.py to set the PATH
variable, instead create a new Python extension module called
_gdal_dll_helper.pyd. The job of this C extension module is simply to get
gdal.dll and other DLLs loaded without resorting to modifying the system
PATH which can sometimes have weird consequences (I can explain more if
needed). The extension module would call the Windows
SetDllDirectoryhttp://msdn.microsoft.com/en-us/library/ms686203%28v=vs.85%29.aspxfunction,
call LoadLibrary to explicitly load gdal17.dll into the current
process, then call SetDllDirectory again to set the DLL directory back to
what it was previously. Then, when gdal.py wants to load _gdal.pyd,
gdal17.dll is already loaded and the binding succeeds.
I know #2 and #3 sound scary but they can be done cleanly. I currently use
a variation of #3 in my own project that embeds GDAL and its Python
bindings.

Jason,

Good writeup, thanks for that. You mention #2 and #3 which is exactly the
same I have in my mind. Already posted a code for #2 related to the csharp
bindings to demonstrate this option.

#2 would be fairly transparent for the user (no additional modules
imported), the only thing we could add is how gdal.py would find out the
install location of the gdal files. This may probably set in the registry
added by the installer. Not sure how this addition would affect the gdal
binding on other platforms (if we implement this in gdal)

#3 seems to be better for gdal (doesn't require to modify the bindings)
however the user will require to use an additional module (which is not
required normally when using gdal.py)

I would personally vote on having an extension (like #3) which is imported
by gdal.py in case if it is installed. If this extension is not installed,
gdal.py would work as before. This extension would scan the registry to find
out the install location of the corresponding files (probably based on an
unique key) and perform the required actions to make the dll-s loadable.

Best regards,

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

Re: [gdal-dev] ogr shapefile viewer

2011-01-06 Thread Mateusz Loskot


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 of ACCU, http://accu.org
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] ogr shapefile viewer

2011-01-06 Thread Mohammed Rashad

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


 http://www.codeproject.com/KB/openGL/RenderSHP.aspx

 Best regards,
 --
 Mateusz Loskot, http://mateusz.loskot.net
 Charter Member of OSGeo, http://osgeo.org
 Member of ACCU, http://accu.org




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

Re: [gdal-dev] ogr shapefile viewer

2011-01-06 Thread Mateusz Loskot


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 pass to renderer. Just translate it to your renderer, Windows GDI, 
GTK+, whatever.
If you want to use OGR, but not Shapelib, learn from OGR tutorial and do 
the same thing.


Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
Member of ACCU, http://accu.org
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

RE: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

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
code at the top of the file that occurs before any other GDAL extension
modules are loaded (_gdal, _gdal_array, etc). It would also need to be done
for other modules such as ogr.py, osr.py, or whatever also imports GDAL
extension modules (unless those ones also import gdal.py first).

 

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 produced a weird problem when I tried to use the nose Python
testing framework to run test cases that involved calling Python modules
from GDAL and ArcGIS. The problem there may ultimately be a Microsoft issue
in which the environment settings for a process are maintained by the
Microsoft C runtime library (msvcrt*.dll) and Python, ArcGIS, and GDAL may
use different versions of that library. I do not want to digress into this
here, but suffice to say, I prefer #3 to #2 because it did not have this
problem.

 

Here is an outline of tasks. We probably should put it in an RFC to keep
track.

 

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 private copy of the GDAL DLLs used just by
those bindings. On Python 2.6 and later, we probably want bdist
--formats=msi to produce a .msi file rather than a .exe, because Windows
likes .msi files much better than .exes for security purposes. IIRC, Python
2.5 and earlier do not have the msi option.

 

2.Modify release--dev\gdal\swig\python\setup.py to include the GDAL
DLLs and data files in the data_files list that is passed to the setup()
function. Make sure it is only done for Windows (Python code can check
that). The goal is to have the installation program create the following
kind of installation:

 

Existing Python bindings:

 

C:\PythonXX\Lib\site-packages\osgeo\gdal.py

C:\PythonXX\Lib\site-packages\osgeo\ogr.py

C:\PythonXX\Lib\site-packages\osgeo\...

C:\PythonXX\Lib\site-packages\osgeo\_gdal.pyd

C:\PythonXX\Lib\site-packages\osgeo\_ogr.pyd

C:\PythonXX\Lib\site-packages\osgeo\...

 

New bin, data, and plugins directories, which are private to this
installation of the bindings:

 

C:\PythonXX\Lib\site-packages\osgeo\bin\gdal17.dll

C:\PythonXX\Lib\site-packages\osgeo\bin\proj.dll

C:\PythonXX\Lib\site-packages\osgeo\bin\...

 

C:\PythonXX\Lib\site-packages\osgeo\bin\gdal-data\coordinate_axis.csv

C:\PythonXX\Lib\site-packages\osgeo\bin\gdal-data\...

 

C:\PythonXX\Lib\site-packages\osgeo\bin\gdal-plugins\ogr_PG.dll

C:\PythonXX\Lib\site-packages\osgeo\bin\gdal-plugins\...

 

3.Introduce a new file
release--dev\gdal\swig\python\extensions\_gdal_dll_loader.cpp. This file
will call GetDllDirectory to find the current DLL directory setting, call
SetDllDirectory to C:\PythonXX\Lib\site-packages\osgeo\bin (or wherever the
Python instance is installed), call LoadLibrary(gdal17.dll), and call
SetDllDirectory back to what it was before. There are more details to
consider. For example, we might want to have it call LoadLibrary first to
see if it can load the GDAL DLL from the PATH, allowing the user to use
their own GDAL DLLs without having to overwrite the ones in the Python
directory. Or we might not want to do that, with the idea that the GDAL
Python bindings must be tightly coupled to a particular version of GDAL's
DLLs.

 

4.Modify setup.py to compile _gdal_dll_loader.cpp, only for Windows.
This will result in _gdal_dll_loader.pyd alongside the other .pyd files.

 

5.Modify gdal.py, osr.py, and so on to do something like this:

 

import sys

if sys.platform == 'win32': # TODO: add check for Windows x64 as well

try:

import osgeo._gdal_dll_loader  # As part of this, Python
will call an init function inside. That function will do the
SetDllDirectory, etc.

except:

pass

 

6.Do whatever is necessary to ensure the GDAL_DATA etc are properly set
up inside GDAL. I can't remember if this will just work using directories
named gdal-data, gdal-plugins, or if it is necessary for the
_gdal_dll_loader.pyd to call some GDAL functions to make it happen.

 

Does that sound like the right direction?

 

Jason

 

From: Tamas Szekeres [mailto:szeker...@gmail.com] 
Sent: Thursday, January 06, 2011 11:07 AM
To: Jason Roberts
Cc: gdal-dev@lists.osgeo.org
Subject: Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

 

 

2011/1/6 Jason Roberts

Re: [gdal-dev] ogr shapefile viewer

2011-01-06 Thread Mohammed Rashad

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 to handle all UI events,
 react on windows resize, etc.
 I can't believe size of Shapefile does change. It can't change as it's a
 file on disk, so unless you edit vectors in file, its size never changes.
 You probably mean size of vectors displayed. Again, it's simple example,
 loads Shapefile, creates a window, draws vectors from Shapefile in this
 window. That's it.

 You wanted simple, this is simple.


  can you point me to some other example with any api OpenGL also no
 problem


 Just google, there is plenty.

 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 website. The only thing you need more is to pass vector
 data/point to rendering API you want to use.

 yes Mateusz Loskot, i need this part. passing the vector data/point to a
rendering API.


Anyone can provide a simple example other than
http://www.codeproject.com/KB/openGL/RenderSHP.aspx

 p.s. please, do not reply privately to folks from mailing lists,
 reply to mailing list.


 Best regards,
 --
 Mateusz Loskot, http://mateusz.loskot.net
 Charter Member of OSGeo, http://osgeo.org
 Member of ACCU, http://accu.org




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

Re: [gdal-dev] ogr shapefile viewer


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 data/point to rendering API you want to use.

yes Mateusz Loskot, i need this part. passing the vector data/point to a
rendering API.


It's still not clear quite what you want. If you just want to look at 
shape files, I'd use an off-the-shelf desktop GIS, there are lots, QGIS 
is pretty nice.


You can also render shapefiles with mapnik or mapserver -- both are 
highly customizable and produce very nice output.


If you want a library you can embed in your own app, and maybe 
customize, that's a different story.


For Python you could use wxPython and my wx.lib.floatcanvas. It doesn't 
understand shape files, but with OGR reading them, it's very easy to 
throw points, lines and polygons on the canvas, and be able to zoom and 
pan around to look at them.


We've also got the maproom project:

https://bitbucket.org/dhelfman/maproom/overview

It's a bit stalled out now, but will be revived. It is designed to be a 
general purpose lib and application for interactive map data viewing and 
manipulation. It doesn't actually support shape files at the moment, but 
it does use GDAL/OGR and has support for points and polygons, so not 
hard to write a new plugin for shape.


It's also using OpenGL for speedy rendering.

HTH,

-Chris



--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

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

Re: [gdal-dev] ogr shapefile viewer

2011-01-06 Thread Chaitanya kumar CH

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 chris.bar...@noaa.gov
  wrote:

 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 data/point to rendering API you want to
 use.

 yes Mateusz Loskot, i need this part. passing the vector data/point to a
 rendering API.


 It's still not clear quite what you want. If you just want to look at
 shape files, I'd use an off-the-shelf desktop GIS, there are lots, QGIS is
 pretty nice.

 You can also render shapefiles with mapnik or mapserver -- both are highly
 customizable and produce very nice output.

 If you want a library you can embed in your own app, and maybe customize,
 that's a different story.

 I need a c++ library to just display an OGR shapefile. i need to embed this
 C++ library in my application that what I need. Is that clear? If you need
 any further details i will provide.


 For Python you could use wxPython and my wx.lib.floatcanvas. It doesn't
 understand shape files, but with OGR reading them, it's very easy to throw
 points, lines and polygons on the canvas, and be able to zoom and pan around
 to look at them.

 We've also got the maproom project:

 https://bitbucket.org/dhelfman/maproom/overview

 It's a bit stalled out now, but will be revived. It is designed to be a
 general purpose lib and application for interactive map data viewing and
 manipulation. It doesn't actually support shape files at the moment, but it
 does use GDAL/OGR and has support for points and polygons, so not hard to
 write a new plugin for shape.

 It's also using OpenGL for speedy rendering.

 HTH,

 -Chris



 --
 Christopher Barker, Ph.D.
 Oceanographer

 Emergency Response Division
 NOAA/NOS/ORR(206) 526-6959   voice
 7600 Sand Point Way NE   (206) 526-6329   fax
 Seattle, WA  98115   (206) 526-6317   main reception

 chris.bar...@noaa.gov




 --
 Rashad

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




-- 
Best regards,
Chaitanya kumar CH.
/tʃaɪθənjə/ /kʊmɑr/
+91-9494447584
17.2416N 80.1426E
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] SAGA: problem to convert grid from ETRS 89 / ETRS-LAEA to WGS84 CRS

2011-01-06 Thread Even Rouault

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 nYSize

Fixed by ticket http://trac.osgeo.org/gdal/ticket/3899.

 
 
 Best regards,
 Volker
 
 Am 06.01.2011 10:48, schrieb Clément Tisseuil:
  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 -of SAGA hdr.sdat
  ./tmp/hdr.sdat
  
  Creating output file that is 39901P x 15248L.
  ERROR 1: Invalid dataset dimensions : -25635 x 15248
  
  Any ideas ?
  
  Thanks in advance.
  
  --
  Clément
  
  
  
  ___
  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
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0


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 try again (or pay
someone to try). It is good because it uses MinGW.


The situation is a bit different for Python -- the Python.org binaries 
are almost universal (and I think the ActiveState ones are compatible). 
So it's the obvious choice to build against. They are built with MS 
compilers, but you can compile extensions with MinGW (at least for 2.6 
and above). However, ideally the MS compilers are users -- there are 
freely available versions that work (not Open source though!)



Then there could also be a more end-user type Windows installation
package project for GDAL, which installs the stuff into some standard
location (c:\Program Files\share?).


I think so too, but it's a bit unclear to me what's best as far as the 
various language bindings go...given all the versions of Python (and I 
assume others) it's a bit messy.



 In fact
Geoinformatica should be simply installable through Perl's cpan
application - but that does not even work in Linux yet :( (the reason is
that the GDAL Perl module installation script is not intelligent enough
and the version of the module in CPAN is horribly old and I really suck
at managing that)


Wow! given how much folks rave about CPAN, it sounds like PyPi is better 
in this regard, at least for binary packages.


On 1/6/11 4:00 AM, Jan Hartmann wrote:

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,


Did you provide Python, to use an existing python.org build?


Since then I got no (zero) replies, so I don't know whether it doesn't
work, isn't interesting, or people just didn't look at it.


well, for what it's worth, on LInux, users can go a long way with distro 
packages and the plain old ./configure; make.. dance.


Binaries on Windows are in much higher demand.

On 1/6/11 4:24 AM, Tamas Szekeres wrote:

Modifying the PATH globally is a bad practice in 99%
of the cases.


really? for command line tools, I do it all the time! It seems the ay to 
go if you want it to just work. Maybe it makes for more dll hell?



I would expect at least a development or a
stable version (and their x86/x64 variants) to coexist which should be
used by the same user.


This is mostly an issue for developers, and you are smart enough to take 
care of yourselves... As for me, I usually have a system wide default 
for things like GDAL on the PATH, and then will have a startup script or 
something that re-sets things if I want to run test versions, or I just 
call the exe I want explicitly


Anyway, putting a binary in a standard location is separate from 
having an installer modify the users PATH -- that second step should be 
optional, or just leave it for the user to do manually if they want.



The same problem may arise when we would like to
install multiple versions to the site packages directory, how the
versions of the files are maintained by the python runtime?


Python is very weak in that regard, There are three ways to handl eit now:

1)a roll-your-open version selection mechanism -- wxPython and I think 
PyGTK do this.


2) virtualenv, or similar -- they set up a virtual python install, so 
that you can have multiple installs, each with different versions of 
packages


3) setuptools provides some mechanism for egg version selection, though 
i've never really figure out how to use it.


I think (2) is the best recommendation -- the nice thing about it is 
that the packager doesn't have to do anything special -- it's handled by 
how the user installs a package -- if they use setup.py or easy_install, 
or pip, it just works -- maybe not with an msi, though.


So this points to building binary eggs, ideally.


 The individual packages may
specify the required minimum version of the referred packages loaded by
the .NET runtime. Is this something that can be done with the python
environment as well?


That's kind of what setuptools provides, but it's pretty kludgy.


(As opposed to this, the dumb solution of having a starting script to
open a command prompt (and setting PYTHONPATH properly) would ensure
multiple versions to be used at the same time, since those settings are
applied to the cmd process solely.)


I suspect that's how virtualenv works, more or less.

On 1/6/11 5:01 AM, Tamas Szekeres wrote:

I did mention to set the environment for the cmd process solely, and not
by a systemwide setting. In this regard it doesn't matter how many
python runtime is installed on a particular system, the only issue is to
refer to the desired one (by setting the PATH to the python executable
or using absolute path when running python) from the command

[gdal-dev] gdal_polygonize.py binding error

2011-01-06 Thread Xiaodong Zhang


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 an older version of the next gen bindings.


I found the previous threads on this issue, but could not find an answer.

Any idea? Thanks

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

Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0


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 
policy should be to set the PATH if GDAL is installed into a system (as 
such - not as a part of something else). Only if a package installs a 
private GDAL, it should be kept out of PATH and the package executables 
need to take care of setting the PATH or other env vars as appropriate 
(in Geoinformatica I do this - the Geoinformatica installer is basically 
a file copy and no env vars are changed).


Ari

6.1.2011 16:50, Tamas Szekeres kirjoitti:

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 (!path.Contains(gdal_bin_path))
{
Environment.SetEnvironmentVariable(PATH, 
gdal_bin_path + ; + path);

}
Gdal.SetConfigOption(GDAL_DRIVER_PATH, 
gdal_driver_path);


But it requires that loading the gdal dll is happening when the 
interface is used actually (in Gdal.SetConfigOption with the code 
above). This is the case with the .NET runtime,  but I'm not sure how 
do we stand with the other bindings in this regard.


Futher problem with this solution is that this startup code should be 
placed in the user's script and not sure how this could be implemented 
in the gdal bindings itself.


Best regards,

Tamas




2011/1/6 Ari Jolma ari.jo...@gmail.com mailto:ari.jo...@gmail.com

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
variable)?


:) I'm not completely satisfied (I'm also not sure I really
understand the whole f* issue) with how Perl searches for dll's -
especially dll import libs - in Windows.

But that's configure/compile time issue. In compile time a Perl
GDAL dll (for the bindings) is created and put into some location,
which is known to Perl and Perl knows how to find it in runtime.

Assuming I've built the binaries, then in runtime (when the GDAL
module is called for) I think somebody (because the Perl GDAL
module dll has a link to GDAL dll that was put there in compile
time) asks for the GDAL dll's and they simply need to be
available. Thus, if there is GDAL in the system (for example in
c:\Program Files\Share\GDAL\bin) then that path needs to be in the
PATH - I don't think there is a way around that. The PATH may be a
temporary PATH set by somebody for Perl programs, but I think the
policy should be that when you run GDAL.msi, the system default
PATH is modified to have the path to the GDAL binaries.

Best regards,

Ari


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org mailto: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


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

[gdal-dev] GDAL autotest optional/slow tests

2011-01-06 Thread Even Rouault

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 autotest, those tests will 
be run, otherwise they will be skipped (currently, there are just 2 such 
tests)

The justificiation is that some tests that trigger particular bugs, or that try 
to be exhaustive when testing some feature, cannot be written in a way where 
they will run fast (because of the algorithmic complexity, or the need to 
create big files, to use lots of memory, etc...) But it is a pity not to be 
able to test them on request, hence that mechanism.

Disclaimer : slow tests ... may be really slow ;-)

Best regards,

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

Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0


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 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 
restricted to 8.3 anymore, are we?


gdal-1.7.1-a.dll

for instance.

Though maybe setting up the build to do that is more trouble that it's 
worth.


-Chris


--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

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

RE: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

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 Files\GDAL\1.6\gdal.dll

 and have one Python binding find 1.6, and one find 1.7 -- I'm not sure 
 how to do that, but it SHOULD be doable! OH what i'd give for a symlink!

Those would be reasonable locations for GDAL to live if the GDAL team
decided to distribute the GDAL binaries using an installer that adhered to
the best practices on Windows. But putting them there would not mean they
would be automatically added to the PATH. The GDAL Python bindings would
still have to use one of the options I mentioned to load the binaries there
(e.g. modify the PATH).

Incidentally, Windows does support both symbolic and hard links, although it
is not widely known, and I'm not sure I'd recommend their use for this
particular problem.

 I think 2.5 is MSVC2003 (but that may be 2.4, my memory is fading...).

I believe both 2.4 and 2.5 used MSVC2003.

 Great summary -- thanks! And you clearly have a better grasp that I on 
 Windows dll hell.

I used to work for Microsoft, back in the day... :-)

 Modify gdal.py to set
 os.environ['PATH'] = os.environ['PATH'] + ';' gdalInstallDir to modify
 the PATH to include that directory prior to importing _gdal.pyd. The
 PATH will be modified for the running process only, for the duration of
 that process.

 I didn't think that was required, if the dll is in the same place as the 
 *.pyd, but maybe it is. And it seems it would work fine. Might it mess 
 things up if someone where to do a system call from Python? Also, would 
 that support py2exe?

Unfortunately, it is not sufficient to simply put the GDAL DLLs in the same
directory as the GDAL .pyd files. When the .pyd tries to load the GDAL DLL
through implicit linking, Windows checks the locations described in
http://msdn.microsoft.com/en-us/library/7d83bc18%28v=vs.80%29.aspx.

You are probably thinking of the first rule in that list, the directory
where the executable module for the current process is located, i.e. the
.exe file. In most cases, this is C:\PythonXY\python.exe. C:\PythonXY is
probably not an appropriate location for the GDAL DLLs. Plus it would not
work for other executables that host the Python interpreter, such as
C:\Program Files\ArcGIS\Bin\ArcMap.exe.

Incidentally, the Python interpreter itself is in a DLL that Python installs
in C:\Windows\system32, which is always very high up in the PATH. GDAL could
put its binaries there. But that might be very risky because GDAL ships a
lot of DLLs that other apps might also use. For example, GDAL optionally
includes xerces-c, which MATLAB and ArcGIS also use, among others. Plunking
GDAL's own copy of xerces-c into the PATH will screw up those apps.

 I wonder what is donefor theones here:

 http://www.lfd.uci.edu/~gohlke/pythonlibs/

I have been meaning to look at that since you originally sent it. It
probably gives an example of the kinds of stuff I mentioned. I wonder if it
is statically linked. Rgdal is one example where someone has statically
linked GDAL into their own project.

 could all that be done with some ctypes calls, rather than another 
 extension?

Yes I believe you are absolutely right. I always forget about ctypes because
I'm working on something that must be compatible back to Python 2.4 and
ctypes was not included in 2.4.

Jason


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

Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0


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 installer that adhered to
the best practices on Windows.


I *think* we're heading for a consensus to do that, but not many people 
have been on this thread.



Incidentally, Windows does support both symbolic and hard links, although it
is not widely known, and I'm not sure I'd recommend their use for this
particular problem.


I've heard that, but never seen it done.


You are probably thinking of the first rule in that list, the directory
where the executable module for the current process is located, i.e. the
.exe file. In most cases, this is C:\PythonXY\python.exe. C:\PythonXY is
probably not an appropriate location for the GDAL DLLs. Plus it would not
work for other executables that host the Python interpreter, such as
C:\Program Files\ArcGIS\Bin\ArcMap.exe.


What about C:\PYTHON26\libs ?

or is that for the main python distro only?


Incidentally, the Python interpreter itself is in a DLL that Python installs
in C:\Windows\system32, which is always very high up in the PATH. GDAL could
put its binaries there. But that might be very risky because GDAL ships a
lot of DLLs that other apps might also use.


I agree -- and Tamas would never go for it! ;-)


I wonder what is donefor theones here:

http://www.lfd.uci.edu/~gohlke/pythonlibs/


I have been meaning to look at that since you originally sent it.


let us now what you find -- I really can't spend any more time on this 
right now!



Rgdal is one example where someone has statically
linked GDAL into their own project.


so we know it can be done -- but with all the third party libs (xerces, 
etc, etc) that could be ugly/impossible.



could all that be done with some ctypes calls, rather than another
extension?


Yes I believe you are absolutely right. I always forget about ctypes because
I'm working on something that must be compatible back to Python 2.4 and
ctypes was not included in 2.4.


I've never actually used it, but it does seem made for this sort of thing.

As for versions, I don't know if GDAL has a policy about what versions 
to support, but I'd think we could dump 2.4 (and maybe even 2.5...), and 
that means only one MS compiler to support.


Thanks for your work on this,

-Chris




--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

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

Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

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
 restricted to 8.3 anymore, are we?

 gdal-1.7.1-a.dll


Chris,

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 example it
depends on different CRT libraries). The issue is that you rarely get a
clear error message what the problem is, but your application is failing
with access violations in certain conditions.

To make sure about the issue I did a quick test on my devserver with a
whereis.bat containing the following script, trying to find the location of
some common dlls (used by gdal):

@for %%e in (%PATHEXT%;.dll) do @for %%i in (%1%%e) do @if NOT
%%~$PATH:i== echo %%~$PATH:i


E:\buildswhereis zlib1
C:\Program Files (x86)\Mono-1.2.6\bin\zlib1.dll

E:\buildswhereis ssleay32
C:\Program Files (x86)\Subversion\ssleay32.dll

Depending on the location of my entry in the PATH may break both
applications or these files may break mine.

Not sure this causes an issue in this particular case but, it makes the
things fragile well enough.

Best regards,

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

Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0


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 to distribute the GDAL binaries using an installer that adhered to
the best practices on Windows.


I *think* we're heading for a consensus to do that, but not many people have
been on this thread.


Jason / Christopher,

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 it defaults to /usr/share/gdal (or /usr/local/share/gdal) on
linux.

Note that this means point releases cannot coexist on a system.  I think
that is mostly a good thing, in that upgrading to a new point release
should not change the ABI and should be a transparent change for any
applications.  That is also why we do not encode the point release values
in the DLL name.  That is the GDAL17.DLL from GDAL 1.7.3 should be a drop
in replacement for the GDAL17.DLL from GDAL 1.7.2.   If the DLL name was
more specific then applications would be forced to relink to use the new
version.

On the other hand, we do want major relases (1.7.x vs. 1.8.x) to coexist
and it is decision that applications need to make which they want to use.
So the proposed structure handles that well.

I'm going to stay out of the Python specific aspects.

Best regards,
--
---+--
I set the clouds in motion - turn up   | Frank Warmerdam, warmer...@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush| Geospatial Programmer for Rent

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

Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0


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
example it depends on different CRT libraries).


yup -- it seems long, descriptive file names would help, but that 
doesn't seem to be the Windows way...


OS_X hard-codes the path to shared libs when linking, which causes its 
own problems, but not these ones.


I think Jason has some good ideas, though.


To make sure about the issue I did a quick test on my devserver with a
whereis.bat containing the following script, trying to find the location
of some common dlls (used by gdal):

@for %%e in (%PATHEXT%;.dll) do @for %%i in (%1%%e) do @if NOT
%%~$PATH:i== echo %%~$PATH:i


E:\buildswhereis zlib1
C:\Program Files (x86)\Mono-1.2.6\bin\zlib1.dll

E:\buildswhereis ssleay32
C:\Program Files (x86)\Subversion\ssleay32.dll


so your gdal depends on Mono's zlib and Subversion's ssleay? that does 
seem fragile!


Or do you mean that you have these somewhere for gdal, and they are ALSO 
in those other locations?


-Chris



--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

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

RE: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

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 libraries are
installed to \Program Files as you describe and the Python bindings are
installed in the standard Python location. A Windows Python programmer
wanting to use GDAL would perform two installs: one for the GDAL libraries,
the other for the bindings.

2. The GDAL Python bindings include a private copy of the GDAL libraries
(with no executable programs). These are installed to a private subdirectory
with the bindings. A Windows Python programmer wanting to use GDAL only
needs to perform one install: the bindings.

#1 is essentially how things are done now, just not following Windows best
practices (not using \Program files) and without any automation to ease the
process (no regularly maintained installer for the Python bindings).

I was proposing #2, basically under the argument that a Windows Python
programmer who needs to use GDAL will rarely ever need to use GDAL for some
other purpose, and therefore not want to install and think about a separate
installation of the GDAL libraries themselves. But if you don't believe
that, or think it is important that the libraries remain distinct from the
bindings in this scenario for some other reason, then we would appreciate
your opinion.

Thanks,
Jason

-Original Message-
From: gdal-dev-boun...@lists.osgeo.org
[mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Frank Warmerdam
Sent: Thursday, January 06, 2011 5:01 PM
To: gdal-dev@lists.osgeo.org
Subject: Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

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 to distribute the GDAL binaries using an installer that adhered
to
 the best practices on Windows.

 I *think* we're heading for a consensus to do that, but not many people
have
 been on this thread.

Jason / Christopher,

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 it defaults to /usr/share/gdal (or /usr/local/share/gdal) on
linux.

Note that this means point releases cannot coexist on a system.  I think
that is mostly a good thing, in that upgrading to a new point release
should not change the ABI and should be a transparent change for any
applications.  That is also why we do not encode the point release values
in the DLL name.  That is the GDAL17.DLL from GDAL 1.7.3 should be a drop
in replacement for the GDAL17.DLL from GDAL 1.7.2.   If the DLL name was
more specific then applications would be forced to relink to use the new
version.

On the other hand, we do want major relases (1.7.x vs. 1.8.x) to coexist
and it is decision that applications need to make which they want to use.
So the proposed structure handles that well.

I'm going to stay out of the Python specific aspects.

Best regards,
-- 
---+
--
I set the clouds in motion - turn up   | Frank Warmerdam,
warmer...@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush| Geospatial Programmer for Rent

___
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

Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

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). However we
could probably rename our custom dlls with a random name during the build
process. Pretty odd, but workable.



 so your gdal depends on Mono's zlib and Subversion's ssleay? that does seem
 fragile!


Or do you mean that you have these somewhere for gdal, and they are ALSO in
 those other locations?


I must say a common gdal build (either FWTools, OSGeo4w, ms4w whatever) may
use dll-s with the same names as many other libraries a user may install. In
my particular case mono and subversion is just a live example. but we could
find many others that use zlib libpng libcurl whatever (these are widely
used libraries in the world). I don't actually suffer from this problem
because I never rely on the PATH environment to load the GDAL dependencies
and I would evangelize against this practice when trying to find out a
reasonable setup approach here also.

Best regards,

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

Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0


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 separately from the GDAL Python bindings. The libraries are
installed to \Program Files as you describe and the Python bindings are
installed in the standard Python location. A Windows Python programmer
wanting to use GDAL would perform two installs: one for the GDAL libraries,
the other for the bindings.

2. The GDAL Python bindings include a private copy of the GDAL libraries
(with no executable programs). These are installed to a private subdirectory
with the bindings. A Windows Python programmer wanting to use GDAL only
needs to perform one install: the bindings.

#1 is essentially how things are done now, just not following Windows best
practices (not using \Program files) and without any automation to ease the
process (no regularly maintained installer for the Python bindings).

I was proposing #2, basically under the argument that a Windows Python
programmer who needs to use GDAL will rarely ever need to use GDAL for some
other purpose, and therefore not want to install and think about a separate
installation of the GDAL libraries themselves. But if you don't believe
that, or think it is important that the libraries remain distinct from the
bindings in this scenario for some other reason, then we would appreciate
your opinion.


Jason,

I don't have a strong position on this, but I would note that beyond
real Python programmers wanting to use the bindings, they are also needed
just to run the python commandline utilities (such as rgb2pct.py).  So
there is definately a large body of folks who would benefit from having
working python for the python utilities, and the regular commandline
executables.

Another benefit of even Python using GDAL from a standard location is
things like format plugins could be easily handled in one place.

Actually, the more I think about it, the more I prefer even the Python
bindings to use the GDAL under \Program Files\GDAL.

If the Pythonistas really want to have their own copy of GDAL then
we really don't need to have this conversation.  They can do their
own thing, in their own place and there is no need for meaningful
cooperation with the core project.

Best regards,
--
---+--
I set the clouds in motion - turn up   | Frank Warmerdam, warmer...@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush| Geospatial Programmer for Rent

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

Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

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 produced a weird problem when I tried to use the “nose” Python
 testing framework to run test cases that involved calling Python modules
 from GDAL and ArcGIS. The problem there may ultimately be a Microsoft issue
 in which the environment settings for a process are maintained by the
 Microsoft C runtime library (msvcrt*.dll) and Python, ArcGIS, and GDAL may
 use different versions of that library. I do not want to digress into this
 here, but suffice to say, I prefer #3 to #2 because it did not have this
 problem.




This is quite a common issue the getenv/_putenv CRT functions operate only
on the data structures accessible to the run-time library (CRT) and not on
the environment segment created for the process by the operating system.
In this regard the libraries work only on a snapshot of the variables that
have been set during the CRT startup. In this case we should probably find a
function that invokes the
SetEnvironmentVariablehttp://msdn.microsoft.com/en-us/library/ms686206%28v=vs.85%29.aspxAPI
instead.





 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 private copy of the GDAL DLLs used just by
 those bindings. On Python 2.6 and later, we probably want “bdist
 --formats=msi” to produce a .msi file rather than a .exe, because Windows
 likes .msi files much better than .exes for security purposes. IIRC, Python
 2.5 and earlier do not have the msi option.



This can be done fairly easily. Does this mean we would require each build
for multiple python versions?


 2.Modify release--dev\gdal\swig\python\setup.py to include the
 GDAL DLLs and data files in the data_files list that is passed to the
 setup() function. Make sure it is only done for Windows (Python code can
 check that). The goal is to have the installation program create the
 following kind of installation:



Hmmm. I'm keen to avoid any local modifications in the compiled files
throughout the build system. Do we have some option to load this infromation
from an external file (which is probably loaded by setup.py if exists)? Or I
must write a custom setup2.py containing this customization.



 3.Introduce a new file
 release--dev\gdal\swig\python\extensions\_gdal_dll_loader.cpp. This file
 will call GetDllDirectory to find the current DLL directory setting, call
 SetDllDirectory to C:\PythonXX\Lib\site-packages\osgeo\bin (or wherever the
 Python instance is installed), call LoadLibrary(gdal17.dll), and call
 SetDllDirectory back to what it was before. There are more details to
 consider. For example, we might want to have it call LoadLibrary first to
 see if it can load the GDAL DLL from the PATH, allowing the user to use
 their own GDAL DLLs without having to overwrite the ones in the Python
 directory. Or we might *not* want to do that, with the idea that the GDAL
 Python bindings must be tightly coupled to a particular version of GDAL’s
 DLLs.



That seems to be quite complicated, not sure it that's working for those
libraries using LoadLibrary binding at run time. Wouldn't that be better
getting back to add the location to the PATH of the process in a loader.py
(using SetEnvironmentVariable).


 5.Modify gdal.py, osr.py, and so on to do something like this:



 import sys

 if sys.platform == 'win32': # TODO: add check for Windows x64 as well

 try:

 import osgeo._gdal_dll_loader  # As part of this, Python
 will call an “init” function inside. That function will do the
 SetDllDirectory, etc.

 except:

 pass


Such changes can be done in the SWIG interface files easily.




 6.Do whatever is necessary to ensure the GDAL_DATA etc are properly
 set up inside GDAL. I can’t remember if this will “just work” using
 directories named gdal-data, gdal-plugins, or if it is necessary for the
 _gdal_dll_loader.pyd to call some GDAL functions to make it happen.




I guess this could also be set form a python script (probably from
loader.py)


Best regards,

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

Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

2011-01-06 Thread Joaquim Luis


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 to distribute the GDAL binaries using an installer that 
adhered to

the best practices on Windows.


I *think* we're heading for a consensus to do that, but not many 
people have been on this thread.


Hi,

I have been following this with attention and sometimes I thought I had 
something to say but than it has many python specific issues, which I'm 
not versed at all. My experience with other installers is GMT  Mirone.  
Here I simply put the gdal dll and ALL its dependencies (determined by 
careful Dependency Walker analysis) in the same directory as the other 
exes. Since this must be in the PATH, the gdal package goes along. But 
this solution normally doesn't care about the gdal exes.
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 seen that happen 
many times). The GMT  Mirone installs propose as default a C:\programs 
diectory. Let me remember that Program Files is not a unique name. For 
example in Portugues Win versions it is called O Meus Programas 
(Horror). Remember also that MS used to have Documents and Settings 
but now on Win7 it's only Users.



Incidentally, Windows does support both symbolic and hard links, 
although it

is not widely known, and I'm not sure I'd recommend their use for this
particular problem.


I've heard that, but never seen it done.


It works pretty well, the command is mklink and works much like on *nix 
BUT exists only on Vista and Win7.


Time to time, it has been raised also the hypothesis to put the dlls in 
windowes\system32. PLEASE, PLEASE don't even think on that. It's the 
easiest way of making the worst dll-hell. I learned that after spending 
many hours trying to understand why GDAL was not working in the 
classroom computers. It turned out to be an very old zlib1.dll put there 
by ArcS*



Joaquim


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

RE: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

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 quick compromise would be for
Tamas's build system to produce a .zip that would have everything in a
suitable directory structure and for wiki page to instruct the user just
unzip this to \Program Files\GDAL\

2. GDAL Python bindings installation program. This could be easily created
using the standard Python distutils stuff I've been mentioning, and would
install the bindings to the normal Python place. The bindings would ideally
be modified to check for and explicitly load libraries from \Program
Files\GDAL\... This would eliminate the need to modify the PATH variable.

A Windows Python programmer would just install those two things and they're
done. No questions about what goes where. No need to set any environment
variables.

People like me who embed GDAL in their own application would now have a new
alternative: rather than including GDAL libraries we could instruct the user
to download an official GDAL build and install it, and then just use it from
there.

What do you think?

Jason

-Original Message-
From: Frank Warmerdam [mailto:warmer...@pobox.com] 
Sent: Thursday, January 06, 2011 5:49 PM
To: Jason Roberts
Cc: gdal-dev@lists.osgeo.org
Subject: Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

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 separately from the GDAL Python bindings. The libraries are
 installed to \Program Files as you describe and the Python bindings are
 installed in the standard Python location. A Windows Python programmer
 wanting to use GDAL would perform two installs: one for the GDAL
libraries,
 the other for the bindings.

 2. The GDAL Python bindings include a private copy of the GDAL libraries
 (with no executable programs). These are installed to a private
subdirectory
 with the bindings. A Windows Python programmer wanting to use GDAL only
 needs to perform one install: the bindings.

 #1 is essentially how things are done now, just not following Windows best
 practices (not using \Program files) and without any automation to ease
the
 process (no regularly maintained installer for the Python bindings).

 I was proposing #2, basically under the argument that a Windows Python
 programmer who needs to use GDAL will rarely ever need to use GDAL for
some
 other purpose, and therefore not want to install and think about a
separate
 installation of the GDAL libraries themselves. But if you don't believe
 that, or think it is important that the libraries remain distinct from the
 bindings in this scenario for some other reason, then we would appreciate
 your opinion.

Jason,

I don't have a strong position on this, but I would note that beyond
real Python programmers wanting to use the bindings, they are also needed
just to run the python commandline utilities (such as rgb2pct.py).  So
there is definately a large body of folks who would benefit from having
working python for the python utilities, and the regular commandline
executables.

Another benefit of even Python using GDAL from a standard location is
things like format plugins could be easily handled in one place.

Actually, the more I think about it, the more I prefer even the Python
bindings to use the GDAL under \Program Files\GDAL.

If the Pythonistas really want to have their own copy of GDAL then
we really don't need to have this conversation.  They can do their
own thing, in their own place and there is no need for meaningful
cooperation with the core project.

Best regards,
-- 
---+
--
I set the clouds in motion - turn up   | Frank Warmerdam,
warmer...@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush| Geospatial Programmer for Rent


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

RE: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

 

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 private copy of the GDAL DLLs used just by
those bindings. On Python 2.6 and later, we probably want bdist
--formats=msi to produce a .msi file rather than a .exe, because Windows
likes .msi files much better than .exes for security purposes. IIRC, Python
2.5 and earlier do not have the msi option.

 

This can be done fairly easily. Does this mean we would require each build
for multiple python versions?

 

Yes, it would mean that. One build for Python 2.5, one for 2.6, one for 2.7,
etc. This is how it is typically done.

 

 

2.Modify release--dev\gdal\swig\python\setup.py to include the GDAL
DLLs and data files in the data_files list that is passed to the setup()
function. Make sure it is only done for Windows (Python code can check
that). The goal is to have the installation program create the following
kind of installation:

 

Hmmm. I'm keen to avoid any local modifications in the compiled files
throughout the build system. Do we have some option to load this infromation
from an external file (which is probably loaded by setup.py if exists)? Or I
must write a custom setup2.py containing this customization.



I was not saying that setup.py be forked and a special copy exist for
windows. I was saying that setup.py should internally check whether it was
being executed on Windows (check Python's sys.platform variable), and then
perform special logic. But this may be moot because it sounded like Frank
was not keen on my suggestion of enclosing a private copy of the GDAL DLLs
with the Python bindings. If we avoid my suggestion then we are left with
the idea of putting them in \Program Files\GDAL. In that case, we would not
need to modify setup.py for this purpose. 


 

3.Introduce a new file
release--dev\gdal\swig\python\extensions\_gdal_dll_loader.cpp. This file
will call GetDllDirectory to find the current DLL directory setting, call
SetDllDirectory to C:\PythonXX\Lib\site-packages\osgeo\bin (or wherever the
Python instance is installed), call LoadLibrary(gdal17.dll), and call
SetDllDirectory back to what it was before. There are more details to
consider. For example, we might want to have it call LoadLibrary first to
see if it can load the GDAL DLL from the PATH, allowing the user to use
their own GDAL DLLs without having to overwrite the ones in the Python
directory. Or we might not want to do that, with the idea that the GDAL
Python bindings must be tightly coupled to a particular version of GDAL's
DLLs.

 

That seems to be quite complicated, not sure it that's working for those
libraries using LoadLibrary binding at run time. Wouldn't that be better
getting back to add the location to the PATH of the process in a loader.py
(using SetEnvironmentVariable).

I do not think it would be good to tamper with setting the PATH. I am not
certain, but I think Python's environment handler may call _putenv rather
than SetEnvironmentVariable, or something like that, which can cause some
problems. It might be better just to use SetDllDirectory. Also, as Chris
pointed out, the Python ctypes module can be used to call win32 APIs. This
would eliminate the need for a new _gdal_dll_loader module. Instead, the
try/except block that I described below would just call win32 directly via
ctypes. It could do the necessary SetDllDirectory/LoadLibrary/etc itself.

 

 

5.Modify gdal.py, osr.py, and so on to do something like this:

 

import sys

if sys.platform == 'win32': # TODO: add check for Windows x64 as well

try:

import osgeo._gdal_dll_loader  # As part of this, Python
will call an init function inside. That function will do the
SetDllDirectory, etc.

except:

pass


Such changes can be done in the SWIG interface files easily.

 

Sounds good to me.


 

 

6.Do whatever is necessary to ensure the GDAL_DATA etc are properly set
up inside GDAL. I can't remember if this will just work using directories
named gdal-data, gdal-plugins, or if it is necessary for the
_gdal_dll_loader.pyd to call some GDAL functions to make it happen.

 


I guess this could also be set form a python script (probably from
loader.py)

If we follow the \Program Files\GDAL suggestion, then I further suggest that
GDAL itself be modified to use that location as the default for GDAL_DATA,
GDAL_PLUGINS, etc. That way the user does not have to set ANY environment
variables for GDAL to work. That would be a major plus because, frankly,
Windows users rarely have to set environment variables.





Best regards,

Tamas

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

Re: [gdal-dev] FWTools and GDAL 1.7.0

2011-01-06 Thread Jürgen E . Fischer

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 it defaults to /usr/share/gdal (or /usr/local/share/gdal) on
 linux.

Just one remark (I don't follow all the python stuff ;)):

The program files directory is usually localized so %PROGRAMFILES% should be
used and the drive letter isn't necessarily C.

Windows 7 might actually be different - perhaps they now even now use symlinks
to point a localized path to a hidden Program Files.


Jürgen 

-- 
Jürgen E. Fischer norBIT GmbH   Tel. +49-4931-918175-20
Dipl.-Inf. (FH)   Rheinstraße 13Fax. +49-4931-918175-50
Software Engineer D-26506 Norden   http://www.norbit.de

-- 
norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
Rheinstrasse 13, 26506 Norden
GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502

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

Re: [gdal-dev] Combining TIFFs w/ different color palettes

2011-01-06 Thread Michael Koehmstedt

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 at 2:12 PM, Frank Warmerdam warmer...@pobox.com wrote:

 On 11-01-05 04:06 PM, MyKillK wrote:


 Hello all,

 My question is simple. Is it possible to combine two GeoTIFFs, each with
 its
 own unique color palette into a single image that is properly color
 mapped?
 Each image only has 16 colors so I feel like it should be possible to copy
 Image #1's color table straight into indexes 0-15 and then remap Image
 #2's
 color table to indexes 16-31. For the life of I can't figure out how this
 can be done, it always wants to use Image #1's color table alone in the
 merged TIFF.


 Michael,

 I am not aware of any existing GDAL application to do this.  You  could
 use pct2rgb.py on each image, merge the RGB images, and then use rgb2pct.py
 to produce a paletted image from the result that would likely have 32
 colors.

 Best regards,
 --

 ---+--
 I set the clouds in motion - turn up   | Frank Warmerdam,
 warmer...@pobox.com
 light and sound - activate the windows | 
 http://pobox.com/~warmerdamhttp://pobox.com/%7Ewarmerdam
 and watch the world go round - Rush| Geospatial Programmer for Rent


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




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

Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0


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 seen that happen
many times).


True, I'm still quite amazed how MS has ignored the command line for 
years. Sure, we geeks are a small fraction of Windows users, but a small 
fraction of a huge userbase is still a LOT.


Perhaps that's why the standard place for Python is NOT in Program Files

That being said, Program Files does seem to work fine for me most of 
the time.



Time to time, it has been raised also the hypothesis to put the dlls in
windowes\system32. PLEASE, PLEASE don't even think on that.


That, we do have a consensus on!

By the way, isn't there some new stuff about side by side installs or 
something -- that's supposed to help dll hell?


On 1/6/11 2:49 PM, Frank Warmerdam wrote:

I don't have a strong position on this, but I would note that beyond
real Python programmers wanting to use the bindings, they are also needed
just to run the python commandline utilities (such as rgb2pct.py). So
there is definately a large body of folks who would benefit from having
working python for the python utilities, and the regular commandline
executables.


yup. Also, I use gdal command line utilities and python bindings. It's 
actually really nice to know that they are using the exact same 
versions, as I can test stuff with the utilities and compare results.



Another benefit of even Python using GDAL from a standard location is
things like format plugins could be easily handled in one place.


Yes, and then Perl, and who knows what else can share the same install.


Actually, the more I think about it, the more I prefer even the Python
bindings to use the GDAL under \Program Files\GDAL.


+1 from me, too.

I winder where Howard is? But anyway, the gdal PyPi site (which I think 
Howard wrote/maintained) says:



Windows

You will need the following items to complete an install of the GDAL 
Python bindings on Windows:


* GDAL Windows Binaries The basic install requires the 
gdalwin32exe###.zip (### is the version number). Other files you see in 
the directory are for various optional plugins and development 
headers/include files. After downloading the zip file, extract it to the 
directory of your choosing.



** the problem here is that that zip file hasn'tbeen maintained for a while.


* GDAL Python Bindings available at the Python Cheeseshop. An 
executable installer is available for both Python 2.4 or 2.5 or as a 
Python egg.


** this is pretty much what Jason is suggeting - a binary egg dependent 
on a certain gdal install.



As explained in the README_EXE.txt file, after unzipping the GDAL 
binaries you will need to modify your system path and variables. If 
you're not sure how to do this, read the Microsoft KnowledgeBase doc


   1. Add the installation directory bin folder to your system PATH, 
remember to put a semicolon in front of it before you add to the 
existing path.


  C:\gdalwin32-1.7\bin

   2. Create a new user or system variable with the data folder from 
your installation.


  Name : GDAL_DATA
  Path : C:\gdalwin32-1.7\data


It would be nice to remove these steps. Again, I think Jason's got some 
good ideas for that.



By the way -- it is fairly common for python packages to include command 
line utilities. There are tools in distutils and setuptools to support 
that -- they get installed in a Scripts directory in the Python install. 
Should the Python-based gdal utilities go there?


-Chris





--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

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

Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

2011-01-06 Thread Joaquim Luis



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 many people don't know it.


By the way, isn't there some new stuff about side by side installs 
or something -- that's supposed to help dll hell?


I think you are referring to the manifests but here also MS has 
changed their mind (aleluia). VC2010 doesn't have them anymore which IMO 
is a compelling reason to use this compiler whenever possible.


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

RE: [gdal-dev] FWTools and GDAL 1.7.0

 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, much maligned User Account Control (UAC) system that improved
security but resulted in numerous popups from the o/s asking for permission
to do things. This was improved in Windows 7 but that virtualization thing
still exists and causes pain for app developers.

It can be circumvented by using the Run As Administrator option when
installing something (you must do it even when your account is, in fact, an
administrator). Installation programs can request a certain level of
privilege that makes it unnecessary for the user to do it.

For more on this, search for Windows virtual store (with no quotes).

The consequence for GDAL is that if GDAL is going to develop an installer
for the GDAL libraries and utilities, it would be best if that installer
technology was aware of these issues. For example, creating a .msi installer
with Microsoft Visual Studio is likely to give good success, while
hand-crafting an installation .exe yourself is likely to not work as
intended.

Jason

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

Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0


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
scripts) to \Program Files\GDAL\... Perhaps a quick compromise would be for
Tamas's build system to produce a .zip that would have everything in a
suitable directory structure and for wiki page to instruct the user just
unzip this to \Program Files\GDAL\

...

What do you think?


Jason,

I'm supportive, but not necessarily willing to take it as action item
for myself.

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.

One question not discussed is whether GDAL should be minimalist or
maximalist.  That is, do we want to include as many formats as possible
despite the fact that it drags in lots of supporting libraries?  If we
just use whatever decision OSGeo4W uses then we will have a fairly
maximalist solution which is ok I suppose but might make integration of
the resulting GDAL in other complex applications messy.

I would like to suggest production of such an installer be done in such
a way that the generating scripts live in SVN somewhere, and with
instructions for the process in the wiki so it isn't all tied to one
person (as FWTools was).

Man, I'm really tempted to leap into this myself but I have so many
other outstanding items right now.  I am willing to assist in an
effort by a small (2-3 people?) team.

Best regards,
--
---+--
I set the clouds in motion - turn up   | Frank Warmerdam, warmer...@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush| Geospatial Programmer for Rent

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

Re: [gdal-dev] gdal_polygonize.py binding error

2011-01-06 Thread Chaitanya kumar CH

 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 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
 an older version of the next gen bindings.

 I found the previous threads on this issue, but could not find an answer.

 Any idea? Thanks

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




-- 
Best regards,
Chaitanya kumar CH.
/tʃaɪθənjə/ /kʊmɑr/
+91-9494447584
17.2416N 80.1426E
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Trouble handling HFA histogram (.img file)