Indexing in VRT.set_offset_size #264
Labels
Comments
|
It is not related to indexing of bands but to names of axes: 'x' or 'y'. |
|
@mortenwh please check the pull request |
akorosov
added a commit
that referenced
this issue
Jul 18, 2018
* #251 close issue * add dev * #272 update conventions * #272 account for comment in #239 * #272 update conventions * #272 update conventions * #264 extend docstring * #91 add tests for VRT * #91 increase test coverage for node * #91 fix according to PR comments * #212 remove cfunits; setup: move numpy, gdal to REQS * #212 remove check of numpy and gdal * #313 add Vagrantfile and provisioning * set libnetcdf version for Vagrant * #331: Modified nansat_test_base.py * #331: clean up in nansat_test_base.py * #329: Added section following suggestions in issue description * Added info about forking and noted that hotfix is generally done by team members * #329: more info on handling forks * #329: Changed text in conventions according to reviews * #336 update docs * Update release_nansat.rst * Update release_nansat.rst * Issue325 mock missing install nansat readme (#340) * add .vagrant to gitignore * "#325: README.rst new install proc. added new Test section (nose mock)" * "#325: README.rst spelling" * Updated README.rst according to comments and, changed section 'Usage' to 'Activate and work in the nansat environment' (too long?), and, also switched the link to the "wiki" page in the bottom to a link to Read the Docs! * empty commit to fix failed Travis CI check? * travis.yml: libnetcdf no pinning * #340: Modified installation.rst according to comments * Added to conda create missing: nansat * Developed method returns border geometry in geojson format * Developed for the geometry to geojson method * #345 remove obsolote function parameters and NansatFutureWarning calls * #345 move basemap checks to test_tools * #345 #347 fix reproject_GCPs
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
How is indexing in the
VRT.set_offset_sizemethod? Since gdal indices start at 1 (at least for band numbers), I think we should clarify this question in the docstring...The text was updated successfully, but these errors were encountered: