Re: [gdal-dev] Call for discussion on RFC 83: guidelines for the use of GDAL project sponsorship

[Even Rouault]

Hi,

are there any remaining comments before we put that to vote ?

Even

Le 19/05/2021 à 14:46, Even Rouault a écrit :

Hi,

in parallel to finalizing the last steps to get the relationship with 
NumFOCUS fully operational, here's a new RFC for your consideration to 
give guidelines on how we can use the sponsorship funds, who can 
apply, etc. Input welcome.


https://github.com/OSGeo/gdal/pull/3855

Even


--
http://www.spatialys.com
My software is free, but my time generally not.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Tons of errors in tests

[Javier Jimenez Shaw]

Hello

I am trying to build GDAL (this worked) and run the tests (tons of
failures). Because it is over a clean clone of master, I think there is
something wrong in my configuration. Maybe you can help me.

OS: Ubuntu 20.04
Python: 3.8.5
$ apt list --installed | grep gdal
gdal-bin/focal,now 3.0.4+dfsg-1build3 amd64 [installed]
gdal-data/focal,focal,now 3.0.4+dfsg-1build3 all [installed,automatic]
libgdal-dev/focal,now 3.0.4+dfsg-1build3 amd64 [installed]
libgdal26/focal,now 3.0.4+dfsg-1build3 amd64 [installed,automatic]
python3-gdal/focal,now 3.0.4+dfsg-1build3 amd64 [installed,automatic]

Following the instructions in
https://github.com/OSGeo/gdal/blob/master/CONTRIBUTING.md

cd gdal
./configure
make -j8 -s
cd apps; make -s test_ogrsf; cd ..

. scripts/setdevenv.sh
gdalinfo --version
$ GDAL 3.4.0dev-6b8835c2b5, released 2021/06/02

cd ../autotest
pip install -r requirements.txt

python -m pytest
Test session starts (platform: linux, Python 3.8.5, pytest 4.6.9,
pytest-sugar 0.9.4)
rootdir: /home/jshaw/work/gdal/autotest, inifile: pytest.ini, testpaths:
ogr, gcore, gdrivers, osr, alg, gnm, utilities, pyscripts
plugins: sugar-0.9.4, env-0.6.2
collecting ...
―――
ERROR collecting gcore/multidim.py

gcore/multidim.py:106: in 
???
E   AttributeError: module 'osgeo.gdal' has no attribute 'GRIORA_RMS'

―――
ERROR collecting alg/fillnodata.py

