gipit/gippy

Geospatial Image Processing for Python

gippy's Issues

Installation does not work.

Tried:

sudo apt-get install libgdal1h gdal-bin libgdal-dev g++4.8

E: Unable to locate package g++4.8
E: Couldn't find any package by regex 'g++4.8'

Also, within a virtualenv, tried

pip install gippy -pre

and got:

Invalid requirement: '–pre'
Traceback (most recent call last):
File "/home/ubuntu/venv2/local/lib/python2.7/site-packages/pip/req/req_install.py", line 77, in init
req = pkg_resources.Requirement.parse(req)
File "/home/ubuntu/venv2/local/lib/python2.7/site-packages/pip/_vendor/pkg_resources/init.py", line 3036, in parse
req, = parse_requirements(s)
File "/home/ubuntu/venv2/local/lib/python2.7/site-packages/pip/_vendor/pkg_resources/init.py", line 2967, in parse_requirements
raise RequirementParseError("Missing distribution spec", line)
RequirementParseError: Missing distribution spec –pre

libgip.so: cannot open shared object file

I'm attempting to install gippy on my laptop from my (up-to-date) fork of the repo. I've come across this issue with libgip.so before, but I cannot remember the cause. Leaving only the commands and import error

$ sudo git clean -xfd ; \
  python setup.py build ; \
  sudo python setup.py install ; \
  cd ~ ; \
  python -c "import gippy ; print 'success' "

[[[ snipped compilation and installation output ]]]

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/local/lib/python2.7/dist-packages/gippy/__init__.py", line 23, in <module>
    from gippy import *
  File "/usr/local/lib/python2.7/dist-packages/gippy/gippy.py", line 32, in <module>
    _gippy = swig_import_helper()
  File "/usr/local/lib/python2.7/dist-packages/gippy/gippy.py", line 28, in swig_import_helper
    _mod = imp.load_module('_gippy', fp, pathname, description)
ImportError: libgip.so: cannot open shared object file: No such file or directory

But everything seems to be there

/usr/local/lib/python2.7/dist-packages/
├── gippy
│   ├── algorithms.py
│   ├── algorithms.pyc
│   ├── _algorithms.so
│   ├── gippy.py
│   ├── gippy.pyc
│   ├── _gippy.so
│   ├── __init__.py
│   ├── __init__.pyc
│   ├── libgip.so
│   ├── tests.py
│   ├── tests.pyc
│   ├── _tests.so
│   ├── version.py
│   └── version.pyc
└── gippy-0.3.3.egg-info
    ├── dependency_links.txt
    ├── PKG-INFO
    ├── SOURCES.txt
    └── top_level.txt

below is the build output:

