[Proj] https://github.com/OSGeo/projgrids

[Sebastiaan Couwenberg]

On 12/18/2017 05:08 PM, Kristian Evers wrote:
> On 18 Dec 2017, at 16:11, Even Rouault <even.rouault at spatialys.com<mailto:even.rouault at spatialys.com>> wrote:
> On lundi 18 décembre 2017 14:42:28 CET Kristian Evers wrote:
>> Even,
>>
>> Thanks for setting this up! A few comments and ideas:
> 
> Basically I just did the first easy step and will now quickly run away before the real troubles show up ;-)
> 
>> 1. Some structure in the repo would be nice. It might be as simple as
>> having a folder called "grids" which contain all the grids and then
>> README's and other relevant files in the root.
> 
> Agreed

Restructuring the repository shouldn't be a problem as long as the
resulting tarball keeps the grids in the root as they've always been.

Packaging proj has always involved unpacking the proj-datumgrid archive
into the nad/ directory to get a complete tree for building the project.
I don't think we should change that.

>> 2. We should come up with some rules to govern the repo with. The most
>> important here is describing the requirements for getting grids accepted as
>> part of the repository. A list of accepted licenses would be handy.
> 
> Would the following make sense:
> - Public domain
> - X/MIT, BSD 2/3/4 clause
> - CC0, CC-BY, CC-BY-SA
> 
> Or perhaps we could just require the license to be an OSI approved one ? The license of grid files, being data files, should have no consequence on the software stack itself, right ?
> 
> I think it is a good start. Software licenses like MIT and BDS are probably not very suited for the purpose, so maybe we should discourage use of those.

The license for grid shift files should be compatible with the Open
Source Definition (and thereby with the Debian Free Software Guidelines).

Historically the files included in proj-datumgrid where in the public
domain.

>> Contact information or some other form of source of the grid is also needed I think.
> 
> Agreed. The README could track the provenance & licensing of grids.

Yes, this is a good idea. It will be a bit of a chore to find the origin
of the existing grids, though.

>> 3. Can we convert the old CTable files to CTable2 format? The former
>> are architecture dependent. Effectively fixes
>> https://github.com/OSGeo/proj.4/issues/44
> 
> I don't see any remanining CTable file. As far as I can see, in projgrids, all files are CTable2 except the .gsb files (NTV2) and ntv1_can.dat (NTV1). So the ticket can probably be closed.
> 
> I was of the impression that the alaska, conus and a few others were still in CTable format. Great if that is not the case!

proj 4.8.0 was the first release to default to ctable2, since 4.8.0 or
newer is available pretty much everywhere, it makes no sense to include
grids using the old ctable format in proj-datumgrid.

>> 4. Are the current tests affected of your "removal-proposal"? Removing
>> the null grid could have some consequences.

The null grid shift file is used by various projections defined in nad/IGNF.

While those projections can probably be updated to not require the null
file, there may be other projections created by users who rely on the
null grid.

I don't think the overhead of keeping the file warrant the possible
breakage it will cause for end users.

> I imagine that the tests woud probably require downloading a few grids.
> 
> That’s what I figured as well. It should be documented somewhere if it is required to download the grids before tests will pass.

The proj-datumgrid archive should always be unpacked as part of setting
up the proj source.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1