Changes between Version 6 and Version 7 of GdalOgrInPython

Timestamp:

Dec 4, 2007, 10:12:31 PM (16 years ago)

Author:

hobu

Comment:

--

GdalOgrInPython

@@ -1 @@
-= GDAL/OGR In Python = 
-
-The GDAL project (primarily Howard Butler) maintains SWIG generated Python bindings for GDAL and OGR.  Generally speaking the classes and methods mostly match those of the GDAL and OGR C++ classes.  There is no python specific reference documentation, but the [http://www.gdal.org/gdal_tutorial.html GDAL API Tutorial] includes Python examples. 
-
-== New vs. Old Bindings ==
-
-Python was the first set of bindings supported by GDAL/OGR and though the bindings were generated with SWIG, the process was very python specific.  In 2005 Kevin Ruland launched an effort for a set of ''Next Generation'' bindings generated with SWIG and supported by a variety of languages.  With GDAL 1.4.0 the various bindings are becoming fairly mature, and the ''next generation'' python bindings are becoming the preferred set in place of the old bindings.  However for python both are still available. 
-
-The ''old generation'' bindings live in the gdal/pymod directory, and are mixed up with various python utility scripts, and samples.  The ''new generation'' bindings live in the gdal/swig/python directory.  On unix to build with the old generation bindings you would configure --with-python --without-ngpython.  To build with the new generation bindings you would use --without-python --with-ngpython.  
-
-The new python bindings are generally compatible with the old bindings though some quirks exist.  As time goes on the new bindings will continue to be extended as GDAL is extended, but the old generation bindings will not.  At this time the test suite should pass with either the old or new bindings.  Some applications, such as OpenEV 1.x still depend on the old Python bindings (which is why [wiki:FWTools] still ships with the old bindings). 
-
-== Numpy / Numeric ==
-
-One advanced feature of the GDAL python bindings not found in the other bindings is integration with the Python numerical array facilities.  The gdal.Dataset.!ReadAsArray() method can be used to read raster data as numerical arrays, ready to use with the Python numerical array capabilities.  
-
-These facilities have evolved somewhat over time.  In the past the package was known as "Numeric" and imported using "import Numeric".  A new generation is imported using "import numpy".  Currently the old generation bindings only support the older Numeric package, and the new generatio bindings only support the new generation numpy package.  They are mostly compatible, and by importing gdalnumeric you will get whichever is appropriate to the current bindings type. 
-
-One example of GDAL/numpy integration is found in the sample [http://trac.osgeo.org/gdal/browser/trunk/gdal/pymod/samples/val_repl.py pymod/samples/val_repl.py] script.
-
-== Examples ==
-
- * [http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/python/samples swig/python/samples] contains some example python scripts
- * [http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/python/scripts swig/python/scripts] has a several interesting python utilities. 
- * Much of the GDAL [http://trac.osgeo.org/gdal/browser/trunk/autotest autotest] suite is written in python and can be browsed for examples
+{{{
+#!rst
+GDAL/OGR in Python
+==================
+
+This Python package and extensions are a number of tools for programming and 
+manipulating the GDAL_ Geospatial Data Abstraction Library.  Actually, it is 
+two libraries -- GDAL for manipulating geospatial raster data and OGR for 
+manipulating geospatial vector data -- but we'll refer to the entire package 
+as the GDAL library for the purposes of this document.
+
+The GDAL project (primarily Howard Butler) maintains SWIG generated Python 
+bindings for GDAL and OGR. Generally speaking the classes and methods mostly 
+match those of the GDAL and OGR C++ classes. There is no Python specific 
+reference documentation, but the `GDAL API Tutorial`_ includes Python examples.
+
+Dependencies
+------------
+ 
+ * libgdal (1.5.0 or greater) and header files (gdal-devel)
+ * numpy (1.0.0 or greater) and header files (numpy-devel) (not explicitly 
+   required, but many examples and utilities will not work without it)
+
+Installation
+------------
+
+The GDAL Python bindings support both distutils and setuptools, with a 
+preference for using setuptools.  If setuptools can be imported, setup will 
+use that to build an egg by default.  If setuptools cannot be imported, a 
+simple distutils root install of the GDAL package (and no dependency 
+chaining for numpy) will be made.  
+
+easy_install
+~~~~~~~~~~~~
+
+GDAL can be installed from the Python CheeseShop::
+
+  $ sudo easy_install GDAL
+
+It may be necessary to have libgdal and its development headers installed 
+if easy_install is expected to do a source build because no egg is available 
+for your specified platform and Python version.
+
+setup.py
+~~~~~~~~~
+
+Most of setup.py's important variables are controlled with the setup.cfg 
+file.  In setup.cfg, you can modify pointers to include files and libraries.  
+The most important option that will likely need to be modified is the 
+gdal_config parameter.  If you installed GDAL from a package, the location 
+of this program is likely /usr/bin/gdal-config, but it may be in another place 
+depending on how your packager arranged things.  
+
+After modifying the location of gdal-config, you can build and install 
+with the setup script::
+  
+  $ python setup.py build
+  $ python setup.py install
+
+If you have setuptools installed, you can also generate an egg::
+  
+  $ python setup.py bdist_egg
+
+Building as part of the GDAL library source tree
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You can also have the GDAL Python bindings built as part of a source 
+build by specifying --with-python as part of your configure line::
+
+  $ ./configure --with-python
+
+Use the typical make and make install commands to complete the installation:: 
+  
+  $ make
+  $ make install
+
+A note about setuptools
+.......................
+
+./configure attempts to detect if you have setuptools installed in the tree 
+of the Python binary it was given (or detected on the execution path), and it 
+will use an egg build by default in that instance.  If you have a need to 
+use a distutils-only install, you will have to edit setup.py to ensure that 
+the HAVE_SETUPTOOLS variable is ultimately set to False and proceed with a 
+typical 'python setup.py install' command.
+
+SWIG
+----
+
+The GDAL Python package is built using SWIG_. The earliest version of SWIG_ 
+that is supported to generate the wrapper code is 1.3.31.  It is possible 
+that usable bindings will build with a version earlier than 1.3.31, but no 
+development efforts are targeted at versions below it.  You should not have 
+to run SWIG in your development tree to generate the binding code, as it 
+is usually included with the source.  However, if you do need to regenerate, 
+you can do so with the following make command from within the ./swig/python
+directory::
+
+  $ make generate
+
+To ensure that all of the bindings are regenerated, you can clean the 
+bindings code out before the generate command by issuing::
+
+  $ make veryclean
+
+Usage
+-----
+
+Imports
+~~~~~~~
+
+There are five major modules that are included with the GDAL_ Python bindings.::
+
+  >>> from osgeo import gdal
+  >>> from osgeo import ogr
+  >>> from osgeo import osr
+  >>> from osgeo import gdal_array
+  >>> from osgeo import gdalconst
+
+Additionally, there are five compatibility modules that are included but 
+provide notices to state that they are deprecated and will be going away.  
+If you are using GDAL 1.5 bindings, you should update your imports to utilize 
+the usage above, but the following will work until at least GDAL 2.0. ::
+
+  >>> import gdal
+  >>> import ogr
+  >>> import osr
+  >>> import gdalnumeric
+  >>> import gdalconst
+
+If you have previous code that imported the global module and still need to 
+support the old import, a simple try...except import can silence the 
+deprecation warning and keep things named essentially the same as before::
+
+  >>> try:
+  ...     from osgeo import gdal
+  ... except ImportError:
+  ...     import gdal
+
+Docstrings
+~~~~~~~~~~
+
+Currently, only the OGR module has docstrings which are generated from the 
+C/C++ API doxygen materials.  Some of the arguments and types might not 
+match up exactly with what you are seeing from Python, but they should be 
+enough to get you going.  Docstrings for GDAL and OSR are planned for a future 
+release.
+
+The History of Using GDAL/OGR in Python
+---------------------------------------
+
+Python was the first set of bindings supported by GDAL/OGR and though the 
+bindings were generated with SWIG (1.1 series), the process was very Python 
+specific and contained a significant amount of hand written wrapper code. In 
+2005, Kevin Ruland launched an effort for a set of next generation bindings 
+generated with SWIG (1.3 series) and supported by a variety of languages. 
+With GDAL 1.4.0 the various bindings became fairly mature, and for GDAL 1.5.0, 
+the "next-generation" bindings become the default bindings.  The previous, 
+"old-generation," bindings will continue to be available, but they will not 
+be widely supported and no new development will be targeted at them.  From 
+the viewpoint of a user, with GDAL 1.5.0 and above, you should not have to 
+worry very much about the distinction between these two development efforts.
+
+Usage of Old-Generation Python Bindings
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+For certain legacy applications (most notably OpenEV 1.x), it may be necessary 
+to continue to use the old-generation Python bindings.  These can be built 
+and installed as part of a source build from ./configure::
+  
+  $ ./configure --with-ogpython=/usr/bin/python
+
+As noted earlier, these bindings are not widely supported and no new 
+development is expected to take place with them (including serious bug 
+fixes).  
+
+Numpy/Numeric
+-------------
+
+One advanced feature of the GDAL Python bindings not found in the other 
+language bindings (C#, Perl) is integration with the Python numerical array 
+facilities. The gdal.Dataset.ReadAsArray() method can be used to read raster 
+data as numerical arrays, ready to use with the Python numerical array 
+capabilities.
+
+These facilities have evolved somewhat over time. In the past the package was 
+known as "Numeric" and imported using "import Numeric". A new generation is 
+imported using "import numpy". Currently the old generation bindings only 
+support the older Numeric package, and the new generation bindings only 
+support the new generation numpy package. They are mostly compatible, and 
+by importing gdalnumeric you will get whichever is appropriate to the 
+current bindings type.
+
+Examples
+~~~~~~~~
+
+One example of GDAL/numpy integration is found in the `val_repl.py`_ script.
+
+Performance Notes
+~~~~~~~~~~~~~~~~~
+
+ReadAsArray expects to make an entire copy of a raster band or dataset unless 
+the data are explicitly subsetted as part of the function call. For large 
+data, this approach is expected to be prohibitively memory intensive.
+
+.. _GDAL API Tutorial: http://www.gdal.org/gdal_tutorial.html
+.. _val_repl.py: http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/python/samples/val_repl.py
+.. _GDAL: http://www.gdal.org
+.. _SWIG: http://www.swig.org
+}}}