running build
running build_py
creating build
creating build/lib.linux-x86_64-2.7
creating build/lib.linux-x86_64-2.7/gippy
copying gippy/version.py -> build/lib.linux-x86_64-2.7/gippy
copying gippy/__init__.py -> build/lib.linux-x86_64-2.7/gippy
running build_ext
building 'gippy/libgip' extension
creating build/temp.linux-x86_64-2.7
creating build/temp.linux-x86_64-2.7/GIP
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -IGIP -I/usr/include/python2.7 -c GIP/GeoRaster.cpp -o build/temp.linux-x86_64-2.7/GIP/GeoRaster.o -std=c++11 -O3 -DBOOST_LOG_DYN_LINK
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -IGIP -I/usr/include/python2.7 -c GIP/GeoImage.cpp -o build/temp.linux-x86_64-2.7/GIP/GeoImage.o -std=c++11 -O3 -DBOOST_LOG_DYN_LINK
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -IGIP -I/usr/include/python2.7 -c GIP/GeoAlgorithms.cpp -o build/temp.linux-x86_64-2.7/GIP/GeoAlgorithms.o -std=c++11 -O3 -DBOOST_LOG_DYN_LINK
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -IGIP -I/usr/include/python2.7 -c GIP/gip_gdal.cpp -o build/temp.linux-x86_64-2.7/GIP/gip_gdal.o -std=c++11 -O3 -DBOOST_LOG_DYN_LINK
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -IGIP -I/usr/include/python2.7 -c GIP/GeoResource.cpp -o build/temp.linux-x86_64-2.7/GIP/GeoResource.o -std=c++11 -O3 -DBOOST_LOG_DYN_LINK
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -IGIP -I/usr/include/python2.7 -c GIP/GeoSpatialContext.cpp -o build/temp.linux-x86_64-2.7/GIP/GeoSpatialContext.o -std=c++11 -O3 -DBOOST_LOG_DYN_LINK
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -IGIP -I/usr/include/python2.7 -c GIP/GeoVectorResource.cpp -o build/temp.linux-x86_64-2.7/GIP/GeoVectorResource.o -std=c++11 -O3 -DBOOST_LOG_DYN_LINK
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -IGIP -I/usr/include/python2.7 -c GIP/tests.cpp -o build/temp.linux-x86_64-2.7/GIP/tests.o -std=c++11 -O3 -DBOOST_LOG_DYN_LINK
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -IGIP -I/usr/include/python2.7 -c GIP/GeoImages.cpp -o build/temp.linux-x86_64-2.7/GIP/GeoImages.o -std=c++11 -O3 -DBOOST_LOG_DYN_LINK
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++
c++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-Bsymbolic-functions -Wl,-z,relro -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -Wl,-Bsymbolic-functions -Wl,-z,relro -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security build/temp.linux-x86_64-2.7/GIP/GeoRaster.o build/temp.linux-x86_64-2.7/GIP/GeoImage.o build/temp.linux-x86_64-2.7/GIP/GeoAlgorithms.o build/temp.linux-x86_64-2.7/GIP/gip_gdal.o build/temp.linux-x86_64-2.7/GIP/GeoResource.o build/temp.linux-x86_64-2.7/GIP/GeoSpatialContext.o build/temp.linux-x86_64-2.7/GIP/GeoVectorResource.o build/temp.linux-x86_64-2.7/GIP/tests.o build/temp.linux-x86_64-2.7/GIP/GeoImages.o -Lbuild/lib.linux-x86_64-2.7/gippy -o build/lib.linux-x86_64-2.7/gippy/libgip.so
building 'gippy/_gippy' extension
swigging gippy/gippy.i to gippy/gippy_wrap.cpp
swig -python -c++ -w509 -IGIP -o gippy/gippy_wrap.cpp gippy/gippy.i
creating build/temp.linux-x86_64-2.7/gippy
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -IGIP -I/home/icooke/.local/lib/python2.7/site-packages/numpy/core/include -I/usr/include/gdal -I/usr/include/python2.7 -c gippy/gippy_wrap.cpp -o build/temp.linux-x86_64-2.7/gippy/gippy_wrap.o -fPIC -std=c++11 -DBOOST_LOG_DYN_LINK
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++
gippy/gippy_wrap.cpp: In function ‘PyObject* _wrap_new_GeoImages(PyObject*, PyObject*)’:
gippy/gippy_wrap.cpp:4765:61: warning: ‘argv[0]’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  return traits_asptr_stdseq<std::vector<T> >::asptr(obj, vec);
                                                             ^
gippy/gippy_wrap.cpp:28262:13: note: ‘argv[0]’ was declared here
   PyObject *argv[2];
             ^
gippy/gippy_wrap.cpp: In function ‘PyObject* _wrap_new_mapss(PyObject*, PyObject*)’:
gippy/gippy_wrap.cpp:5295:4: warning: ‘argv[0]’ may be used uninitialized in this function [-Wmaybe-uninitialized]
    res = SWIG_ConvertPtr(obj,(void**)&p,swig::type_info<map_type>(),0);
    ^
gippy/gippy_wrap.cpp:11317:13: note: ‘argv[0]’ was declared here
   PyObject *argv[2];
             ^
