05-01-2011 05:26 AM
05-01-2011 11:41 AM
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.
05-01-2011 02:05 PM
2011/1/5 Livneh Yehiyam <> 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
05-01-2011 04:48 PM
On 1/5/11 3:41 AM, iomeneandrei wrote: 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.
05-01-2011 05:44 PM
2011/1/5 Christopher Barker <> I've found it painful to find appropriate Windows executables every time 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
05-01-2011 05:50 PM
On 11-01-05 12:44 PM, Tamas Szekeres wrote: 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.
05-01-2011 06:28 PM
On 1/5/11 9:44 AM, Tamas Szekeres wrote: yes, a Major pain. I don't know that we need a single installer, but there is a lot to support. 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. 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.
05-01-2011 09:37 PM
2011/1/5 Christopher Barker <> 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 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. 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. 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. 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, 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. 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 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. Agreed, but I have no idea either. I would also add Wix
05-01-2011 09:43 PM
2011/1/5 Daniel Morissette <> 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
05-01-2011 10:25 PM
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: 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. It's not a strong requirement, but standard defaults do make things easier for everyone. 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 Surely there are ways to accommodate that? though "dll hell" is in the lexicon for a reason! 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. 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/... 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". It's not that hard (at lest once GDAL is built), but it is work. Agreed -- that's my point! 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.* right -- I think we're talking about lightweight, GDAL only packages here. 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. 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.