/usr/lib/python3/dist-packages/pluggy/hooks.py:286: in __call__
return self._hookexec(self, self.get_hookimpls(), kwargs)
/usr/lib/python3/dist-packages/pluggy/manager.py:92: in _hookexec
return self._inner_hookexec(hook, methods, kwargs)
/usr/lib/python3/dist-packages/pluggy/manager.py:83: in 
self._inner_hookexec = lambda hook, methods, kwargs: hook.multicall(
/usr/lib/python3/dist-packages/_pytest/python.py:234: in
pytest_pycollect_makeitem
res = list(collector._genfunctions(name, obj))
/usr/lib/python3/dist-packages/_pytest/python.py:410: in _genfunctions
self.ihook.pytest_generate_tests(metafunc=metafunc)
/usr/lib/python3/dist-packages/pluggy/hooks.py:286: in __call__
return self._hookexec(self, self.get_hookimpls(), kwargs)
/usr/lib/python3/dist-packages/pluggy/manager.py:92: in _hookexec
return self._inner_hookexec(hook, methods, kwargs)
/usr/lib/python3/dist-packages/pluggy/manager.py:83: in 
self._inner_hookexec = lambda hook, methods, kwargs: hook.multicall(
/usr/lib/python3/dist-packages/_pytest/python.py:137: in
pytest_generate_tests
metafunc.parametrize(*marker.args, **marker.kwargs)
/usr/lib/python3/dist-packages/_pytest/python.py:1015: in parametrize
ids = self._resolve_arg_ids(argnames, ids, parameters,
item=self.definition)
/usr/lib/python3/dist-packages/_pytest/python.py:1069: in _resolve_arg_ids
ids = idmaker(argnames, parameters, idfn, ids, self.config, item=item)
/usr/lib/python3/dist-packages/_pytest/python.py:1221: in idmaker
ids = [
/usr/lib/python3/dist-packages/_pytest/python.py:1222: in 
_idvalset(valindex, parameterset, argnames, idfn, ids, config=config,
item=item)
/usr/lib/python3/dist-packages/_pytest/python.py:1210: in _idvalset
if ids is None or (idx >= len(ids) or ids[idx] is None):
E   TypeError: 'dict_keys' object is not subscriptable

――
ERROR collecting pyscripts/test_gdal_utils.py
――
ImportError while importing test module
'/home/jshaw/work/gdal/autotest/pyscripts/test_gdal_utils.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
pyscripts/test_gdal_utils.py:37: in 
from osgeo_utils.auxiliary.extent_util import Extent
E   ModuleNotFoundError: No module named 'osgeo_utils'

―
ERROR collecting pyscripts/test_pct.py
――
ImportError while importing test module
'/home/jshaw/work/gdal/autotest/pyscripts/test_pct.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
pyscripts/test_pct.py:37: in 
from osgeo_utils import gdalattachpct, rgb2pct
E   ModuleNotFoundError: No module named 'osgeo_utils'

――― ERROR
collecting pyscripts/gdal2tiles/test_add_alpha_band_to_string_vrt.py

ImportError while importing test module
'/home/jshaw/work/gdal/autotest/pyscripts/gdal2tiles/test_add_alpha_band_to_string_vrt.py'.
Hint: make sure your test modules/packages have valid Python name

Re: [gdal-dev] Tons of errors in tests

[Andrew C Aitchison]

On Wed, 2 Jun 2021, Javier Jimenez Shaw wrote:


Hello

I am trying to build GDAL (this worked) and run the tests (tons of
failures). Because it is over a clean clone of master, I think there is
something wrong in my configuration. Maybe you can help me.




cd ../autotest
pip install -r requirements.txt

python -m pytest
Test session starts (platform: linux, Python 3.8.5, pytest 4.6.9,
pytest-sugar 0.9.4)


I have Ubuntu 21.04/hirsute:
(platform: linux, Python 3.9.5, pytest 6.2.3, pytest-sugar 0.9.4)

4.69 to 6.2.3 is quite a jump in pytest. Is it a python2 or a python3 pytest ?
GDAL is now python 3.

When I started running the autotests recently, I discovered that the
python3 pytest is
/usr/bin/pytest-3
not
/usr/bin/pytest

Assuming this is your problem too,
you could change autotest/GNUmakefile;
I just sym-linked pytest-3 to pytest


OS: Ubuntu 20.04
Python: 3.8.5
$ apt list --installed | grep gdal
gdal-bin/focal,now 3.0.4+dfsg-1build3 amd64 [installed]
gdal-data/focal,focal,now 3.0.4+dfsg-1build3 all [installed,automatic]
libgdal-dev/focal,now 3.0.4+dfsg-1build3 amd64 [installed]
libgdal26/focal,now 3.0.4+dfsg-1build3 amd64 [installed,automatic]
python3-gdal/focal,now 3.0.4+dfsg-1build3 amd64 [installed,automatic]

Following the instructions in
https://github.com/OSGeo/gdal/blob/master/CONTRIBUTING.md

cd gdal
./configure
make -j8 -s
cd apps; make -s test_ogrsf; cd ..

. scripts/setdevenv.sh
gdalinfo --version
$ GDAL 3.4.0dev-6b8835c2b5, released 2021/06/02

cd ../autotest
pip install -r requirements.txt

python -m pytest
Test session starts (platform: linux, Python 3.8.5, pytest 4.6.9,
pytest-sugar 0.9.4)


--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Tons of errors in tests

[Even Rouault]

Javier,

CONTRIBUTING.md was missing the --with-python configure switch to build 
the python bindings. Now fixed


So re-run ./configure --with-python && make -j8 -s , and also source 
again ". scripts/setdevenv.sh" so that PYTHONPATH is set appropriately


You can check that everything is OK with:

python -c "from osgeo import gdal; print(gdal.__version__)"

Even


Le 02/06/2021 à 16:26, Javier Jimenez Shaw a écrit :

Hello

I am trying to build GDAL (this worked) and run the tests (tons of 
failures). Because it is over a clean clone of master, I think there 
is something wrong in my configuration. Maybe you can help me.


OS: Ubuntu 20.04
Python: 3.8.5
$ apt list --installed | grep gdal
gdal-bin/focal,now 3.0.4+dfsg-1build3 amd64 [installed]
gdal-data/focal,focal,now 3.0.4+dfsg-1build3 all [installed,automatic]
libgdal-dev/focal,now 3.0.4+dfsg-1build3 amd64 [installed]
libgdal26/focal,now 3.0.4+dfsg-1build3 amd64 [installed,automatic]
python3-gdal/focal,now 3.0.4+dfsg-1build3 amd64 [installed,automatic]

Following the instructions in 
https://github.com/OSGeo/gdal/blob/master/CONTRIBUTING.md 



cd gdal
./configure
make -j8 -s
cd apps; make -s test_ogrsf; cd ..

. scripts/setdevenv.sh
gdalinfo --version
$ GDAL 3.4.0dev-6b8835c2b5, released 2021/06/02

cd ../autotest
pip install -r requirements.txt

python -m pytest
Test session starts (platform: linux, Python 3.8.5, pytest 4.6.9, 
pytest-sugar 0.9.4)
rootdir: /home/jshaw/work/gdal/autotest, inifile: pytest.ini, 
testpaths: ogr, gcore, gdrivers, osr, alg, gnm, utilities, pyscripts

plugins: sugar-0.9.4, env-0.6.2
collecting ...
――― 
ERROR collecting gcore/multidim.py 


gcore/multidim.py:106: in 
    ???
E   AttributeError: module 'osgeo.gdal' has no attribute 'GRIORA_RMS'

――― 
ERROR collecting alg/fillnodata.py 


/usr/lib/python3/dist-packages/pluggy/hooks.py:286: in __call__
    return self._hookexec(self, self.get_hookimpls(), kwargs)
/usr/lib/python3/dist-packages/pluggy/manager.py:92: in _hookexec
    return self._inner_hookexec(hook, methods, kwargs)
/usr/lib/python3/dist-packages/pluggy/manager.py:83: in 
    self._inner_hookexec = lambda hook, methods, kwargs: hook.multicall(
/usr/lib/python3/dist-packages/_pytest/python.py:234: in 
pytest_pycollect_makeitem

    res = list(collector._genfunctions(name, obj))
/usr/lib/python3/dist-packages/_pytest/python.py:410: in _genfunctions
    self.ihook.pytest_generate_tests(metafunc=metafunc)
/usr/lib/python3/dist-packages/pluggy/hooks.py:286: in __call__
    return self._hookexec(self, self.get_hookimpls(), kwargs)
/usr/lib/python3/dist-packages/pluggy/manager.py:92: in _hookexec
    return self._inner_hookexec(hook, methods, kwargs)
/usr/lib/python3/dist-packages/pluggy/manager.py:83: in 
    self._inner_hookexec = lambda hook, methods, kwargs: hook.multicall(
/usr/lib/python3/dist-packages/_pytest/python.py:137: in 
pytest_generate_tests

    metafunc.parametrize(*marker.args, **marker.kwargs)
/usr/lib/python3/dist-packages/_pytest/python.py:1015: in parametrize
    ids = self._resolve_arg_ids(argnames, ids, parameters, 
item=self.definition)

/usr/lib/python3/dist-packages/_pytest/python.py:1069: in _resolve_arg_ids
    ids = idmaker(argnames, parameters, idfn, ids, self.config, item=item)
/usr/lib/python3/dist-packages/_pytest/python.py:1221: in idmaker
    ids = [
/usr/lib/python3/dist-packages/_pytest/python.py:1222: in 
    _idvalset(valindex, parameterset, argnames, idfn, ids, 
config=config, item=item)

/usr/lib/python3/dist-packages/_pytest/python.py:1210: in _idvalset
    if ids is None or (idx >= len(ids) or ids[idx] is None):
E   TypeError: 'dict_keys' object is not subscriptable

―― 
ERROR collecting pyscripts/test_gdal_utils.py 
――
ImportError while importing test module 
'/home/jshaw/work/gdal/autotest/pyscripts/test_gdal_utils.py'.

Hint: make sure your test modules/packages have valid Python names.
Traceback:
pyscripts/test_gdal_utils.py:37: in 
    from osgeo_utils.auxiliary.extent_util import Extent
E   ModuleNotFoundError: No module named 'osgeo_utils'

― 
ERROR collecting pyscripts/test_pct.py 
――
ImportError while importing test module 
'/home/jshaw/work/gdal/autotest/pyscripts/test_pct.py'.

Hint: make sure your test modules/packages have valid Python names.
Traceback:
pyscripts/test_pct.py:3

Re: [gdal-dev] Tons of errors in tests

[Javier Jimenez Shaw]

Thanks Even and Andrew for your answers.

Andrew, somehow I had a workaround for the pytest-3 (that I absolutely
forgot), but thanks for the info.

Even, with the "--with-python" everything goes much better...
Now I can run tiff tests without any failure!
pytest gcore/tiff_*

However, if I run the full test suite, it fails collecting alg/fillnodata.py
(I work it around with "pytest --continue-on-collection-errors")

$ pytest
Test session starts (platform: linux, Python 3.8.5, pytest 4.6.9,
pytest-sugar 0.9.4)
rootdir: /home/jshaw/work/gdal/autotest, inifile: pytest.ini, testpaths:
ogr, gcore, gdrivers, osr, alg, gnm, utilities, pyscripts
plugins: sugar-0.9.4, env-0.6.2
collecting ...
―――
ERROR collecting alg/fillnodata.py

/usr/lib/python3/dist-packages/pluggy/hooks.py:286: in __call__
return self._hookexec(self, self.get_hookimpls(), kwargs)
/usr/lib/python3/dist-packages/pluggy/manager.py:92: in _hookexec
return self._inner_hookexec(hook, methods, kwargs)
/usr/lib/python3/dist-packages/pluggy/manager.py:83: in 
self._inner_hookexec = lambda hook, methods, kwargs: hook.multicall(
/usr/lib/python3/dist-packages/_pytest/python.py:234: in
pytest_pycollect_makeitem
res = list(collector._genfunctions(name, obj))
/usr/lib/python3/dist-packages/_pytest/python.py:410: in _genfunctions
self.ihook.pytest_generate_tests(metafunc=metafunc)
/usr/lib/python3/dist-packages/pluggy/hooks.py:286: in __call__
return self._hookexec(self, self.get_hookimpls(), kwargs)
/usr/lib/python3/dist-packages/pluggy/manager.py:92: in _hookexec
return self._inner_hookexec(hook, methods, kwargs)
/usr/lib/python3/dist-packages/pluggy/manager.py:83: in 
self._inner_hookexec = lambda hook, methods, kwargs: hook.multicall(
/usr/lib/python3/dist-packages/_pytest/python.py:137: in
pytest_generate_tests
metafunc.parametrize(*marker.args, **marker.kwargs)
/usr/lib/python3/dist-packages/_pytest/python.py:1015: in parametrize
ids = self._resolve_arg_ids(argnames, ids, parameters,
item=self.definition)
/usr/lib/python3/dist-packages/_pytest/python.py:1069: in _resolve_arg_ids
ids = idmaker(argnames, parameters, idfn, ids, self.config, item=item)
/usr/lib/python3/dist-packages/_pytest/python.py:1221: in idmaker
ids = [
/usr/lib/python3/dist-packages/_pytest/python.py:1222: in 
_idvalset(valindex, parameterset, argnames, idfn, ids, config=config,
item=item)
/usr/lib/python3/dist-packages/_pytest/python.py:1210: in _idvalset
if ids is None or (idx >= len(ids) or ids[idx] is None):
E   TypeError: 'dict_keys' object is not subscriptable

!
Interrupted: 1 errors during collection
!

Results (5.42s):

Cheers
.___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ...  ._ .__
Entre dos pensamientos racionales
hay infinitos pensamientos irracionales.



On Wed, 2 Jun 2021 at 17:38, Even Rouault 
wrote:

> Javier,
>
> CONTRIBUTING.md was missing the --with-python configure switch to build
> the python bindings. Now fixed
>
> So re-run ./configure --with-python && make -j8 -s , and also source again
> ". scripts/setdevenv.sh" so that PYTHONPATH is set appropriately
>
> You can check that everything is OK with:
>
> python -c "from osgeo import gdal; print(gdal.__version__)"
>
> Even
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Tons of errors in tests

[Even Rouault]

However, if I run the full test suite, it fails collecting 
alg/fillnodata.py

(I work it around with "pytest --continue-on-collection-errors")


The issue is that pytest 4.6.9 is too old. I've just bumped the min 
version to 6.0.0





$ pytest
Test session starts (platform: linux, Python 3.8.5, pytest 4.6.9, 
pytest-sugar 0.9.4)
rootdir: /home/jshaw/work/gdal/autotest, inifile: pytest.ini, 
testpaths: ogr, gcore, gdrivers, osr, alg, gnm, utilities, pyscripts

plugins: sugar-0.9.4, env-0.6.2
collecting ...
――― 
ERROR collecting alg/fillnodata.py 


/usr/lib/python3/dist-packages/pluggy/hooks.py:286: in __call__
    return self._hookexec(self, self.get_hookimpls(), kwargs)
/usr/lib/python3/dist-packages/pluggy/manager.py:92: in _hookexec
    return self._inner_hookexec(hook, methods, kwargs)
/usr/lib/python3/dist-packages/pluggy/manager.py:83: in 
    self._inner_hookexec = lambda hook, methods, kwargs: hook.multicall(
/usr/lib/python3/dist-packages/_pytest/python.py:234: in 
pytest_pycollect_makeitem

    res = list(collector._genfunctions(name, obj))
/usr/lib/python3/dist-packages/_pytest/python.py:410: in _genfunctions
    self.ihook.pytest_generate_tests(metafunc=metafunc)
/usr/lib/python3/dist-packages/pluggy/hooks.py:286: in __call__
    return self._hookexec(self, self.get_hookimpls(), kwargs)
/usr/lib/python3/dist-packages/pluggy/manager.py:92: in _hookexec
    return self._inner_hookexec(hook, methods, kwargs)
/usr/lib/python3/dist-packages/pluggy/manager.py:83: in 
    self._inner_hookexec = lambda hook, methods, kwargs: hook.multicall(
/usr/lib/python3/dist-packages/_pytest/python.py:137: in 
pytest_generate_tests

    metafunc.parametrize(*marker.args, **marker.kwargs)
/usr/lib/python3/dist-packages/_pytest/python.py:1015: in parametrize
    ids = self._resolve_arg_ids(argnames, ids, parameters, 
item=self.definition)

/usr/lib/python3/dist-packages/_pytest/python.py:1069: in _resolve_arg_ids
    ids = idmaker(argnames, parameters, idfn, ids, self.config, item=item)
/usr/lib/python3/dist-packages/_pytest/python.py:1221: in idmaker
    ids = [
/usr/lib/python3/dist-packages/_pytest/python.py:1222: in 
    _idvalset(valindex, parameterset, argnames, idfn, ids, 
config=config, item=item)

/usr/lib/python3/dist-packages/_pytest/python.py:1210: in _idvalset
    if ids is None or (idx >= len(ids) or ids[idx] is None):
E   TypeError: 'dict_keys' object is not subscriptable

! 
Interrupted: 1 errors during collection 
!


Results (5.42s):

Cheers
.___ ._ ..._ .. . ._. .___ .. __ . _. . __..  ...  ._ .__
Entre dos pensamientos racionales
hay infinitos pensamientos irracionales.



On Wed, 2 Jun 2021 at 17:38, Even Rouault > wrote:


Javier,

CONTRIBUTING.md was missing the --with-python configure switch to
build the python bindings. Now fixed

So re-run ./configure --with-python && make -j8 -s , and also
source again ". scripts/setdevenv.sh" so that PYTHONPATH is set
appropriately

You can check that everything is OK with:

python -c "from osgeo import gdal; print(gdal.__version__)"

Even


--
http://www.spatialys.com
My software is free, but my time generally not.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Call for discussion on RFC 83: guidelines for the use of GDAL project sponsorship

[Sean Gillies via gdal-dev]

Hi Even,

I've got two questions. I don't think they need answers before we vote, but
I'm curious if asking them leads to any useful discussion.

Will we strictly require project proposals to be submitted and approved
before work starts? Will we allow works in progress to apply for funding?

Should we address, in the text of the RFC, the possibility of conflicting
proposals? Should we limit the number of proposals per person/organization
to minimize conflicts?

> Applicants will provide the amount to be funded. Proposals may be put
together by one or several individuals (in the later case, to be determined
if we can let the team have a "invoicing point of contact" and let them
arrange how to dispatch it amongst members, or if each team member should
ask for its part of funding). An applicant may submit proposals for several
subjects.

On Wed, Jun 2, 2021 at 6:02 AM Even Rouault 
wrote:

> Hi,
>
> are there any remaining comments before we put that to vote ?
>
> Even
>
> Le 19/05/2021 à 14:46, Even Rouault a écrit :
> > Hi,
> >
> > in parallel to finalizing the last steps to get the relationship with
> > NumFOCUS fully operational, here's a new RFC for your consideration to
> > give guidelines on how we can use the sponsorship funds, who can
> > apply, etc. Input welcome.
> >
> > https://github.com/OSGeo/gdal/pull/3855
> >
> > Even
> >
>

-- 
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Alpha band data type

[Evert Etienne (SITEMARK)]

Dear all,

I was wondering if there is a best practice or guide for the data type of alpha 
channels in geotiffs.
I have many files where the data type is constant over all bands (UInt16 for 
example). 
I would expect the alpha band to be a byte band or even bit.

Is it possible to have different types in a single file? If so, can I change 
the type of the alpha band alone to see if it has impact on the file size for 
example?

Many thanks

Evert
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Call for discussion on RFC 83: guidelines for the use of GDAL project sponsorship

[Even Rouault]

Hi Sean,
I've got two questions. I don't think they need answers before we 
vote, but I'm curious if asking them leads to any useful discussion.


Will we strictly require project proposals to be submitted and 
approved before work starts? Will we allow works in progress to apply 
for funding?
I don't see why we would refuse an in-progress work to be funded, and I 
don't think the text of the RFC exclude this situation. The risk is not 
for the project, but for applicants who could see their work not 
selected for funding despite their expectation.


Should we address, in the text of the RFC, the possibility of 
conflicting proposals? Should we limit the number of proposals per 
person/organization to minimize conflicts?


If we find conflicting proposals, I guess we'll ask to applicants if 
they want to collaborate together, if that makes sense. And if they 
don't/can't, we'll select the one we will find the best according to our 
criteria. As far as limiting the number of proposals, I don't see any 
need for now. Thinking to how QGIS grant proposals work, they are no 
such rules regarding that, and things seem to work well. The main 
limitation comes from the budget. If someone submit proposals that would 
> total amount of the grant program, they know some will not be 
selected . At this stage, I don't think we don't have enough experience 
of how that work for GDAL to set extra rules.


Even

--

http://www.spatialys.com
My software is free, but my time generally not.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: adopt RFC 81: support for coordinate epochs in geospatial formats

[Sean Gillies via gdal-dev]

Even,

Sounds good. Until there is consensus on what coordinate epoch means for
OGC:CRS84 GeoJSON, the official and most widely used kind, I think it would
be better if GDAL didn't extend the format. For now, applications that need
more precision can and should use another format.

On Thu, May 27, 2021 at 12:19 PM Even Rouault 
wrote:

> Regarding KML and GeoJSON and OGC:CRS84 (or EPSG:4326 since they are the
> same thing, except axis order), that's a good and hard question. Actually
> that extends to *any* CRS built on top of them, like all the
> EPSG:32[6|7][01-60] UTM CRS, and that's probably for those later than
> things are the most problematic since there's no EPSG code for a UTM WGS 84
> (G1762) CRS. I guess people would potentially want to attach a coordinate
> epoch to them, and have a (non-encoded-in-the-format) convention that they
> actually mean WGS 84 (G1762) (or possibly an earlier realization. The datum
> ensemble reality of WGS 84 is really due to Transit which differs
> significantly from later realizations, which are pretty consistent between
> them within a few centimers) . So I wouldn't forbid such uses (I actually
> got private feedback that some people would even want to store coordinate
> epoch for CRS that aren't considered by EPSG as dynamic CRS, but which, for
> advanced uses, can still have things like deformation models, like
> NAD83(2011) that is used for most people as a static CRS, but is more a
> snapshot of a dynamic CRS with a conventional reference epoch of 2010.0).
>
> That said, I'll probably drop the commit for KML as it is clearly a hack,
> but I think support for GeoJSON, which is cleaner, could still be useful at
> some point as it is widely used as an exchange format. But I'll defer for
> GeoJSON until we see if the *OGC Features* and *Geometries JSON* SWG comes
> with something regarding this.
>
> Even
> Le 27/05/2021 à 19:24, Sean Gillies via gdal-dev a écrit :
>
> Hi all,
>
> I've got a suggestion about limiting the number of formats.
>
> GeoJSON and KML don't need support for a coordinate epoch. Both of these
> are pretty cleared intended for low accuracy data (1-2 meters). KML and
> GeoJSON don't support any CRS other than OGC:CRS84, which uses (it has been
> pointed out many times) a datum ensemble that RFC 81 does not intend to
> address. Right, Even? So let's leave these formats the way they are.
>
> GML, GeoPackage, PostGIS, and the actively used raster formats like
> GeoTIFF seem like the important ones to me.
>
> On Thu, May 27, 2021 at 7:40 AM Even Rouault 
> wrote:
>
>> Hi,
>>
>> - merging the underlying API without any format support is I believe of
>> little interest. So I'll wait for at least one format (likely
>> GeoPackage) to have merged in the master of their specification an
>> official way of storing the coordinate epoch. I've also prepared an
>> enhancement of the GeoTIFF spec regarding this
>> (https://github.com/opengeospatial/geotiff/pull/99) that will likely be
>> discussed at the next OGC GeoTIFF SWG meeting.
>>
>> - I've just chatted with Howard and a good compromise could be that for
>> formats that will have an official way of storing the coordinate epoch,
>> we store it by default (when it is set), and for formats that we
>> unilaterally extend (GML, KML, GeoJSON, etc.), we require an explicit
>> GDAL_ENABLE_COORD_EPOCH_STORAGE=YES configuration option to be set
>> (default would be NO). We might revisit in the future the default value.
>>
>> - On the vector side of things, things will probably get more
>> complicated for some drivers, as it is likely that Spatialite (see
>> https://groups.google.com/g/spatialite-users/c/NtbuBpRzYBE) or PostGIS
>> might have per-geometry coordinate epoch, not at the layer level. But I
>> don't think that would invalidate having support for it at the layer
>> level (those database already support a per-geometry CRS, but GDAL
>> support for that is probably lacking a bit in those drivers), as a
>> OGRGeometry can potentially be associated with its own
>> OGRSpatialReference object.
>>
>> Even
>>
>> Le 27/05/2021 à 15:01, Howard Butler a écrit :
>> >
>> >> On May 26, 2021, at 8:33 PM, Nyall Dawson 
>> wrote:
>> >>
>> >> Can I make the suggestion that a subset of
>> >> https://github.com/OSGeo/gdal/pull/3827 could be created and be merged
>> >> on its own? Specifically the commits which add the underlying API for
>> >> GDAL to handle epochs should be controversy-free and suitable for
>> >> merge outside of the larger/trickier question of patching in support
>> >> to the data formats.
>> > :thumbsup:
>> >
>> > As for the patching of data formats with GDAL application-specific
>> metadata, as I said, I don't have a better option, but I'm satisfied if the
>> process of writing epochs into metadata is opt-in (some kind of global CRS
>> option? we already have magic switches like that).
>> >
>> > Howard
>> >
>> >
>>
>
>
-- 
Sean Gillies
___
gdal-dev mailing list
gd

Re: [gdal-dev] Alpha band data type

[Javier Jimenez Shaw]

Hi Evert,

As far as I know, TIFF data type is "constant" along the bands. You cannot
have a uint16 band and a byte band in the same page.
If you are worried about space, you can use the "nodata value", assigning a
single value for that purpose (assuming that you do not want intermediate
values, just on and off). However I do not know if this nodata is only for
GDAL -and widely used-, or in the (Geo)TIFF standard.

Cheers,
Javier
.___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ...  ._ .__
Entre dos pensamientos racionales
hay infinitos pensamientos irracionales.



On Wed, 2 Jun 2021 at 21:44, Evert Etienne (SITEMARK) <
evert.etie...@sitemark.com> wrote:

> Dear all,
>
> I was wondering if there is a best practice or guide for the data type of
> alpha channels in geotiffs.
> I have many files where the data type is constant over all bands (UInt16
> for example).
> I would expect the alpha band to be a byte band or even bit.
>
> Is it possible to have different types in a single file? If so, can I
> change the type of the alpha band alone to see if it has impact on the file
> size for example?
>
> Many thanks
>
> Evert
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Alpha band data type

[Even Rouault]

Le 02/06/2021 à 22:08, Javier Jimenez Shaw a écrit :

Hi Evert,

As far as I know, TIFF data type is "constant" along the bands. You 
cannot have a uint16 band and a byte band in the same page.
Yes, in theory this would be possible since the SampleFormat tag has as 
many values as bands 
(https://www.awaresystems.be/imaging/tiff/tifftags/sampleformat.html), 
but in practice libtiff only handles its value to be same for all bands 
(and similarly for BitsPerSample)
If you are worried about space, you can use the "nodata value", 
assigning a single value for that purpose (assuming that you do not 
want intermediate values, just on and off). However I do not know if 
this nodata is only for GDAL -and widely used-, or in the (Geo)TIFF 
standard.
GDAL-only concept. See 
https://www.awaresystems.be/imaging/tiff/tifftags/gdal_nodata.html


Cheers,
Javier
.___ ._ ..._ .. . ._. .___ .. __ . _. . __..  ...  ._ .__
Entre dos pensamientos racionales
hay infinitos pensamientos irracionales.



On Wed, 2 Jun 2021 at 21:44, Evert Etienne (SITEMARK) 
mailto:evert.etie...@sitemark.com>> wrote:


Dear all,

I was wondering if there is a best practice or guide for the data
type of alpha channels in geotiffs.
I have many files where the data type is constant over all bands
(UInt16 for example).
I would expect the alpha band to be a byte band or even bit.

Is it possible to have different types in a single file? If so,
can I change the type of the alpha band alone to see if it has
impact on the file size for example?

Many thanks

Evert
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org 
https://lists.osgeo.org/mailman/listinfo/gdal-dev



___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev


--
http://www.spatialys.com
My software is free, but my time generally not.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev