[Proj] (moved to) https://github.com/OSGeo/proj-datumgrid

[Sebastiaan Couwenberg]

On 12/20/2017 03:43 PM, Greg Troxel wrote:
> Sebastiaan Couwenberg <sebastic at xs4all.nl> writes:
>> On 12/19/2017 02:28 AM, Greg Troxel wrote:
>>> Even Rouault <even.rouault at spatialys.com> writes:
>>>>> Ah sorry for reinventing the wheel, we should probably just
>>>>> push your repo
>>>>
>>>> Done:
>>>> https://github.com/OSGeo/proj-datumgrid
>>>
>>> What is the plan for how these bits are used?
>>
>> Primarily to produce the proj-datumgrid archives alongside proj.
>>
>>> It seems obvious to me that they should be released with version numbers
>>> and enough of a packaging system that they can install into
>>> ${prefix}/share/proj/? or something, so that packaging systems can make
>>> packages (one, separate?), for installation by use by end users.
>>
>> For now the proj build system is still expected to install the gridshift
>> files. This could possibly be separated in the future.
> 
> My real question is about the flow from repositories to releases of
> tarballs to packaging system packages to bits in users' filesystems.  It
> seems (but I could well be confused) that the points of proj-datumgrid
> are
> 
>   - allow separate update cycle from proj proper
>   - make size of proj itself smaller
> 
> Right now the pkgsrc proj package includes both proj and
> proj-datumgrids.  That's perfectly workable, except that the version of
> datumgrids isn't represented in the packaging system, which is perhaps
> only cosmetic.

The proj package in Debian also includes the content of the
proj-datumgrid archives.

> Is that how you think we should be doing things?   Or should the
> datumgrids be a separate package, depending on proj, with its own
> version?

proj needs to depend on proj-datumgrid assuming the projection files are
included in proj and the grid shift files they use in proj-datumgrid.

proj-datumgrid could become as more standalone package, but that require
changing proj to not assume the grids are available in the nad directory.

Kind Regards,

Bas

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
Url : http://lists.maptools.org/pipermail/proj/attachments/20171220/7f4c2f76/attachment.pgp