/usr/lib/python3/dist-packages/GDAL-1.10.1.egg-info is in python3-gdal 1.10.1+dfsg-5ubuntu1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 | Metadata-Version: 1.1
Name: GDAL
Version: 1.10.1
Summary: GDAL: Geospatial Data Abstraction Library
Home-page: http://www.gdal.org
Author: Howard Butler
Author-email: hobu.inc@gmail.com
License: MIT
Description: b'\nGDAL/OGR in Python\n==================\n \nThis Python package and extensions are a number of tools for programming and \nmanipulating the GDAL_ Geospatial Data Abstraction Library. Actually, it is \ntwo libraries -- GDAL for manipulating geospatial raster data and OGR for \nmanipulating geospatial vector data -- but we\'ll refer to the entire package \nas the GDAL library for the purposes of this document.\n\nThe GDAL project (primarily Howard Butler) maintains SWIG generated Python \nbindings for GDAL and OGR. Generally speaking the classes and methods mostly \nmatch those of the GDAL and OGR C++ classes. There is no Python specific \nreference documentation, but the `GDAL API Tutorial`_ includes Python examples.\n\nDependencies\n------------\n \n * libgdal (1.7.0 or greater) and header files (gdal-devel)\n * numpy (1.0.0 or greater) and header files (numpy-devel) (not explicitly \n required, but many examples and utilities will not work without it)\n\nInstallation\n------------\n\nUnix\n~~~~~~~~~~~~~\n\nThe GDAL Python bindings support both distutils and setuptools, with a \npreference for using setuptools. If setuptools can be imported, setup will \nuse that to build an egg by default. If setuptools cannot be imported, a \nsimple distutils root install of the GDAL package (and no dependency \nchaining for numpy) will be made. \n\neasy_install\n~~~~~~~~~~~~\n\nGDAL can be installed from the Python CheeseShop::\n\n $ sudo easy_install GDAL\n\nIt may be necessary to have libgdal and its development headers installed \nif easy_install is expected to do a source build because no egg is available \nfor your specified platform and Python version.\n\nsetup.py\n~~~~~~~~~\n\nMost of setup.py\'s important variables are controlled with the setup.cfg \nfile. In setup.cfg, you can modify pointers to include files and libraries. \nThe most important option that will likely need to be modified is the \ngdal_config parameter. If you installed GDAL from a package, the location \nof this program is likely /usr/bin/gdal-config, but it may be in another place \ndepending on how your packager arranged things. \n\nAfter modifying the location of gdal-config, you can build and install \nwith the setup script::\n \n $ python setup.py build\n $ python setup.py install\n\nIf you have setuptools installed, you can also generate an egg::\n \n $ python setup.py bdist_egg\n\nBuilding as part of the GDAL library source tree\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nYou can also have the GDAL Python bindings built as part of a source \nbuild by specifying --with-python as part of your configure line::\n\n $ ./configure --with-python\n\nUse the typical make and make install commands to complete the installation:: \n \n $ make\n $ make install\n\nA note about setuptools\n.......................\n\n./configure attempts to detect if you have setuptools installed in the tree \nof the Python binary it was given (or detected on the execution path), and it \nwill use an egg build by default in that instance. If you have a need to \nuse a distutils-only install, you will have to edit setup.py to ensure that \nthe HAVE_SETUPTOOLS variable is ultimately set to False and proceed with a \ntypical \'python setup.py install\' command.\n\nWindows\n~~~~~~~~~~~~\n\nYou will need the following items to complete an install of the GDAL Python\nbindings on Windows:\n\n* `GDAL Windows Binaries`_ The basic install requires the gdalwin32exe###.zip \n (### is the version number). Other files you see in the directory are \n for various optional plugins and development headers/include files. After \n downloading the zip file, extract it to the directory of your choosing.\n\n* GDAL Python Bindings available at the `Python Cheeseshop`_. An executable \n installer is available for both Python 2.4 or 2.5 or as a Python egg.\n\nAs explained in the README_EXE.txt file, after unzipping the GDAL binaries you \nwill need to modify your system path and variables. If you\'re not sure how to \ndo this, read the `Microsoft KnowledgeBase doc`_ \n\n1. Add the installation directory bin folder to your system PATH, remember \n to put a semicolon in front of it before you add to the existing path.\n\n ::\n \n C:\\gdalwin32-1.7\\bin\n\n2. Create a new user or system variable with the data folder from \n your installation.\n\n ::\n \n Name : GDAL_DATA\n Path : C:\\gdalwin32-1.7\\data\n\nSkip down to the `Usage`_ section to test your install. Note, a reboot \nmay be required.\n\nSWIG\n----\n\nThe GDAL Python package is built using SWIG_. The earliest version of SWIG_ \nthat is supported to generate the wrapper code is 1.3.39. It is possible \nthat usable bindings will build with a version earlier than 1.3.39, but no \ndevelopment efforts are targeted at versions below it. You should not have \nto run SWIG in your development tree to generate the binding code, as it \nis usually included with the source. However, if you do need to regenerate, \nyou can do so with the following make command from within the ./swig/python\ndirectory::\n\n $ make generate\n\nTo ensure that all of the bindings are regenerated, you can clean the \nbindings code out before the generate command by issuing::\n\n $ make veryclean\n\nUsage\n-----\n\nImports\n~~~~~~~\n\nThere are five major modules that are included with the GDAL_ Python bindings.::\n\n >>> from osgeo import gdal\n >>> from osgeo import ogr\n >>> from osgeo import osr\n >>> from osgeo import gdal_array\n >>> from osgeo import gdalconst\n\nAdditionally, there are five compatibility modules that are included but \nprovide notices to state that they are deprecated and will be going away. \nIf you are using GDAL 1.7 bindings, you should update your imports to utilize \nthe usage above, but the following will work until at least GDAL 2.0. ::\n\n >>> import gdal\n >>> import ogr\n >>> import osr\n >>> import gdalnumeric\n >>> import gdalconst\n\nIf you have previous code that imported the global module and still need to \nsupport the old import, a simple try...except import can silence the \ndeprecation warning and keep things named essentially the same as before::\n\n >>> try:\n ... from osgeo import gdal\n ... except ImportError:\n ... import gdal\n\nDocstrings\n~~~~~~~~~~\n\nCurrently, only the OGR module has docstrings which are generated from the \nC/C++ API doxygen materials. Some of the arguments and types might not \nmatch up exactly with what you are seeing from Python, but they should be \nenough to get you going. Docstrings for GDAL and OSR are planned for a future \nrelease.\n\nThe History of Using GDAL/OGR in Python\n---------------------------------------\n\nPython was the first set of bindings supported by GDAL/OGR and though the \nbindings were generated with SWIG (1.1 series), the process was very Python \nspecific and contained a significant amount of hand written wrapper code. In \n2005, Kevin Ruland launched an effort for a set of next generation bindings \ngenerated with SWIG (1.3 series) and supported by a variety of languages. \nWith GDAL 1.4.0 the various bindings became fairly mature, and for GDAL 1.5.0, \nthe "next-generation" bindings become the default bindings. The previous, \n"old-generation," bindings will continue to be available, but they will not \nbe widely supported and no new development will be targeted at them. From \nthe viewpoint of a user, with GDAL 1.7.0 and above, you should not have to \nworry very much about the distinction between these two development efforts.\n\nNumpy/Numeric\n-------------\n\nOne advanced feature of the GDAL Python bindings not found in the other \nlanguage bindings (C#, Perl) is integration with the Python numerical array \nfacilities. The gdal.Dataset.ReadAsArray() method can be used to read raster \ndata as numerical arrays, ready to use with the Python numerical array \ncapabilities.\n\nThese facilities have evolved somewhat over time. In the past the package was \nknown as "Numeric" and imported using "import Numeric". A new generation is \nimported using "import numpy". Currently the old generation bindings only \nsupport the older Numeric package, and the new generation bindings only \nsupport the new generation numpy package. They are mostly compatible, and \nby importing gdalnumeric (or osgeo.gdal_array) you will get whichever is\nappropriate to the current bindings type.\n\nExamples\n~~~~~~~~\n\nOne example of GDAL/numpy integration is found in the `val_repl.py`_ script.\n\nPerformance Notes\n~~~~~~~~~~~~~~~~~\n\nReadAsArray expects to make an entire copy of a raster band or dataset unless \nthe data are explicitly subsetted as part of the function call. For large \ndata, this approach is expected to be prohibitively memory intensive.\n\n.. _GDAL API Tutorial: http://www.gdal.org/gdal_tutorial.html\n.. _GDAL Windows Binaries: http://download.osgeo.org/gdal/win32/1.5/\n.. _Microsoft KnowledgeBase doc: http://support.microsoft.com/kb/310519\n.. _Python Cheeseshop: http://pypi.python.org/pypi/GDAL/\n.. _val_repl.py: http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/python/samples/val_repl.py\n.. _GDAL: http://www.gdal.org\n.. _SWIG: http://www.swig.org\n'
Platform: UNKNOWN
Classifier: Development Status :: 5 - Production/Stable
Classifier: Intended Audience :: Developers
Classifier: Intended Audience :: Science/Research
Classifier: License :: OSI Approved :: MIT License
Classifier: Operating System :: OS Independent
Classifier: Programming Language :: Python :: 2
Classifier: Programming Language :: Python :: 3
Classifier: Programming Language :: C
Classifier: Programming Language :: C++
Classifier: Topic :: Scientific/Engineering :: GIS
Classifier: Topic :: Scientific/Engineering :: Information Analysis
|