c++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-Bsymbolic-functions -Wl,-z,relro -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -Wl,-Bsymbolic-functions -Wl,-z,relro -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security build/temp.linux-x86_64-2.7/gippy/gippy_wrap.o -Lbuild/lib.linux-x86_64-2.7/gippy -lgip -lgdal -lboost_system -lboost_filesystem -lboost_log -lpthread -o build/lib.linux-x86_64-2.7/gippy/_gippy.so
building 'gippy/_tests' extension
swigging gippy/tests.i to gippy/tests_wrap.cpp
swig -python -c++ -w509 -IGIP -o gippy/tests_wrap.cpp gippy/tests.i
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -IGIP -I/home/icooke/.local/lib/python2.7/site-packages/numpy/core/include -I/usr/include/gdal -I/usr/include/python2.7 -c gippy/tests_wrap.cpp -o build/temp.linux-x86_64-2.7/gippy/tests_wrap.o -fPIC -std=c++11 -DBOOST_LOG_DYN_LINK
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++
gippy/tests_wrap.cpp: In function ‘PyObject* _wrap_new_GeoImages(PyObject*, PyObject*)’:
gippy/tests_wrap.cpp:4758:61: warning: ‘argv[0]’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  return traits_asptr_stdseq<std::vector<T> >::asptr(obj, vec);
                                                             ^
gippy/tests_wrap.cpp:28243:13: note: ‘argv[0]’ was declared here
   PyObject *argv[2];
             ^
gippy/tests_wrap.cpp: In function ‘PyObject* _wrap_new_mapss(PyObject*, PyObject*)’:
gippy/tests_wrap.cpp:5288:4: warning: ‘argv[0]’ may be used uninitialized in this function [-Wmaybe-uninitialized]
    res = SWIG_ConvertPtr(obj,(void**)&p,swig::type_info<map_type>(),0);
    ^
gippy/tests_wrap.cpp:11298:13: note: ‘argv[0]’ was declared here
   PyObject *argv[2];
             ^
c++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-Bsymbolic-functions -Wl,-z,relro -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -Wl,-Bsymbolic-functions -Wl,-z,relro -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security build/temp.linux-x86_64-2.7/gippy/tests_wrap.o -Lbuild/lib.linux-x86_64-2.7/gippy -lgip -lgdal -lboost_system -lboost_filesystem -lboost_log -lpthread -o build/lib.linux-x86_64-2.7/gippy/_tests.so
building 'gippy/_algorithms' extension
swigging gippy/algorithms.i to gippy/algorithms_wrap.cpp
swig -python -c++ -w509 -IGIP -o gippy/algorithms_wrap.cpp gippy/algorithms.i
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -IGIP -I/home/icooke/.local/lib/python2.7/site-packages/numpy/core/include -I/usr/include/gdal -I/usr/include/python2.7 -c gippy/algorithms_wrap.cpp -o build/temp.linux-x86_64-2.7/gippy/algorithms_wrap.o -fPIC -std=c++11 -DBOOST_LOG_DYN_LINK
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++
gippy/algorithms_wrap.cpp: In function ‘PyObject* _wrap_new_GeoImages(PyObject*, PyObject*)’:
gippy/algorithms_wrap.cpp:4757:61: warning: ‘argv[0]’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  return traits_asptr_stdseq<std::vector<T> >::asptr(obj, vec);
                                                             ^
gippy/algorithms_wrap.cpp:28258:13: note: ‘argv[0]’ was declared here
   PyObject *argv[2];
             ^
gippy/algorithms_wrap.cpp: In function ‘PyObject* _wrap_new_mapss(PyObject*, PyObject*)’:
gippy/algorithms_wrap.cpp:5287:4: warning: ‘argv[0]’ may be used uninitialized in this function [-Wmaybe-uninitialized]
    res = SWIG_ConvertPtr(obj,(void**)&p,swig::type_info<map_type>(),0);
    ^
gippy/algorithms_wrap.cpp:11313:13: note: ‘argv[0]’ was declared here
   PyObject *argv[2];
             ^
