Re: [gdal-dev] Nodata is None, but still has blanks?

[Jeff McKenna]

Hi Matt,

Just for the record, the TIFF tools are also distributed to the MS4W 
users as well, on the web mapping side of things ha (I use them often, 
so when I find something useful I try to distribute them). 
https://ms4w.com   Cheers from the far east side.


-jeff



On 2022-01-18 12:41 p.m., matt.wil...@yukon.ca wrote:
Never mind! Paying attention to the version numbers answers the Q: Conda 
is built from libtiff 4.x while GnuWin32 libtiff is back on version 3.x.


I’ll see if I can find a contact at libtiff.org about adding a line 
about the library and tools being available via Conda as well as the 
other sources.


-Matt//

*From:*gdal-dev  *On Behalf Of 
*matt.wil...@yukon.ca

*Sent:* January 18, 2022 9:34 AM
*To:* gdal-dev@lists.osgeo.org
*Subject:* Re: [gdal-dev] Nodata is None, but still has blanks?

A little off topic for this list but people here might know: I see Tiff 
Tools for Windows binaries[0] haven’t been updated since 2006. Conda has 
Windows libtiff packages which include the tiff tools executables.[1] Is 
the conda variant actually newer than 2006 or is it just current packaging?


[0]: http://www.libtiff.org/index.html 

[1]: 
https://anaconda.org/conda-forge/libtiff/4.3.0/download/win-64/libtiff-4.3.0-h0c97f57_1.tar.bz2 



-Matt//

*From:*Matt.Wilkie
*Sent:* January 18, 2022 8:35 AM
*To:* gdal-dev@lists.osgeo.org 
*Subject:* RE: [gdal-dev] Nodata is None, but still has blanks?

Thank you Frank and Even.

As is so often the case on this list, I now have answers, and an 
education. I have been peripherally aware of the tiff tools from 
libtiff, but not enough so that they came to mind when seeking to puzzle 
out things. I’m now updated. ;-)


-Matt//


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



--
Jeff McKenna
GatewayGeo: Developers of MS4W, MapServer Consulting and Training
co-founder of FOSS4G
http://gatewaygeo.com/
___
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 85: Policy regarding substantial code additions

[Howard Butler]

> On Jan 18, 2022, at 9:28 AM, Kemeter, Mathias via gdal-dev 
>  wrote:
> 
> Hi Even,
>  
> thanks for the feedback.
>  
> Let me briefly elaborate on the distinction between corporate and 
> non-corporate contributors (…which I did not intend in the first place):
> As an individual, I can very well live with the general message and ‘sign’ 
> the policy based on trust. As written before, I do understand this message 
> and fully agree to it. 
> However, as an employee in a corporate environment, I will have to justify 
> and quantify investments. No one likes that – but that’s just how it is.

As an open source community, we must also justify and quantify our time 
investments. A GDAL driver based on a binary SDK that is contributed by the 
company whose SDK it supports is a white elephant for the project. Fixing 
issues with it is often not simply a matter of putting in time and attention. 
GDAL's distribution mechanism provides a lot of value – the binary SDK 
proprietor is using GDAL to give the benefits of GDAL to its userbase. This RFC 
is about giving the PSC some tools to react when that cost/benefit as measured 
by the project is out of balance. 

> Accepting a policy means signing a contract. And if formulations leave room 
> for interpretation, it gets harder to sign (or fulfill) this contract. As an 
> individual I wouldn’t care too much. However, in a company with legal 
> departments these thing are handled more strict.

There's no crying in baseball and there's no contracts in open source. It is 
run by social mores, social capital, and expertise/time gifting. Showing up 
cold to drop +15k lines onto a project in one which you have no social capital 
is rightly met with skepticism. It's the easiest thing for that project to just 
say no. 

This RFC is to flip the default policy to 'yes', but to provide some guidelines 
when the contribution has gone stale to the point that it is imposing 
time/money/maintenance/attention/usability cost on the project.

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

Re: [gdal-dev] Nodata is None, but still has blanks?

[Matt.Wilkie]

Never mind! Paying attention to the version numbers answers the Q: Conda is 
built from libtiff 4.x while GnuWin32 libtiff is back on version 3.x.

I’ll see if I can find a contact at libtiff.org about adding a line about the 
library and tools being available via Conda as well as the other sources.

