Quantcast

[gdal-dev] FWTools and GDAL 1.7.0

classic Classic list List threaded Threaded
71 messages Options
1234
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[gdal-dev] FWTools and GDAL 1.7.0

Kyle Shannon
Hello all,
I was working on #3890 and the ticket issuer reported gdalinfo version as:


gdalinfo --version

GDAL 1.7.0b2, FWTools 2.4.7, released 2010/01/19

I downloaded FWTools 2.4.7 for windows and verified the version.  I may be confused with the GDAL version, but assuming b2 is beta 2, wasn't this version was retracted?  Does anyone know if beta 2 was released before the commit that caused the HFA issue?  Just wondering if the FWTools should be upgraded to 1.7.x.  Thanks.

kss


# ============================
Kyle Shannon
Physical Science Technician
RMRS Fire Sciences Lab
Fire, Fuels & Smoke - RWU 4405
5775 Highway 10 W.
Missoula, MT 59808
(406)829-6954
[hidden email]
# ============================

_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FWTools and GDAL 1.7.0

Frank Warmerdam
On 11-01-03 06:40 PM, Kyle Shannon wrote:

> Hello all,
> I was working on #3890 and the ticket issuer reported gdalinfo version as:
>
>
>     gdalinfo --version
>
>     GDAL 1.7.0b2, FWTools 2.4.7, released 2010/01/19
>
> I downloaded FWTools 2.4.7 for windows and verified the version.  I may be
> confused with the GDAL version, but assuming b2 is beta 2, wasn't this version
> was retracted?  Does anyone know if beta 2 was released before the commit that
> caused the HFA issue?  Just wondering if the FWTools should be upgraded to
> 1.7.x.  Thanks.

Kyle,

FWTools was built at random intervals from GDAL trunk.  It appears that
last release was around the 1.7 release point.  I haven't really tried to
keep producing new FWTools releases over the last year and I'm not sure
I've retained enough of the materials for it to produce a new one.  I
might revisit this at some point.  In the meantime I mostly try to point
people to OSGeo4W now.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Livneh Yehiyam
In reply to this post by Kyle Shannon

Hi Frank
I personally will be happy to see FWTOOLS updated at least for major Gdal releases. I find it to be a much simpler way to distribute Gdal to my end users.
I agree that OSGeo4W is more complete, but I think that for many users the simplicity of FWTOOLS wins.

Thanks
Yehiyam Livneh

From: "Frank Warmerdam"
Subject: Re: [gdal-dev] FWTools and GDAL 1.7.0
Date: 04 ינואר 2011 05:11

On 11-01-03 06:40 PM, Kyle Shannon wrote:
> Hello all,
> I was working on #3890 and the ticket issuer reported gdalinfo version as:
>
>
> gdalinfo --version
>
> GDAL 1.7.0b2, FWTools 2.4.7, released 2010/01/19
>
> I downloaded FWTools 2.4.7 for windows and verified the version. I may be
> confused with the GDAL version, but assuming b2 is beta 2, wasn't this version
> was retracted? Does anyone know if beta 2 was released before the commit that
> caused the HFA issue? Just wondering if the FWTools should be upgraded to
> 1.7.x. Thanks.

Kyle,

FWTools was built at random intervals from GDAL trunk. It appears that
last release was around the 1.7 release point. I haven't really tried to
keep producing new FWTools releases over the last year and I'm not sure
I've retained enough of the materials for it to produce a new one. I
might revisit this at some point. In the meantime I mostly try to point
people to OSGeo4W now.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, [hidden email]
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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev



This message (including any attachments) issued by RAFAEL- ADVANCED DEFENSE SYSTEMS LTD. (hereinafter "RAFAEL") contains confidential information intended for a specific individual and purpose, may constitute information that is privileged or confidential or otherwise protected from disclosure. If you are not the intended recipient, you should contact us immediately and thereafter delete this message from your system. You are hereby notified that any disclosure, copying, dissemination, distribution or forwarding of this message, or the taking of any action based on it, is strictly prohibited. If you have received this e-mail in error, please notify us immediately by e-mail mailto:[hidden email] and completely delete or destroy any and all electronic or other copies of the original message and any attachments thereof.

_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

iomeneandrei
Hi all,
for what is worth also for me the simplicity of FWTOOLS wins.

Best regards,

andrea
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Tamas Szekeres
In reply to this post by Livneh Yehiyam


2011/1/5 Livneh Yehiyam <[hidden email]>

I personally will be happy to see FWTOOLS updated at least for major Gdal releases. I find it to be a much simpler way to distribute Gdal to my end users.
I agree that OSGeo4W is more complete, but I think that for many users the simplicity of FWTOOLS wins.



What do you mean by 'simplicity'? Is this related to the installer which is simpler to use? In this regard would it be much simpler to pick up the required files and distribute that to the end used in a single .zip package?

As far as I know FWTools is based on the development version while OSGeo4W and ms4w are mostly compiled against the stable branches (OSGeo4W may also contain -dev packages though). This may strongly define which one is more suitable for a particual use case. A development version contains the recent features up to the time when the package has been built, but it may also contain a high number of bugs temporarily, which should be fixed until the next stable release.

Best regards,

Tamas



_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Chris Barker
In reply to this post by iomeneandrei
On 1/5/11 3:41 AM, iomeneandrei wrote:
> for what is worth also for me the simplicity of FWTOOLS wins.

FWTools is nice, but I think with OSgeo4win, not really important.

However, for simplicity, a one-click installer for just GDAL/OGR for
Windows, complete with command line tools and ready for use with the
python bindings (and others language bindings?) would be great.

I've found it painful to find appropriate Windows executables every time
I've need to upgrade to the latest.

-Chris


--
Christopher Barker, Ph.D.
Oceanographer

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

[hidden email]
_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: FWTools and GDAL 1.7.0

Konstantin Baumann
And add x64 support to that list, too...

Kosta

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Christopher Barker
Sent: Wednesday, January 05, 2011 5:49 PM
To: [hidden email]
Subject: Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

On 1/5/11 3:41 AM, iomeneandrei wrote:
> for what is worth also for me the simplicity of FWTOOLS wins.

FWTools is nice, but I think with OSgeo4win, not really important.

However, for simplicity, a one-click installer for just GDAL/OGR for
Windows, complete with command line tools and ready for use with the
python bindings (and others language bindings?) would be great.

I've found it painful to find appropriate Windows executables every time
I've need to upgrade to the latest.

-Chris


--
Christopher Barker, Ph.D.
Oceanographer

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

[hidden email]
_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev

_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FWTools and GDAL 1.7.0

Jürgen E. Fischer
In reply to this post by Chris Barker
Hi Christopher,

On Wed, 05. Jan 2011 at 08:48:48 -0800, Christopher Barker wrote:
> However, for simplicity, a one-click installer for just GDAL/OGR for  
> Windows, complete with command line tools and ready for use with the  
> python bindings (and others language bindings?) would be great.

The QGIS standalone NSIS installer is made from OSGeo4W binaries with
creatensis.pl[1].

It starts from the qgis-full/qgis-dev package and collects the dependencies
from OSGeo4W, extracts them and repackages them to a single NSIS installer.

Adapting it to do the same for gdal17 shouldn't be too difficult.


Jürgen


[1] http://trac.osgeo.org/qgis/browser/trunk/qgis/ms-windows/osgeo4w/creatensis.pl

--
Jürgen E. Fischer         norBIT GmbH               Tel. +49-4931-918175-20
Dipl.-Inf. (FH)           Rheinstraße 13            Fax. +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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Tamas Szekeres
In reply to this post by Chris Barker


2011/1/5 Christopher Barker <[hidden email]>
However, for simplicity, a one-click installer for just GDAL/OGR for Windows, complete with command line tools and ready for use with the python bindings (and others language bindings?) would be great.
 
I've found it painful to find appropriate Windows executables every time I've need to upgrade to the latest.


Supporting multiple vesions (development/stable branches/releases, x32/x64, multiple MSVC CRT dependencies) is quite a difficult task in a single installer. With regards to the development version it would also be reasonable to provide a build quite frequently to be in sync with the latest changes in trunk. These are the main reasons I've originally set up http://vbkto.dyndns.org/sdk/ to provide most of the resonable combinations as daily built packages.

I also wanted to include these files in an installer (or multiple installers) but at the moment I don't see the real benefit of this over extracting a single zip package, since these libraries don't require significant preparation (like regkey entries) during the deployment. Any further consideration in this topic would be helpful, as I may have missed something that would also be important by a windows user.


Best regards,

Tamas




_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FWTools and GDAL 1.7.0

Kyle Shannon
In reply to this post by Jürgen E. Fischer
I guess my worry was if someone uses the FWTools libs to link against.  1.7.0 had that serious bug for writing HFA files:

ALERT: The GDAL/OGR 1.7.0 release has been discovered to have a serious bug which results in all Erdas Imagine files (HFA driver) being generated in a way that is unreadable by non-GDAL software. Due to this bug, the GDAL/OGR project has retracted the 1.7.0 release, and has issued it's replacement with the 1.7.1 bug fix release. See http://trac.osgeo.org/gdal/ticket/3382 for details.

If it was worth retracting the release and pushing 1.7.1 out, maybe we shouldn't have it available in binary form either.  Maybe I am missing something.

kss

# ============================
Kyle Shannon
Physical Science Technician
RMRS Fire Sciences Lab
Fire, Fuels & Smoke - RWU 4405
5775 Highway 10 W.
Missoula, MT 59808
(406)829-6954
[hidden email]
# ============================


On Wed, Jan 5, 2011 at 10:42, Jürgen E. <[hidden email]> wrote:
Hi Christopher,

On Wed, 05. Jan 2011 at 08:48:48 -0800, Christopher Barker wrote:
> However, for simplicity, a one-click installer for just GDAL/OGR for
> Windows, complete with command line tools and ready for use with the
> python bindings (and others language bindings?) would be great.

The QGIS standalone NSIS installer is made from OSGeo4W binaries with
creatensis.pl[1].

It starts from the qgis-full/qgis-dev package and collects the dependencies
from OSGeo4W, extracts them and repackages them to a single NSIS installer.

Adapting it to do the same for gdal17 shouldn't be too difficult.


Jürgen


[1] http://trac.osgeo.org/qgis/browser/trunk/qgis/ms-windows/osgeo4w/creatensis.pl