c++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-Bsymbolic-functions -Wl,-z,relro -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -Wl,-Bsymbolic-functions -Wl,-z,relro -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security build/temp.linux-x86_64-2.7/gippy/algorithms_wrap.o -Lbuild/lib.linux-x86_64-2.7/gippy -lgip -lgdal -lboost_system -lboost_filesystem -lboost_log -lpthread -o build/lib.linux-x86_64-2.7/gippy/_algorithms.so
running install
module <setuptools.extension.Extension instance at 0x7f3ae522d2d8> /usr/local/lib/python2.7/dist-packages/gippy
module <setuptools.extension.Extension instance at 0x7f3ae37236c8> /usr/local/lib/python2.7/dist-packages/gippy
module <setuptools.extension.Extension instance at 0x7f3ae3723758> /usr/local/lib/python2.7/dist-packages/gippy
module <setuptools.extension.Extension instance at 0x7f3ae3723a70> /usr/local/lib/python2.7/dist-packages/gippy
running build_ext
running build
running build_py
copying gippy/tests.py -> build/lib.linux-x86_64-2.7/gippy
copying gippy/algorithms.py -> build/lib.linux-x86_64-2.7/gippy
copying gippy/gippy.py -> build/lib.linux-x86_64-2.7/gippy
running install_lib
creating /usr/local/lib/python2.7/dist-packages/gippy
copying build/lib.linux-x86_64-2.7/gippy/tests.py -> /usr/local/lib/python2.7/dist-packages/gippy
copying build/lib.linux-x86_64-2.7/gippy/version.py -> /usr/local/lib/python2.7/dist-packages/gippy
copying build/lib.linux-x86_64-2.7/gippy/__init__.py -> /usr/local/lib/python2.7/dist-packages/gippy
copying build/lib.linux-x86_64-2.7/gippy/libgip.so -> /usr/local/lib/python2.7/dist-packages/gippy
copying build/lib.linux-x86_64-2.7/gippy/algorithms.py -> /usr/local/lib/python2.7/dist-packages/gippy
copying build/lib.linux-x86_64-2.7/gippy/gippy.py -> /usr/local/lib/python2.7/dist-packages/gippy
copying build/lib.linux-x86_64-2.7/gippy/_algorithms.so -> /usr/local/lib/python2.7/dist-packages/gippy
copying build/lib.linux-x86_64-2.7/gippy/_gippy.so -> /usr/local/lib/python2.7/dist-packages/gippy
copying build/lib.linux-x86_64-2.7/gippy/_tests.so -> /usr/local/lib/python2.7/dist-packages/gippy
byte-compiling /usr/local/lib/python2.7/dist-packages/gippy/tests.py to tests.pyc
byte-compiling /usr/local/lib/python2.7/dist-packages/gippy/version.py to version.pyc
byte-compiling /usr/local/lib/python2.7/dist-packages/gippy/__init__.py to __init__.pyc
byte-compiling /usr/local/lib/python2.7/dist-packages/gippy/algorithms.py to algorithms.pyc
byte-compiling /usr/local/lib/python2.7/dist-packages/gippy/gippy.py to gippy.pyc
running install_egg_info
running egg_info
creating gippy.egg-info
writing gippy.egg-info/PKG-INFO
writing top-level names to gippy.egg-info/top_level.txt
writing dependency_links to gippy.egg-info/dependency_links.txt
writing manifest file 'gippy.egg-info/SOURCES.txt'
reading manifest file 'gippy.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
writing manifest file 'gippy.egg-info/SOURCES.txt'
Copying gippy.egg-info to /usr/local/lib/python2.7/dist-packages/gippy-0.3.3.egg-info
running install_scripts
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "gippy/__init__.py", line 23, in <module>
    from gippy import *
  File "gippy/gippy.py", line 32, in <module>
    _gippy = swig_import_helper()
  File "gippy/gippy.py", line 24, in swig_import_helper
    import _gippy
ImportError: No module named _gippy

Numpy array to CImg conversion

Assumes data types are the same, which is usually valid. However a user could pass in a numpy array to a function expecting a CImg of another type. GIPPY should automatically convert (just as it does when going CImg -> numpy)

pythonize function names

function names to be changed to match common python style of all lowercase and underscores. This is not without precedent, as all of the GeoRaster CImg functions (eg cos, sqrt, pow) are lower case.

This will make things even more backward incompatible, but there's already significant changes to 0.4, and changes in the future will be much more difficult since gippy is to be used in sat-utils and thus will be more widely used.