-Matt

From: gdal-dev  On Behalf Of 
matt.wil...@yukon.ca
Sent: January 18, 2022 9:34 AM
To: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Nodata is None, but still has blanks?

A little off topic for this list but people here might know: I see Tiff Tools 
for Windows binaries[0] haven’t been updated since 2006. Conda has Windows 
libtiff packages which include the tiff tools executables.[1] Is the conda 
variant actually newer than 2006 or is it just current packaging?

[0]: http://www.libtiff.org/index.html
[1]: 
https://anaconda.org/conda-forge/libtiff/4.3.0/download/win-64/libtiff-4.3.0-h0c97f57_1.tar.bz2

-Matt

From: Matt.Wilkie
Sent: January 18, 2022 8:35 AM
To: gdal-dev@lists.osgeo.org
Subject: RE: [gdal-dev] Nodata is None, but still has blanks?

Thank you Frank and Even.

As is so often the case on this list, I now have answers, and an education. I 
have been peripherally aware of the tiff tools from libtiff, but not enough so 
that they came to mind when seeking to puzzle out things. I’m now updated. ;-)

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

Re: [gdal-dev] Nodata is None, but still has blanks?

[Matt.Wilkie]

A little off topic for this list but people here might know: I see Tiff Tools 
for Windows binaries[0] haven’t been updated since 2006. Conda has Windows 
libtiff packages which include the tiff tools executables.[1] Is the conda 
variant actually newer than 2006 or is it just current packaging?

[0]: http://www.libtiff.org/index.html
[1]: 
https://anaconda.org/conda-forge/libtiff/4.3.0/download/win-64/libtiff-4.3.0-h0c97f57_1.tar.bz2


-Matt

From: Matt.Wilkie
Sent: January 18, 2022 8:35 AM
To: gdal-dev@lists.osgeo.org
Subject: RE: [gdal-dev] Nodata is None, but still has blanks?

Thank you Frank and Even.

As is so often the case on this list, I now have answers, and an education. I 
have been peripherally aware of the tiff tools from libtiff, but not enough so 
that they came to mind when seeking to puzzle out things. I’m now updated. ;-)

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

Re: [gdal-dev] Nodata is None, but still has blanks?

[Matt.Wilkie]

Thank you Frank and Even.

As is so often the case on this list, I now have answers, and an education. I 
have been peripherally aware of the tiff tools from libtiff, but not enough so 
that they came to mind when seeking to puzzle out things. I’m now updated. ;-)

-Matt
___
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 85: Policy regarding substantial code additions

[Kemeter, Mathias via gdal-dev]

Hi Even,

thanks for the feedback.

Let me briefly elaborate on the distinction between corporate and non-corporate 
contributors (…which I did not intend in the first place):

  *   As an individual, I can very well live with the general message and 
‘sign’ the policy based on trust. As written before, I do understand this 
message and fully agree to it.
  *   However, as an employee in a corporate environment, I will have to 
justify and quantify investments. No one likes that – but that’s just how it is.
  *   Accepting a policy means signing a contract. And if formulations leave 
room for interpretation, it gets harder to sign (or fulfill) this contract. As 
an individual I wouldn’t care too much. However, in a company with legal 
departments these thing are handled more strict.

So the intent is not to draw a division between corporate and non-corporate (it 
may be the same individual), but the perspectives differ for sure depending on 
what hat you wear.

I like this proposal a lot more as it makes the intention clearer and leaves 
less room for interpretation:
https://github.com/OSGeo/gdal/pull/5128#discussion_r786826988

Regards,
Mathias

From: Even Rouault 
Date: Tuesday, 18. January 2022 at 16:07
To: Kemeter, Mathias , gdal-dev@lists.osgeo.org 

Subject: Re: [gdal-dev] Call for discussion on RFC 85: Policy regarding 
substantial code additions
Mathias,
Hi Even, hi everyone,

As we (SAP) are probably one of the triggers for formalizing this policy, let 
me take a first stab from the perspective of a new contributor trying to make a 
substantial contribution:
(My personal position is that a first contribution that is a substantial one is 
probably not the best way to engage and socialize with a project. End of 
bracket)




  1.  Having such a policy greatly increases transparency on what has to be 