--
Jürgen E. Fischer         norBIT GmbH               Tel. +49-4931-918175-20
Dipl.-Inf. (FH)           Rheinstraße 13            Fax. +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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev


_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Daniel Morissette
In reply to this post by Tamas Szekeres
On 11-01-05 12:44 PM, Tamas Szekeres wrote:
>
> I also wanted to include these files in an installer (or multiple
> installers) but at the moment I don't see the real benefit of this over
> extracting a single zip package, since these libraries don't require
> significant preparation (like regkey entries) during the deployment. Any
> further consideration in this topic would be helpful, as I may have
> missed something that would also be important by a windows user.
>

Tamas,

I agree with you, but it seems that an [OK] button (even if it doesn't
do anything) makes Windows users feel so much better.  :)

Daniel
--
Daniel Morissette
http://www.mapgears.com/
_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Chris Barker
In reply to this post by Tamas Szekeres
On 1/5/11 9:44 AM, Tamas Szekeres wrote:

> Supporting multiple vesions (development/stable branches/releases,
> x32/x64, multiple MSVC CRT dependencies) is quite a difficult task in a
> single installer.

yes, a Major pain. I don't know that we need a single installer, but
there is a lot to support.

> These are the main reasons I've originally set
> up http://vbkto.dyndns.org/sdk/ to provide most of the resonable
> combinations as daily built packages.

Actually, that is a GREAT resource. At the moment, I can't remember why
it's been difficult for me to use, but a few thoughts:

First -- I use GDAL from Python and with the command line tools, so
that's my perspective.

1) It would be nice to have binaries for the latest release front and
center at the main GDAL site -- having to poke around to find Tamas's
site is not a big deal, but not always obvious.

2) A standard install location would be good. As I've messed with this
each time, I never know where stuff should go -- maybe installers would
help with that

3) If there is a standard install location, then "easy_install gdal" (or
setup.py build, or...) could work for the python bindings.

Another option is to have a binary installer for the python bindings
that includes gdal and the gdal utilities -- that would be great for
users like me, but I don't know how common my use case is. In that case,
you'd want to support a few recent pythons versions, the python.org
binaries: 2.6, 2.7, 3.1 (maybe 2.5 too).

One of the tricks here is which numpy to support, etc. numpy has been
pretty good with binary compatibility lately (except for one mistake
recently that was corrected)

However, I DON'T want gdal to give me  Python -- I use Python for too
many other things for that.

4) it might be nice if the install location for the utilities got put on
the user's PATH -- I don't know how hard that is in an installer --
Windows really sucks in that regard.

> I also wanted to include these files in an installer (or multiple
> installers) but at the moment I don't see the real benefit of this over
> extracting a single zip package, since these libraries don't require
> significant preparation (like regkey entries) during the deployment.

An installer would better enforce a standard install location. You could
also have a custom DOS box with a menu entry that set up the environment
for the command line tools (maybe only PATH?), provide an uninstaller,
and of course, give the Windows users a nice warm and fuzzy feeling.

With regard to Python, an installer could see what Python the user has
and install the bindings for that version. Not that I have any idea how
to build that!

Inno Setup is a very nice free installer, by the way.

-Chris



--
Christopher Barker, Ph.D.
Oceanographer

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

[hidden email]
_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Tamas Szekeres


2011/1/5 Christopher Barker <[hidden email]>

1) It would be nice to have binaries for the latest release front and center at the main GDAL site -- having to poke around to find Tamas's site is not a big deal, but not always obvious.


Chris,

With regards to the comment above, while I'm not sure about the objectives but I don't think the GDAL site would intend to be a hosting provider of various binary packages, the most reasonable thing is to put the references pointing the user to the correct locations which has already been done, see the "Downloads" section at http://www.gdal.org/

2) A standard install location would be good. As I've messed with this each time, I never know where stuff should go -- maybe installers would help with that


This doesn't seem to be decisive requirement to me. We may also create a definite location in the hard drive to host such files (which can be remembered later). Or some other folks may prefer installing these files along with their applications or keep such files in separate - project specific - directories. We may also have a requirement to deploy and run these applications from portable locations (ie. from CD or a flash drive). Another issue of an installer may be due to a single product key along with the setup which would prevent from installing multiple versions side by side in the same environment.
 
3) If there is a standard install location, then "easy_install gdal" (or setup.py build, or...) could work for the python bindings.


I admit I don't have enough knowledge about the 'magic' tricks related to python-ish way installing applications. I expect that most 'magic' are implemented by copying the files at certain locations, setting some environment variables or regkey entries. However I might also consider running a custom application with gdal not necessarily be the responsibility of a GDAL package. You might also want to install python from a separate installer (either ActivePython, python.org whatever) and run the application direcly from a command prompt where the environments are set to run the gdal applications properly. Most of these packages provide the required .bat file to setup the environment this way.
 
Another option is to have a binary installer for the python bindings that includes gdal and the gdal utilities -- that would be great for users like me, but I don't know how common my use case is. In that case, you'd want to support a few recent pythons versions, the python.org binaries: 2.6, 2.7, 3.1 (maybe 2.5 too).


I don't know much about this either. This may however be doable for those guys who know the Python packaging approach well enough. I don't think eiter of the packages referred at http://trac.osgeo.org/gdal/wiki/DownloadingGdalBinaries would support this feature though.

 
One of the tricks here is which numpy to support, etc. numpy has been pretty good with binary compatibility lately (except for one mistake recently that was corrected)


Not sure how this be related to a GDAL binary distribution, as far as I remember numpy can be installed to the Python deployment directly.

 
However, I DON'T want gdal to give me  Python -- I use Python for too many other things for that.


Yes, adding more runtime environments to a simple GDAL package makes it more heavy weighted. Would also be reasonable to include the Perl environment or a .NET framework installer for example to make it more complete. However, in many cases it's more reasonable to let the application (using the GDAL binaries) decide how to make a proper installer to run their application smoothly.

 
4) it might be nice if the install location for the utilities got put on the user's PATH -- I don't know how hard that is in an installer -- Windows really sucks in that regard.


I don't think it would be beneficial in most cases. This could easily break other applications (using the dll-s with the same names) to fail unexpectedly. I would prefer to keep the applications isolated (setting the environment variables specifically to the process and not the user/system) as much as possible.

An installer would better enforce a standard install location. You could also have a custom DOS box with a menu entry that set up the environment for the command line tools (maybe only PATH?), provide an uninstaller, and of course, give the Windows users a nice warm and fuzzy feeling.


The 'nice warm and fuzzy feeling' is a good objective indeed, setting up an entry on the start menu instead of a running the batch file directly may also be an advantage. While I'm not sure starting a DOS prompt would validate an installer by it's own, I can see this requirement to be valid in most cases.

 
With regard to Python, an installer could see what Python the user has and install the bindings for that version. Not that I have any idea how to build that!


Agreed, but I have no idea either.
 
Inno Setup is a very nice free installer, by the way.


I would also add Wix to the list.
 

Best regards,

Tamas



_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Tamas Szekeres
In reply to this post by Daniel Morissette


2011/1/5 Daniel Morissette <[hidden email]>
I agree with you, but it seems that an [OK] button (even if it doesn't do anything) makes Windows users feel so much better.  :)


Daniel,

:-)   And sometimes we wonder what a heck is being done behind an OK button on Windows which takes so long (or lasts forever ;-)

Best regards,

Tamas



_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Chris Barker
In reply to this post by Tamas Szekeres
It may well be that GDAL has too many different use cases to even have a
"standard" install, but...

On 1/5/11 1:37 PM, Tamas Szekeres wrote:
> 2011/1/5 Christopher Barker <[hidden email]
>     1) It would be nice to have binaries for the latest release front
>     and center at the main GDAL site -- having to poke around to find
>     Tamas's site is not a big deal, but not always obvious.

> With regards to the comment above, while I'm not sure about the
> objectives but I don't think the GDAL site would intend to be a hosting
> provider of various binary packages,

Well, many (most?) open source packages have "official" binaries hosted
on its site. It's pretty common to go to a project's site and expect to
find a way to download binaries right then and there.

>     2) A standard install location would be good. As I've messed with
>     this each time, I never know where stuff should go -- maybe
>     installers would help with that
>
> This doesn't seem to be decisive requirement to me.

It's not a strong requirement, but standard defaults do make things
easier for everyone.

> Or some other folks may prefer installing these files
> along with their applications or keep such files in separate - project
> specific - directories.

Well, users should certainly be able to do something custom if they
want. This is all about use-cases -- if you are building a custom app
linked against GDAL, then you probably want to control where you put things.

However, if you are interested in the command line tools, and using GDAL
via Python or Perl or ??, then it makes it easier to have a standard
location.

 > Another issue of an installer may be due to a single product key
> along with the setup which would prevent from installing multiple
> versions side by side in the same environment.

Surely there are ways to accommodate that? though "dll hell" is in the
lexicon for a reason!

>     3) If there is a standard install location, then "easy_install gdal"
>     (or setup.py build, or...) could work for the python bindings.

> I admit I don't have enough knowledge about the 'magic' tricks related
> to python-ish way installing applications.

That's the thing -- there is no magic here. If you are building a python
extension, you need to tell the build system where its dependencies lie.
If you are installing a pre-built python extension, then the
dependencies need to be in a known place (or maybe on the right PATHS --
Windows is pretty ugly this way). Which is why a "standard" install
location would be a good idea.

> I might also consider
> running a custom application with gdal not necessarily be the
> responsibility of a GDAL package.

well, that depends on whether you consider Python bindings a "custom
application". In any case, I think it helps third party packages to have
standard default install locations.

Oh for *nix -- this would be easier if we just could just put stuff in
/usr/local/...

> You might also want to install python
> from a separate installer (either ActivePython, python.org
> <http://python.org> whatever)

True -- but it is very much a standard for third party packages to
provide binaries for the python.org python build. Again, I'm not
suggesting that folks should be prevented (or even discouraged) from
doing various sorts of custom installs, just that there should be
defaults, so that it's clear an easy for a newbie to know what to to to
get things to "just work".

>     Another option is to have a binary installer for the python bindings
>     that includes gdal and the gdal utilities -- that would be great for
>     users like me, but I don't know how common my use case is. In that
>     case, you'd want to support a few recent pythons versions, the
>     python.org <http://python.org> binaries: 2.6, 2.7, 3.1 (maybe 2.5 too).
>
> I don't know much about this either. This may however be doable for
> those guys who know the Python packaging approach well enough.

It's not that hard (at lest once GDAL is built), but it is work.

> I don't
> think eiter of the packages referred at
> http://trac.osgeo.org/gdal/wiki/DownloadingGdalBinaries would support
> this feature though.

Agreed -- that's my point!

>     One of the tricks here is which numpy to support, etc. numpy has
>     been pretty good with binary compatibility lately (except for one
>     mistake recently that was corrected)
>
>
> Not sure how this be related to a GDAL binary distribution, as far as I
> remember numpy can be installed to the Python deployment directly.

yes, but the Python bindings are built against a particular numpy.
That's OK for version so numpy that are binary compatible, but it
potentially fragile. Note that with the new extended buffer interface,
it should be possible to build GDAL with full numpy support, but not
have to compile against numpy. But I think that's only good for 2.7 and 3.*

>     However, I DON'T want gdal to give me  Python -- I use Python for
>     too many other things for that.
>
> Yes, adding more runtime environments to a simple GDAL package makes it
> more heavy weighted.

right -- I think we're talking about lightweight, GDAL only packages here.

> in many cases it's more reasonable to let the
> application (using the GDAL binaries) decide how to make a proper
> installer to run their application smoothly.

Hmm -- that's the trick -- are the Python (and Perl, and...) bindings an
"application (using the GDAL binaries)", or are they part of GDAL? In
many cases, the python bindings are a completely separate project from
the library they bind, so it's a clear distinction, but not in this case.

This makes me think, though -- maybe I should think about this
differently -- I'm trying to get the GDAL command line tools, and the
Python bindings. Maybe I should simply consider those as separate issues
altogether -- they don't need to share the same binaries. In that case,
maybe the python bindings should be statically linked, or deliver the
dlls with the bindings, and be available as an entirely stand-alone
installer.

Indeed, having said that, I'm looking around and see that someone is
doing that:

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

very nice -- I'll have to give those a test.

>     4) it might be nice if the install location for the utilities got
>     put on the user's PATH -- I don't know how hard that is in an
>     installer -- Windows really sucks in that regard.
>
> I don't think it would be beneficial in most cases. This could easily
> break other applications (using the dll-s with the same names) to fail
> unexpectedly.

I was thinking the executable utilities, not the dlls, but Windows does
conflate those PATHs, doesn't it? (sigh)

Anyway, next time I update my Windows system (which I'll need to do
soon), I'll think about these issues some more.

A couple notes on:

http://trac.osgeo.org/gdal/wiki/DownloadingGdalBinaries

Looking again at that page, I'm reminded why this has seemed painful.
Under the Windows section:

"""
Minimalist windows executables are available at:

      http://download.osgeo.org/gdal/win32/1.6/gdalwin32exe160.zip
"""

these are out of date -- if they are going to exist, they really should
be updated. They are hosted by osgeo, and thus look "official".

"""
Other plugins will be added in the same location (such as Oracle/OCI):

      http://download.osgeo.org/gdal/win32/
"""

How well maintained is this set?

"""
A more featureful set of windows binaries, including python, proj and c#
support is available as part of the  FWTools package.
"""

no longer kept up to date, either.

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


"""
Tamas Szekeres maintains a complete set of Win32 and Win64 binary
packages (compiled with VC2003/VC2005/VC2008) available at the following
location.

      http://vbkto.dyndns.org/sdk/
"""

These are fabulous -- maybe they should be first on the list? Though
there is a LOT there -- you need to know what you are looking for.

"""
  OSGeo4W is a binary distribution of a broad set of open source
geospatial software for Win32 environments (Windows XP, Vista, etc).
OSGeo4W includes GDAL/OGR,  GRASS, MapServer?,  OpenEV,  uDig, as well
as many other packages (about 70 as of summer 2008).
"""

I think for folks that are primarily FOSS4G folks, this is great. A bit
of a mess if you just want GDAL though.

-Chris



--
Christopher Barker, Ph.D.
Oceanographer

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

[hidden email]
_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Frank Warmerdam
In reply to this post by Tamas Szekeres
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,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Jason Roberts
In reply to this post by Tamas Szekeres

Specifically regarding Python programmers who primarily or exclusively use Windows:

 

The majority of popular Python packages are delivered to Windows users by one of two mechanisms:

 

1.    A stand-alone installation program (either a .exe or .msi file) that the user just downloads and runs, often built with the Python “distutils” technology.

2.    The easy_install mechanism, in which the user starts a shell and types “easy_install xxxxx”.

 

Most Windows users are not familiar with the UNIX way of doing things, in which the package is compiled and installed from a script. Most Windows users do not even have a C compiler on their machine.

 

As evidence for the popularity of #1, just look at the installation statistics for popular packages such as scipy or numpy. For example, the Python 2.6 .exe installer for scipy 0.8.0 currently has 28417 downloads, while the source code (.tar.gz file) currently has 14403 downloads. As UNIX users will be downloading the source code and not the Windows executable, the 14403 is likely to be a lot of UNIX users and few Windows users. As you can see, the vast majority of Windows scipy users prefer to install it via the GUI installation program rather than the source code.

 

Right now, to install the latest GDAL for Python on Windows, the user has to download a zip file from http://vbkto.dyndns.org/sdk/, drill in to find the Python files, copy them to C:\PythonXX\Lib\site-packages, drill into find the GDAL binaries and related files, copy them to a directory such as C:\GDAL, set the PATH and GDAL environment variables, and so on. And there are no obvious instructions anywhere about how to do this. Python programmers are programmers after all, so they can generally figure that out and accomplish it. But it is not what they are used to doing if they are a Windows programmer. This is why Chris basically says that he has to remember / relearn how to do it every time he upgrades GDAL.

 

It would be really helpful to Windows Python programmers who want to use GDAL—probably a large number of potential GDAL users—for the GDAL team to offer installation via one or both of the mechanisms I mentioned above.

 

Best,

Jason

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Tamas Szekeres
Sent: Wednesday, January 05, 2011 4:37 PM
To: Christopher Barker
Cc: [hidden email]
Subject: Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

 

 

2011/1/5 Christopher Barker <[hidden email]>


1) It would be nice to have binaries for the latest release front and center at the main GDAL site -- having to poke around to find Tamas's site is not a big deal, but not always obvious.


Chris,

With regards to the comment above, while I'm not sure about the objectives but I don't think the GDAL site would intend to be a hosting provider of various binary packages, the most reasonable thing is to put the references pointing the user to the correct locations which has already been done, see the "Downloads" section at http://www.gdal.org/

2) A standard install location would be good. As I've messed with this each time, I never know where stuff should go -- maybe installers would help with that


This doesn't seem to be decisive requirement to me. We may also create a definite location in the hard drive to host such files (which can be remembered later). Or some other folks may prefer installing these files along with their applications or keep such files in separate - project specific - directories. We may also have a requirement to deploy and run these applications from portable locations (ie. from CD or a flash drive). Another issue of an installer may be due to a single product key along with the setup which would prevent from installing multiple versions side by side in the same environment.
 

3) If there is a standard install location, then "easy_install gdal" (or setup.py build, or...) could work for the python bindings.


I admit I don't have enough knowledge about the 'magic' tricks related to python-ish way installing applications. I expect that most 'magic' are implemented by copying the files at certain locations, setting some environment variables or regkey entries. However I might also consider running a custom application with gdal not necessarily be the responsibility of a GDAL package. You might also want to install python from a separate installer (either ActivePython, python.org whatever) and run the application direcly from a command prompt where the environments are set to run the gdal applications properly. Most of these packages provide the required .bat file to setup the environment this way.
 

Another option is to have a binary installer for the python bindings that includes gdal and the gdal utilities -- that would be great for users like me, but I don't know how common my use case is. In that case, you'd want to support a few recent pythons versions, the python.org binaries: 2.6, 2.7, 3.1 (maybe 2.5 too).


I don't know much about this either. This may however be doable for those guys who know the Python packaging approach well enough. I don't think eiter of the packages referred at http://trac.osgeo.org/gdal/wiki/DownloadingGdalBinaries would support this feature though.

 

One of the tricks here is which numpy to support, etc. numpy has been pretty good with binary compatibility lately (except for one mistake recently that was corrected)


Not sure how this be related to a GDAL binary distribution, as far as I remember numpy can be installed to the Python deployment directly.

 

However, I DON'T want gdal to give me  Python -- I use Python for too many other things for that.


Yes, adding more runtime environments to a simple GDAL package makes it more heavy weighted. Would also be reasonable to include the Perl environment or a .NET framework installer for example to make it more complete. However, in many cases it's more reasonable to let the application (using the GDAL binaries) decide how to make a proper installer to run their application smoothly.

 

4) it might be nice if the install location for the utilities got put on the user's PATH -- I don't know how hard that is in an installer -- Windows really sucks in that regard.

 


I don't think it would be beneficial in most cases. This could easily break other applications (using the dll-s with the same names) to fail unexpectedly. I would prefer to keep the applications isolated (setting the environment variables specifically to the process and not the user/system) as much as possible.

An installer would better enforce a standard install location. You could also have a custom DOS box with a menu entry that set up the environment for the command line tools (maybe only PATH?), provide an uninstaller, and of course, give the Windows users a nice warm and fuzzy feeling.


The 'nice warm and fuzzy feeling' is a good objective indeed, setting up an entry on the start menu instead of a running the batch file directly may also be an advantage. While I'm not sure starting a DOS prompt would validate an installer by it's own, I can see this requirement to be valid in most cases.

 

With regard to Python, an installer could see what Python the user has and install the bindings for that version. Not that I have any idea how to build that!


Agreed, but I have no idea either.
 

Inno Setup is a very nice free installer, by the way.

 


I would also add Wix to the list.
 

Best regards,

Tamas


_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Tamas Szekeres
In reply to this post by Tamas Szekeres


2011/1/5 Jason Roberts <[hidden email]>

Right now, to install the latest GDAL for Python on Windows, the user has to download a zip file from http://vbkto.dyndns.org/sdk/, drill in to find the Python files, copy them to C:\PythonXX\Lib\site-packages, drill into find the GDAL binaries and related files, copy them to a directory such as C:\GDAL, set the PATH and GDAL environment variables, and so on. And there are no obvious instructions anywhere about how to do this. Python programmers are programmers after all, so they can generally figure that out and accomplish it. But it is not what they are used to doing if they are a Windows programmer. This is why Chris basically says that he has to remember / relearn how to do it every time he upgrades GDAL.

 

It would be really helpful to Windows Python programmers who want to use GDAL—probably a large number of potential GDAL users—for the GDAL team to offer installation via one or both of the mechanisms I mentioned above.



Jason,

Maybe this is due to my lack of knowledge in Python, but why is it a requirement to place the files to such specific locations to run a python app with gdal on Windows? As far as I remember setting up the following environment variables properly (in a command prompt) does the right thing from arbitrary locations (at least when running the autotest suite for GDAL):

PROJ_LIB
GDAL_DRIVER_PATH
GDAL_DATA
PYTHONPATH
PATH

Certainly one should find out the location of the python.exe which might also be included in PATH for convenience.

Best regards,

Tamas


_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Tamas Szekeres
In reply to this post by Chris Barker
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?

Best regards,

Tamas



2011/1/5 Christopher Barker <[hidden email]>
It may well be that GDAL has too many different use cases to even have a "standard" install, but...


On 1/5/11 1:37 PM, Tamas Szekeres wrote:
2011/1/5 Christopher Barker <[hidden email]
   1) It would be nice to have binaries for the latest release front
   and center at the main GDAL site -- having to poke around to find
   Tamas's site is not a big deal, but not always obvious.

With regards to the comment above, while I'm not sure about the
objectives but I don't think the GDAL site would intend to be a hosting
provider of various binary packages,

Well, many (most?) open source packages have "official" binaries hosted on its site. It's pretty common to go to a project's site and expect to find a way to download binaries right then and there.


   2) A standard install location would be good. As I've messed with
   this each time, I never know where stuff should go -- maybe
   installers would help with that

This doesn't seem to be decisive requirement to me.

It's not a strong requirement, but standard defaults do make things easier for everyone.


Or some other folks may prefer installing these files
along with their applications or keep such files in separate - project
specific - directories.

Well, users should certainly be able to do something custom if they want. This is all about use-cases -- if you are building a custom app linked against GDAL, then you probably want to control where you put things.

However, if you are interested in the command line tools, and using GDAL via Python or Perl or ??, then it makes it easier to have a standard location.


> Another issue of an installer may be due to a single product key
along with the setup which would prevent from installing multiple
versions side by side in the same environment.

Surely there are ways to accommodate that? though "dll hell" is in the lexicon for a reason!


   3) If there is a standard install location, then "easy_install gdal"
   (or setup.py build, or...) could work for the python bindings.

I admit I don't have enough knowledge about the 'magic' tricks related
to python-ish way installing applications.

That's the thing -- there is no magic here. If you are building a python extension, you need to tell the build system where its dependencies lie. If you are installing a pre-built python extension, then the dependencies need to be in a known place (or maybe on the right PATHS -- Windows is pretty ugly this way). Which is why a "standard" install location would be a good idea.


I might also consider
running a custom application with gdal not necessarily be the
responsibility of a GDAL package.

well, that depends on whether you consider Python bindings a "custom application". In any case, I think it helps third party packages to have standard default install locations.

Oh for *nix -- this would be easier if we just could just put stuff in /usr/local/...

You might also want to install python
from a separate installer (either ActivePython, python.org
<http://python.org> whatever)

True -- but it is very much a standard for third party packages to provide binaries for the python.org python build. Again, I'm not suggesting that folks should be prevented (or even discouraged) from doing various sorts of custom installs, just that there should be defaults, so that it's clear an easy for a newbie to know what to to to get things to "just work".

   Another option is to have a binary installer for the python bindings
   that includes gdal and the gdal utilities -- that would be great for
   users like me, but I don't know how common my use case is. In that
   case, you'd want to support a few recent pythons versions, the
   python.org <http://python.org> binaries: 2.6, 2.7, 3.1 (maybe 2.5 too).


I don't know much about this either. This may however be doable for
those guys who know the Python packaging approach well enough.

It's not that hard (at lest once GDAL is built), but it is work.


I don't
think eiter of the packages referred at
http://trac.osgeo.org/gdal/wiki/DownloadingGdalBinaries would support
this feature though.

Agreed -- that's my point!


   One of the tricks here is which numpy to support, etc. numpy has
   been pretty good with binary compatibility lately (except for one
   mistake recently that was corrected)


Not sure how this be related to a GDAL binary distribution, as far as I
remember numpy can be installed to the Python deployment directly.

yes, but the Python bindings are built against a particular numpy. That's OK for version so numpy that are binary compatible, but it potentially fragile. Note that with the new extended buffer interface, it should be possible to build GDAL with full numpy support, but not have to compile against numpy. But I think that's only good for 2.7 and 3.*


   However, I DON'T want gdal to give me  Python -- I use Python for
   too many other things for that.

Yes, adding more runtime environments to a simple GDAL package makes it
more heavy weighted.

right -- I think we're talking about lightweight, GDAL only packages here.


in many cases it's more reasonable to let the
application (using the GDAL binaries) decide how to make a proper
installer to run their application smoothly.

Hmm -- that's the trick -- are the Python (and Perl, and...) bindings an "application (using the GDAL binaries)", or are they part of GDAL? In many cases, the python bindings are a completely separate project from the library they bind, so it's a clear distinction, but not in this case.

This makes me think, though -- maybe I should think about this differently -- I'm trying to get the GDAL command line tools, and the Python bindings. Maybe I should simply consider those as separate issues altogether -- they don't need to share the same binaries. In that case, maybe the python bindings should be statically linked, or deliver the dlls with the bindings, and be available as an entirely stand-alone installer.

Indeed, having said that, I'm looking around and see that someone is doing that:

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

very nice -- I'll have to give those a test.


   4) it might be nice if the install location for the utilities got
   put on the user's PATH -- I don't know how hard that is in an
   installer -- Windows really sucks in that regard.

I don't think it would be beneficial in most cases. This could easily
break other applications (using the dll-s with the same names) to fail
unexpectedly.

I was thinking the executable utilities, not the dlls, but Windows does conflate those PATHs, doesn't it? (sigh)

Anyway, next time I update my Windows system (which I'll need to do soon), I'll think about these issues some more.

A couple notes on: Looking again at that page, I'm reminded why this has seemed painful. Under the Windows section:

"""
Minimalist windows executables are available at:

    http://download.osgeo.org/gdal/win32/1.6/gdalwin32exe160.zip
"""

these are out of date -- if they are going to exist, they really should be updated. They are hosted by osgeo, and thus look "official".

"""
Other plugins will be added in the same location (such as Oracle/OCI):

    http://download.osgeo.org/gdal/win32/
"""

How well maintained is this set?

"""
A more featureful set of windows binaries, including python, proj and c# support is available as part of the  FWTools package.
"""

no longer kept up to date, either.

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


"""
Tamas Szekeres maintains a complete set of Win32 and Win64 binary packages (compiled with VC2003/VC2005/VC2008) available at the following location. These are fabulous -- maybe they should be first on the list? Though there is a LOT there -- you need to know what you are looking for.

"""
 OSGeo4W is a binary distribution of a broad set of open source geospatial software for Win32 environments (Windows XP, Vista, etc). OSGeo4W includes GDAL/OGR,  GRASS, MapServer?,  OpenEV,  uDig, as well as many other packages (about 70 as of summer 2008).
"""

I think for folks that are primarily FOSS4G folks, this is great. A bit of a mess if you just want GDAL though.


-Chris



--
Christopher Barker, Ph.D.
Oceanographer

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

[hidden email]
_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev


_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Jason Roberts
In reply to this post by Tamas Szekeres

Tamas,

 

I have a decent amount of experience programming with Python (6 years, develop my own extension modules, etc) and I have never seen a package that recommends you install it to a directory of your choice and then modify the PYTHONPATH environment variable. The standard installation location is the “site-packages” directory. See http://www.python.org/dev/peps/pep-0250/ for some background on that.

 

The GDAL team certainly could publish instructions that said “copy the release-1500-dev\gdal\swig\python\*.py and the osgeo subdirectory directory to a location of your choice and modify set the PYTHONPATH environment variable to include that location” but it would be very unusual. GDAL would likely be the only package that the user encounters with those instructions. The PYTHONPATH environment variable would likely not even be defined already. (Although if they have ArcGIS, it would be, because ArcGIS includes some Python extensions that live in the ArcGIS installation dir.)

 

So, in sum, you could make PYTHONPATH your official solution but it would be weird. The more traditional route would be to modify the GDAL build scripts to invoke the existing setup.py with the arguments “bdist --formats=wininst” to build a Windows installation package (see http://docs.python.org/distutils/builtdist.html). Ideally, it would also include a post-install script that could install the GDAL binaries somewhere (such as a subdir inside \PythonXX\Lib\site-packages\gdal) and set PATH, PROJ_LIB, GDAL_DRIVER_PATH, and GDAL_DATA to the correct things. I could potentially help you develop that. It looks like most of what is needed is already there.

 

Jason

 

From: Tamas Szekeres [mailto:[hidden email]]
Sent: Wednesday, January 05, 2011 6:12 PM
To: Jason Roberts
Cc: [hidden email]; Christopher Barker
Subject: Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

 

 

2011/1/5 Jason Roberts <[hidden email]>

 

Right now, to install the latest GDAL for Python on Windows, the user has to download a zip file from http://vbkto.dyndns.org/sdk/, drill in to find the Python files, copy them to C:\PythonXX\Lib\site-packages, drill into find the GDAL binaries and related files, copy them to a directory such as C:\GDAL, set the PATH and GDAL environment variables, and so on. And there are no obvious instructions anywhere about how to do this. Python programmers are programmers after all, so they can generally figure that out and accomplish it. But it is not what they are used to doing if they are a Windows programmer. This is why Chris basically says that he has to remember / relearn how to do it every time he upgrades GDAL.

 

It would be really helpful to Windows Python programmers who want to use GDAL—probably a large number of potential GDAL users—for the GDAL team to offer installation via one or both of the mechanisms I mentioned above.



Jason,

Maybe this is due to my lack of knowledge in Python, but why is it a requirement to place the files to such specific locations to run a python app with gdal on Windows? As far as I remember setting up the following environment variables properly (in a command prompt) does the right thing from arbitrary locations (at least when running the autotest suite for GDAL):

PROJ_LIB
GDAL_DRIVER_PATH
GDAL_DATA
PYTHONPATH
PATH

Certainly one should find out the location of the python.exe which might also be included in PATH for convenience.

Best regards,

Tamas

 


_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
1234
Loading...