Check if the library works on Windows

improve error handling

Improve error handling, specifically reporting when invalid input parameters passed

Write tests for GeoImage

Indices return a GeoImage instead of a gippy.algorithms.mapss

remove boost dependencies

c++11 and c++14 introduce new features that often replace the boost libraries (in many cases, incorporating the boost implementation). Boost is a rather large set of packages, and looks not much is lost by moving away from it and making gippy more portable.

• fileystem functionality isn't really used internally much at all, so can safely be removed (just use string instead).
• shared_ptr: c++11 implements smart_ptr and direct replacement for boosts shared_ptr
• boost logging wasn't really used (implementation was started, but never finished) so can be safely removed
• boost bind for dynamic binding of functions: this is the tricky part, however c++11 lambda functions may prove to not only be a replacement, but also be a better implementation which will make it easier to implement #2

SetBandNames

Add function taking in vector (python list) of all band names in sequential order

Search for geovector feature by attribute

In Python I am manually searching through features to find the one I want:

def find_geometry(self, attribute, value):
    for fid in self.get_fids():
        feature = self.get_geom(fid)
        if value == self.get_attribute(fid, attribute):
            return self.get_geom(fid)
    return None

But I'm wondering if it's possible to do this more efficiently within gippy.

get osx version to work

This involves fixing wrong boost symbols. And potentially fixing linking. Helpful links:

conda/conda-build#279
https://github.com/conda/conda-build/blob/e8587bb49d47b1255d6137b273b45b94b71fb4e7/conda_build/post.py#L151
http://qin.laya.com/tech_coding_help/dylib_linking.html
http://stackoverflow.com/questions/19123623/python-runtime-library-dirs-doesnt-work-on-mac

better error handling when failed process

If input file corrupt (e.g., bad landsat tar file), it appears to complete processing without reporting an error.

Indices have the option of not saving the output to a file

Make container objects iterable

Defining getitem to be the same as operator[] is not enough. A for loop over a wrapped container will just enter an infinite loop.

See here:
http://stackoverflow.com/questions/8776328/swig-interfacing-c-library-to-python-creating-iterable-python-data-type-from

Container objects include ChunkSet (holding Rect objects) and GeoImage (holding GeoRaster objects)

Add warp option to GeoImage.Save()

Should accept any valid CRS string

binary operations

Allow CImg chaining of binary operations (i.e. those that take in two images rather than an image and a scalar).

GeoImage functions: new vs inplace

The convention for operations on a raster is that a new raster gets returned with the operation chained to it. Thus:

newband = band * 5

where (band * 5) returns a new GeoRaster with a x5 function added to it's chain.

In contrast, some GeoImage functions (eg AddMask) actually operate on *this, which is then returned. This is not consistent.

I think the best way is to always return a new object, that way any previous references will still contain the original GeoImage without the processing applied, which would be desirable.

Somewhat related is the various Set functions: SetGain, SetBandNames which return void and operate on *this as well, however I think with a 'Set' functions this would be the expected behavior. Although, at least returning *this from these would allow those functions to be included in a chain, e.g.,

image2 = image.SetGain(1.0).autoscale(args)

Python 3 compatiblity

Here is the error: https://travis-ci.org/sat-utils/sat-process/jobs/124310527#L419

Color indexing should be case insensitive

Currently expects in all uppercase. Should allow any mixing of case.

GeoVector where/ SQL problem

mcorbier wrote:

mcorbier@rio:/titan/work/mcorbiere/geokit$ gips_project daymet -s gadmn2_vtnh.shp -d 2010 --days 100,105 -k OBJECTID -p tmax -w "HASC_1=US.NH"

GIPS Data Project (v0.8.0rc6) Data Project error: GeoVector_where() takes exactly 3 arguments (2 given)

The -w clause needs 3 arguments, which is not possible to write on the command line as far as I can tell. The new version of GIPS also does not allow for anything other than an =, making it less useful than the old sql string version.mcorbier@rio:/titan/work/mcorbiere/geokit$ gips_project daymet -s gadmn2_vtnh.shp -d 2010 --days 100,105 -k OBJECTID -p tmax -w "HASC_1=US.NH" GIPS Data Project (v0.8.0rc6) Data Project error: GeoVector_where() takes exactly 3 arguments (2 given)

The -w clause needs 3 arguments, which is not possible to write on the command line as far as I can tell. The new version also does not allow for anything other than an =, making it less useful than the old sql string version.

set band name on output image followed by Process

If creating an initial output image which is then the target of a Process() command:

imgin.Process(imgout)

The band names are written over. Behavior should be reconsidered.

support multiple files in created files

When creating a new output file, there should be some way to create it so that each band is a separate file.

Add GeoVector

Need GeoVector class for better handling of vector layers

cleanup algorithms

gippy algorithms should only be algos that are complex, such as ACCA, Fmask, k-means, etc.

More simple ones, BrowseImage, SpectralStatistics should become members of GeoImage.

Indices will hopefully be obsolete at some point, since #2 if implemented will allow index calculation directly with python syntax.

Rect width/height methods assume grid spacing of 1

as discussed with @matthewhanson -- the width being

p1.x - p0.x + 1 

properly computes the width for a pixel grid where the spacing is 1. But if the spacing is not 1 (call it res), then this will be res - 1 short of the actual width.

allow specify affine when creating new

When creating a new image, the srs can be specified, but should also be allowed to specify an affine...or, at least, a corner coordinate and resolution (size already given)....

Add debian packaging

To make installation of dependencies much easier

add travis tests for OSX and Ubuntu 14

TemporalImages

Finish TemporalImages class, using a date* as a band identifier

*initial method is to support an integer as the date - because dates are often just a year, or a day of year.

verify installation via PyPi

A beta version should be uploaded to PyPi and installation tested on both mac and linux, both in and outside a virtual environment, and in both install or develop mode.

Additionally, a binary wheel distribution for mac should be considered.

Add SetRGB method to GeoImage

GIP/gip/GeoResource.h:32:28: fatal error: gdal/gdal_priv.h: No such file or directory

I am using GDAL version 1.11.2 and gdal_priv.h is located at ./gdal1.11.2/gcore/gdal_priv.h. When I compile gippy, I get this compiler error:

~/dev/gis/gippy$ python setup.py build
running build
running build_py
creating build
creating build/lib.linux-x86_64-2.7
creating build/lib.linux-x86_64-2.7/gippy
copying gippy/version.py -> build/lib.linux-x86_64-2.7/gippy
copying gippy/init.py -> build/lib.linux-x86_64-2.7/gippy
running build_ext
building 'gippy/libgip' extension
creating build/temp.linux-x86_64-2.7
creating build/temp.linux-x86_64-2.7/GIP
x86_64-linux-gnu-gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -IGIP -I/usr/include/python2.7 -c GIP/GeoImage.cpp -o build/temp.linux-x86_64-2.7/GIP/GeoImage.o -std=c++11 -O3 -DBOOST_LOG_DYN_LINK
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++ [enabled by default]
In file included from GIP/gip/GeoImage.h:25:0,
from GIP/GeoImage.cpp:22:
GIP/gip/GeoResource.h:32:28: fatal error: gdal/gdal_priv.h: No such file or directory
#include <gdal/gdal_priv.h>
^
compilation terminated.
error: command 'x86_64-linux-gnu-gcc' failed with exit status 1

commit swig wrappers

Try to commit swig generated wrappers to repo to see if they work across both linux and mac.

ACCA Implementation

need to implement snow and desert masks

Also add automatic object-based shadow mask

python setup.py error

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "gippy/__init__.py", line 23, in <module>
    from gippy import *
  File "gippy/gippy.py", line 30, in <module>
    _gippy = swig_import_helper()
  File "gippy/gippy.py", line 22, in swig_import_helper
    import _gippy
ImportError: No module named _gippy

GeoImage constructor allow options

add keyword support in Python bindings.

Biggest problem here is that keyword argument support is incompatible with overloaded operators, so to have keywords in python:

1. in the C++ code an additional function added that can handle all versions of the overloaded operator

2. somehow ignore the other versions and only wrap the single function