done to make a driver contribution. The outlined criteria reduces the need for 
lengthy discussions.


  2.  I do specifically like the idea of having a list of responsible contacts. 
It makes it easier to track personas – even if people change. Still, the list 
could be outdated at some point. Maybe a regular check-in (via email, virtual 
meeting, etc.) would be beneficial.
It is the responsibility of a maintainer listed the contacts that can no longer 
occupy this position to update the list: preferably with a replacement 
maintainer, or if not with an empty name.


  1.

  2.  To me, the term “significant code addition” should be defined more 
precisely. Not only in terms of quantity, but also complexity. New drivers 
typically have a significant footprint in terms of code quantity, but they are 
isolated. Whereas there may be other contributions with less code, but spanning 
several software components.
If you know how to define that more precisely, please propose. But this RFC is 
more about giving a general message, and as noted at the end the PSC is the 
ultimate adjudicator.



  1.  At least for corporate contributors, the bullet point of participating in 
the day-to-day activities is too vague to be seriously accomplishable. While I 
do well understand, what the goal of the statement is, I still think, the 
responsibilities have to be defined (and quantified) more clearly as the 
current description may be interpreted as a bottomless pit for development 
resources.

I'm not sure how we can quantify, and I don't like the artificial division 
about "corporate contributors" vs "non-corporate contributors". Are 
non-corporate contributors expected to spend their nights & weekends doing all 
the boring & thankless tasks that corporate contributors don't "quantify" as 
being in their area of responsibility ? The message here is that the project 
can't work if people wear blinders and only care about the part that they 
contributed to without considering & investing in the project as a whole. 
Maintaining a project of this size is close to be a bottomless pit.

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 85: Policy regarding substantial code additions

[Even Rouault]

Another comment is about "complicated registration process".  I
sympathize but I don't really understand that.   So it might be good to
say what's acceptable, which could be one of:

   The SDK must be downloadable by a URL with no user interaction

   It's ok to have a form which requires a name and an email address, and
   which does not opt the user in to spamming, to download.

   It's ok to have a form which requires a name and an email address (and
   opting in to spamming is ok) to download.
  
   Something else

I'll keep the vague formulation.




I also think it probably went without saying that drivers that depend on
proprietary SDKs will be default off, even if the build system finds the
SDK, so that people who build GDAL will not accidentally create
proprietary software.


Sorry , but no. If people have put proprietary SDKs in default findable 
locations (which generally requires efforts since they generally have 
non standard layouts), they will be used by default, at least in the new 
CMake build. That makes things much more consistent. People can still 
disable them (see 
https://gdal.org/build_hints.html#cmake-package-dependent-options and 
https://gdal.org/build_hints.html#selection-of-drivers). People who 
build GDAL should look at the licensing of all dependencies. It might be 
well possible to create a GDAL build with only free components with 
incompatible licenses, who knows. Or maybe people want a build that is 
globally permissive licensed, and thus they must be careful of not 
including copyleft components. There was a RFC attempt at addressing 
this, but this was abandoned as being a too complex issue.


Anyway people who want to create a build that is going to be used by 
other peoples should do that in a dedicated controlled environment, not 
just the random state of their desktop day-to-day env.


--
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 85: Policy regarding substantial code additions

[Even Rouault]

Mathias,


Hi Even, hi everyone,

As we (SAP) are probably one of the triggers for formalizing this 
policy, let me take a first stab from the perspective of a new 
contributor trying to make a substantial contribution:


(My personal position is that a first contribution that is a substantial 
one is probably not the best way to engage and socialize with a project. 
End of bracket)



  * Having such a policy greatly increases transparency on what has to
be done to make a driver contribution. The outlined criteria
reduces the need for lengthy discussions.

  * I do specifically like the idea of having a list of responsible
contacts. It makes it easier to track personas – even if people
change. Still, the list could be outdated at some point. Maybe a
regular check-in (via email, virtual meeting, etc.) would be
beneficial.

It is the responsibility of a maintainer listed the contacts that can no 
longer occupy this position to update the list: preferably with a 
replacement maintainer, or if not with an empty name.


 *


  * To me, the term “significant code addition” should be defined more
precisely. Not only in terms of quantity, but also complexity. New
drivers typically have a significant footprint in terms of code
quantity, but they are isolated. Whereas there may be other
contributions with less code, but spanning several software
components.

If you know how to define that more precisely, please propose. But this 
RFC is more about giving a general message, and as noted at the end the 
PSC is the ultimate adjudicator.


  * At least for corporate contributors, the bullet point of
participating in the day-to-day activities is too vague to be
seriously accomplishable. While I do well understand, what the
goal of the statement is, I still think, the responsibilities have
to be defined (and quantified) more clearly as the current
description may be interpreted as a bottomless pit for development
resources.

I'm not sure how we can quantify, and I don't like the artificial 
division about "corporate contributors" vs "non-corporate contributors". 
Are non-corporate contributors expected to spend their nights & weekends 
doing all the boring & thankless tasks that corporate contributors don't 
"quantify" as being in their area of responsibility ? The message here 
is that the project can't work if people wear blinders and only care 
about the part that they contributed to without considering & investing 
in the project as a whole. Maintaining a project of this size is close 
to be a bottomless pit.


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] Shortening schedule for CMake adoption ?

