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,
--
---------------------------------------+--------------------------------------
___________________________________________________

Posted on the Gdal-dev mailing list. Go to http://lists.osgeo.org/mailman/listinfo/gdal-dev/ to subscribe.

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

Best regards,

andrea

-----
Andrea Borruso

----------------------------------------------------
___________________________________________________

Posted on the Gdal-dev mailing list. Go to http://lists.osgeo.org/mailman/listinfo/gdal-dev/ to subscribe.

2011/1/5 Livneh Yehiyam <>

> 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

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


_______________________________________________
___________________________________________________

Posted on the Gdal-dev mailing list. Go to http://lists.osgeo.org/mailman/listinfo/gdal-dev/ to subscribe.

2011/1/5 Christopher Barker <>

> 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

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/
_______________________________________________
___________________________________________________

Posted on the Gdal-dev mailing list. Go to http://lists.osgeo.org/mailman/listinfo/gdal-dev/ to subscribe.

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


_______________________________________________
___________________________________________________

Posted on the Gdal-dev mailing list. Go to http://lists.osgeo.org/mailman/listinfo/gdal-dev/ to subscribe.

2011/1/5 Christopher Barker <>

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

2011/1/5 Daniel Morissette <>

> 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

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


_______________________________________________
___________________________________________________

Posted on the Gdal-dev mailing list. Go to http://lists.osgeo.org/mailman/listinfo/gdal-dev/ to subscribe.