Perhaps the best way to handle this is to create the additional function using %extend in the swig wrappers themselves.

Make GeoImage::Write more flexible

So that it can accept an array that is either

B x 1 x X x Y
-or-
B x X x Y

Wrap Point object in SWIG

Also check for any other unwrapped classes

Setting NoData before Description causes Description to not get written

Creating a new image and setting NoData prior to setting the a band description causes it to not write the band description.

Add scale option to GoeImage.Save()

Use case: convert UInt16 to UInt8

documentation for pythonhosted

update documentation to work on pythonhosted.

C++ scoped enums

The new c++0x standard supports scoped enumerators. Implement enums (e.g., UNITS, DATATYPES) as scoped...should carry through swig to python API. This way enums won't just appear in the global namespace, they will be grouped under the enum type name

Improve readme

It should include:

• Installation Guide
• Test guide
• Todo list
• etc.

support GDAL SetGeotransform or equivalent

I typically construct geo-image data by specifying an array, a projection, and a geotransform. This could be handled in gippy with the existing constructors if there was a method to set the geotransform (as in GDAL), or separate methods to set spatial resolution, and UL X and Y coordinates.

standardize algorithm function signature

Algorithms should be standardized to have a function signature like:

algorithm(geoimage, output_filename, options)

Where options is either a string dictionary of options (map<string, string>) or it's own C++ options class with a swig typemap added that can convert from a python dictionary into an instance of that class.

output format option

When saving a file (GeoImage::save) or creating a new one (GeoImage::create or GeoImage::create_from) allow optional parameter for format.

multiple resolutions

Gippy does not currently check that all bands have the same resolution (size, extent). So right now, if gippy.test.get_test_image is used on the Sentinel scene it will fail when it tries to read.

There should be checks, or some way to handle multiple resolutions.

RGB image appears as Black and White on OSX

RGB images saved with GeoImage.save() appears black and white on Mac's preview app. QGIS correctly shows the colored image.

Wheels fail on Mac OSX

Installation is successful but wheels fail to be created.

traceback:

  running bdist_wheel
  running build_ext
  building 'gippy/_gippy' extension
  creating build
  creating build/temp.macosx-10.11-x86_64-2.7
  creating build/temp.macosx-10.11-x86_64-2.7/gippy
  clang -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -IGIP -I/Users/ajdevseed/.virtualenvs/sat-process-py2/lib/python2.7/site-packages/numpy/core/include -I/usr/local/Cellar/gdal/1.11.3_1/include -I/Users/ajdevseed/.pyenv/versions/2.7.11/include/python2.7 -c gippy/gippy_wrap.cpp -o build/temp.macosx-10.11-x86_64-2.7/gippy/gippy_wrap.o -fPIC -O3 -std=c++11 -stdlib=libc++ -mmacosx-version-min=10.8 -Wno-absolute-value -Wno-shift-negative-value -Wno-parentheses-equality -Wno-deprecated-declarations
  creating build/lib.macosx-10.11-x86_64-2.7
  creating build/lib.macosx-10.11-x86_64-2.7/gippy
  c++ -dynamiclib -undefined dynamic_lookup -L/usr/local/opt/readline/lib -L/usr/local/opt/readline/lib -L/usr/local/opt/openssl/lib -L/Users/ajdevseed/.pyenv/versions/2.7.11/lib build/temp.macosx-10.11-x86_64-2.7/gippy/gippy_wrap.o -L/usr/local/Cellar/gdal/1.11.3_1/lib -L./ -lgip -lpthread -lgdal -o build/lib.macosx-10.11-x86_64-2.7/gippy/_gippy.so -stdlib=libc++ -mmacosx-version-min=10.8
  ld: library not found for -lgip
  clang: error: linker command failed with exit code 1 (use -v to see invocation)
  error: command 'c++' failed with exit status 1

  ----------------------------------------
  Failed building wheel for gippy
  Running setup.py clean for gippy
Failed to build gippy
Installing collected packages: gippy
  Running setup.py install for gippy ... done
Successfully installed gippy-1.0.0b1

The error is very similar to the one in Python3