[Greg Troxel]

Even Rouault  writes:

> Greg,
>
> I will not respond point by point, but the message here is: "CMake
> support is available and believed to be in good shape into master
> based on our manual tests and initial CI configuration exercising it,
> it will replace autotools+nmake soon, be ready for it and help
> polishing it". 

OK, that's great to hear.  As someone who is here mainly as a packager,
I don't subscribe to github, and I haven't seen anything on gdal-dev@
saying that cmake support is ready for widespread testing (but now I
have!).

> There will perhaps be areas where it will not do
> everything that existing build systems made, but existing build
> systems have also their flows that are not easily fixable. So be
> it. Having one single build system at the end of the process, and used
> in an idiomatic way (our autoconf system without automake is far from
> being idiomatic), is the main objective of this whole effort from my
> side.

Sure, I get it that there will be a few rough edges.

> CMake might not be completely ready for 3.5.0 for all imaginable
> platforms & configurations (we don't promise to support all platforms
> anyway. I don't believe we have a formal list of supported platforms
> by the way. I'd say what is tested on our CI is the practical
> definition of what is supported), and we won't defer indefinitely
> 3.5.0 if it doesn't work on some confs. That's why autoconf will
> only be removed in 3.6.0, and we have 3.5.x point releases to help
> address issues.

Sorry, I misunderstood that the autoconf removal would not be for this
release.  As long as I can use the existing autoconf support for 3.5.0
if I have to, things are much less tense.

And yes, I realize that "supported platforms" is a difficult concept.
But here we're talking about a big change that risks regresssions to
platforms people have already made work, so I see it more as "we should
really avoid causing regressions on platforms known to work".

As a random datpoint, I have updated gdal in pkgsrc to 3.4.1 (not yet
committed it), tested on NetBSD 9 amd64, and the tests have only a
handful of failures that perhaps could be test issues.  And qgis with
this build works ok as far as I can tell.

> The release process  is described in HOWTO-RELEASE and it points to
> the mkgdaldist.sh script
>
> You can generate a gdal-master.tar.gz with:
>
> ./mkgdaldist.sh master -branch master
>
> No idea if the script works properly on non-Linux systems. You'll need
> some prerequisites for the script to run: Sphinx (pip install -r 
> doc/requirements.txt) to generate man pages, swig

I'll try that, but I think you'll get a lot more testing from packagers
if you publish an alpha tarball.

> Or just clone the git repo and rm -rf autotest .git .github, and that
> will be very close to the final tarball, at least for the purpose of
> doing a CMake build
>
> and try packaging this.

I'll try that if the above doesn't work.

And actually I can try a cmake build from the repo, which is probably a
good first step.



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

Re: [gdal-dev] Shortening schedule for CMake adoption ?

[Even Rouault]

Greg,

I will not respond point by point, but the message here is: "CMake 
support is available and believed to be in good shape into master based 
on our manual tests and initial CI configuration exercising it, it will 
replace autotools+nmake soon, be ready for it and help polishing it". 
There will perhaps be areas where it will not do everything that 
existing build systems made, but existing build systems have also their 
flows that are not easily fixable. So be it. Having one single build 
system at the end of the process, and used in an idiomatic way (our 
autoconf system without automake is far from being idiomatic), is the 
main objective of this whole effort from my side.


CMake might not be completely ready for 3.5.0 for all imaginable 
platforms & configurations (we don't promise to support all platforms 
anyway. I don't believe we have a formal list of supported platforms by 
the way. I'd say what is tested on our CI is the practical definition of 
what is supported), and we won't defer indefinitely 3.5.0 if it doesn't 
work on some confs. That's why autoconf will only be removed in 
3.6.0, and we have 3.5.x point releases to help address issues.


The release process  is described in HOWTO-RELEASE and it points to the 
mkgdaldist.sh script


You can generate a gdal-master.tar.gz with:

./mkgdaldist.sh master -branch master

No idea if the script works properly on non-Linux systems. You'll need 
some prerequisites for the script to run: Sphinx (pip install -r 
doc/requirements.txt) to generate man pages, swig


Or just clone the git repo and rm -rf autotest .git .github, and that 
will be very close to the final tarball, at least for the purpose of 
doing a CMake build


and try packaging this.

Even


Le 18/01/2022 à 14:06, Greg Troxel a écrit :

Even Rouault  writes:


The new CMake build system
(https://gdal.org/development/rfc/rfc84_cmake.html) has made excellent
progress, and I believe that it should be in a production ready state
on time for GDAL 3.5.0 (~ May). It is already very close to it
according to a checklist I had created
(https://docs.google.com/spreadsheets/d/1SsUXiZxKim6jhLjlJFCRs1zwMvNpbJbBMB6yl0ms01c).

Do you mean that the master branch already has cmake support that you
believe 99% meets the requirements?

I think that establishing a date before the code meets requirement risks
a later decision to proceed anyway despite meeting the requirements.  So
I'd like to flip this around to the steps needed, with the autoconf
removal decision gated on packager testing.

Specifically:

   - Get master in a shape where the developers believe the requirements
 are met.  This includes build instructions, specifically about how
 to get the right RPATH behavior.  It's going to need testing
 building to a prefix other than /usr and specifically a prefix not
 in the default linker search path.

 I'm unclear on the plan for the test suite.  If running py-test in
 the tests directory against an installed build still works, that's
 fine -- I don't see a need to couple test improvements with the
 cmake conversion.

   - Produce an alpha tarball, following the same (documented) procedure
 that would be used for a relaase in an autoconf-removed world.  This
 is what packagers package, and users hand build.  Tarball creation
 should be documented and scripted, so this should be a combination
 of good testing and near-zero effort.

   - Call for packager and user testing of the alpha tarball.  Give them
 1 full month, because converting a packaging build from autoconf to
 cmake is not trivial, and because everything that depends on gdal
 needs testing too.  (In my case, the gdal build control files are
 much bigger than typical packages.)

 I expect to find problems, because I usually do on autoconf->cmake
 transitions, and often around RPATH handling.  But I will be happy
 to report 100% success if that's how it is.  And I'll try to do this
 sooner rather than later.

   - If there are any failures to meet requirements (including on systems
 where gdal does not have CI; that's the point of the call for
 testing), fix and release another alpha.  2 weeks is adequate
 testing time, if the failures were minor enough to not prevent
 getting to a working state.

   - Once the report/fix cycle ends, then the autoconf removal can
 proceed.

The above can be pipelined, if an alpha tarball can be produced that
90-95% meets requirements, enough that it's reasonable to do a draft
packaging conversion and end up with an installed gdal that one can
build a working qgis against.

Will this work for May?  I don't know, and I think the big questions are
when a believed-requirements-meeting alpha tarball can be produced, and
how many residual issues there are.  With a alpha in 2 weeks, the odds
are good.  With an alpha on April 1, I don't see how it can work.

Greg


--
http://www.spatialys.com
My software is 

Re: [gdal-dev] Call for discussion on RFC 85: Policy regarding substantial code additions

[Rahkonen Jukka (MML)]

Hi,

Greg Troxel wrote:

> If that is meant to apply mainly to drivers with proprietary SDKs, it
> looks fine.   It's a little hard to tell which things apply to drivers
> that don't have proprietary dependencies.
I think that even drivers with no proprietary dependencies require a thorough 
understanding about what they do and how they work and for example what 
standards they try to implement. It could mean hours or days for a generic GDAL 
maintainer to make the first bug fix.

> For example:
> Drivers require a designated responsible contact.
> seems perhaps a bit much, perhaps not, for something that is actually Free 
> Software.
The intention of the RFC, as I understand it, is to clarify that no new drivers 
will be accepted without a named maintainer. For a Free Software there is room 
to live also outside GDAL. 

> Besides proprietary SDKs being a problem because the users can't read them 
> and fix bugs, they are also non-portable.
I belong to those users who can't read and fix even Free Software but depend on 
maintainers.

-Jukka Rahkonen-
___
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 85: Policy regarding substantial code additions

[Baker (US), Anthony W]

unsubscribe

-Original Message-
From: gdal-dev  On Behalf Of Greg Troxel
Sent: Tuesday, January 18, 2022 8:14 AM
To: Even Rouault 
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Call for discussion on RFC 85: Policy regarding 
substantial code additions


If that is meant to apply mainly to drivers with proprietary SDKs, it
looks fine.   It's a little hard to tell which things apply to drivers
that don't have proprietary dependencies.

For example:

  Drivers require a designated responsible contact.

seems perhaps a bit much, perhaps not, for something that is actually Free 
Software.


Besides proprietary SDKs being a problem because the users can't read them and 
fix bugs, they are also non-portable.



Another comment is about "complicated registration process".  I
sympathize but I don't really understand that.   So it might be good to
say what's acceptable, which could be one of:

  The SDK must be downloadable by a URL with no user interaction

  It's ok to have a form which requires a name and an email address, and
  which does not opt the user in to spamming, to download.

  It's ok to have a form which requires a name and an email address (and
  opting in to spamming is ok) to download.
 
  Something else



I also think it probably went without saying that drivers that depend on 
proprietary SDKs will be default off, even if the build system finds the SDK, 
so that people who build GDAL will not accidentally create proprietary software.
___
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 85: Policy regarding substantial code additions

[Greg Troxel]

If that is meant to apply mainly to drivers with proprietary SDKs, it
looks fine.   It's a little hard to tell which things apply to drivers
that don't have proprietary dependencies.

For example:

  Drivers require a designated responsible contact.

seems perhaps a bit much, perhaps not, for something that is actually
Free Software.


Besides proprietary SDKs being a problem because the users can't read
them and fix bugs, they are also non-portable.



Another comment is about "complicated registration process".  I
sympathize but I don't really understand that.   So it might be good to
say what's acceptable, which could be one of:

  The SDK must be downloadable by a URL with no user interaction

  It's ok to have a form which requires a name and an email address, and
  which does not opt the user in to spamming, to download.

  It's ok to have a form which requires a name and an email address (and
  opting in to spamming is ok) to download.
 
  Something else



I also think it probably went without saying that drivers that depend on
proprietary SDKs will be default off, even if the build system finds the
SDK, so that people who build GDAL will not accidentally create
proprietary software.


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

Re: [gdal-dev] Shortening schedule for CMake adoption ?

[Greg Troxel]

Even Rouault  writes:

> The new CMake build system
> (https://gdal.org/development/rfc/rfc84_cmake.html) has made excellent
> progress, and I believe that it should be in a production ready state
> on time for GDAL 3.5.0 (~ May). It is already very close to it
> according to a checklist I had created
> (https://docs.google.com/spreadsheets/d/1SsUXiZxKim6jhLjlJFCRs1zwMvNpbJbBMB6yl0ms01c).

Do you mean that the master branch already has cmake support that you
believe 99% meets the requirements?

I think that establishing a date before the code meets requirement risks
a later decision to proceed anyway despite meeting the requirements.  So
I'd like to flip this around to the steps needed, with the autoconf
removal decision gated on packager testing.

Specifically:

  - Get master in a shape where the developers believe the requirements
are met.  This includes build instructions, specifically about how
to get the right RPATH behavior.  It's going to need testing
building to a prefix other than /usr and specifically a prefix not
in the default linker search path.

I'm unclear on the plan for the test suite.  If running py-test in
the tests directory against an installed build still works, that's
fine -- I don't see a need to couple test improvements with the
cmake conversion.

  - Produce an alpha tarball, following the same (documented) procedure
that would be used for a relaase in an autoconf-removed world.  This
is what packagers package, and users hand build.  Tarball creation
should be documented and scripted, so this should be a combination
of good testing and near-zero effort.

  - Call for packager and user testing of the alpha tarball.  Give them
1 full month, because converting a packaging build from autoconf to
cmake is not trivial, and because everything that depends on gdal
needs testing too.  (In my case, the gdal build control files are
much bigger than typical packages.)

I expect to find problems, because I usually do on autoconf->cmake
transitions, and often around RPATH handling.  But I will be happy
to report 100% success if that's how it is.  And I'll try to do this
sooner rather than later.

  - If there are any failures to meet requirements (including on systems
where gdal does not have CI; that's the point of the call for
testing), fix and release another alpha.  2 weeks is adequate
testing time, if the failures were minor enough to not prevent
getting to a working state.

  - Once the report/fix cycle ends, then the autoconf removal can
proceed.

The above can be pipelined, if an alpha tarball can be produced that
90-95% meets requirements, enough that it's reasonable to do a draft
packaging conversion and end up with an installed gdal that one can
build a working qgis against.

Will this work for May?  I don't know, and I think the big questions are
when a believed-requirements-meeting alpha tarball can be produced, and
how many residual issues there are.  With a alpha in 2 weeks, the odds
are good.  With an alpha on April 1, I don't see how it can work.

Greg


signature.asc
Description: PGP signature
___
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 85: Policy regarding substantial code additions

[Kemeter, Mathias via gdal-dev]

Hi Even, hi everyone,

As we (SAP) are probably one of the triggers for formalizing this policy, let 
me take a first stab from the perspective of a new contributor trying to make a 
substantial contribution:


  *   Having such a policy greatly increases transparency on what has to be 
done to make a driver contribution. The outlined criteria reduces the need for 
lengthy discussions.

  *   I do specifically like the idea of having a list of responsible contacts. 
It makes it easier to track personas – even if people change. Still, the list 
could be outdated at some point. Maybe a regular check-in (via email, virtual 
meeting, etc.) would be beneficial.

  *   To me, the term “significant code addition” should be defined more 
precisely. Not only in terms of quantity, but also complexity. New drivers 
typically have a significant footprint in terms of code quantity, but they are 
isolated. Whereas there may be other contributions with less code, but spanning 
several software components.

  *   At least for corporate contributors, the bullet point of participating in 
the day-to-day activities is too vague to be seriously accomplishable. While I 
do well understand, what the goal of the statement is, I still think, the 
responsibilities have to be defined (and quantified) more clearly as the 
current description may be interpreted as a bottomless pit for development 
resources.

Best regards,
Mathias

Mathias Kemeter
Head of Multi-model Engines, SAP HANA Database & Analytics

SAP SE Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany
T +49 6227 7-64316, M +49 151 62345760, E mathias.keme...@sap.com
Mandatory Disclosure Statement:
http://www.sap.com/company/legal/impressum.epx

This e-mail may contain trade secrets or privileged, undisclosed, or otherwise 
confidential information.  If you have received this e-mail in error, you are 
hereby notified that any review, copying, or distribution of it is strictly 
prohibited. Please inform us immediately and destroy the original transmittal.
Thank you for your cooperation

___
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 85: Policy regarding substantial code additions

[Robert Coup]

Working link is https://github.com/OSGeo/gdal/pull/5128

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

[gdal-dev] Call for discussion on RFC 85: Policy regarding substantial code additions

[Even Rouault]

Hi,

Please find in https://github.com/OSGeo/gdal/pull/3855a RFC 
thatdescribes the policies that the GDAL project will apply to assess 
substantial code additions, typically new drivers, in particular coming 
for new contributors to the project.


Best regards,

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] Nodata is None, but still has blanks?

[Even Rouault]

>  I find that if I do:

tiffcp sample-no-mask.tif,0 x0.tif

I get an "x0.tif" with just the jpeg image, and not the mask. That may 
be helpful for you (without uncompressing the jpeg image).


tiffcp doesn't use the raw interface of libtiff, hence JPEG 
decompression will occur.


tiffsplit avoids that as it does use the raw interface:

tiffsplit sample-no-mask.tif out

will generate a outaaa.tif file with the original JPEG content (the 
geotif tags will be lost however, and will have to be reinjected 
https://github.com/OSGeo/gdal/blob/master/swig/python/gdal-utils/osgeo_utils/samples/gdalcopyproj.py 
for example)


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