<div dir="ltr">Please note that licensing issues is also a major reason for splitting grids from code. There is probably no problems in combining material under the MIT license (proj) and public domain or CC0 grid data. But what should the license be for a compound package including MIT and CC-NC, CC-BY or even, as recently seen, MIT and BSD 3-clause?<br><br><br></div><div class="gmail_extra"><br><div class="gmail_quote">2017-12-20 17:02 GMT+01:00 Sebastiaan Couwenberg <span dir="ltr"><<a href="mailto:sebastic@xs4all.nl" target="_blank">sebastic@xs4all.nl</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 12/20/2017 03:43 PM, Greg Troxel wrote:<br>
> Sebastiaan Couwenberg <<a href="mailto:sebastic@xs4all.nl">sebastic@xs4all.nl</a>> writes:<br>
>> On 12/19/2017 02:28 AM, Greg Troxel wrote:<br>
>>> Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> writes:<br>
>>>>> Ah sorry for reinventing the wheel, we should probably just<br>
>>>>> push your repo<br>
>>>><br>
>>>> Done:<br>
>>>> <a href="https://github.com/OSGeo/proj-datumgrid" rel="noreferrer" target="_blank">https://github.com/OSGeo/proj-<wbr>datumgrid</a><br>
>>><br>
>>> What is the plan for how these bits are used?<br>
>><br>
>> Primarily to produce the proj-datumgrid archives alongside proj.<br>
>><br>
>>> It seems obvious to me that they should be released with version numbers<br>
>>> and enough of a packaging system that they can install into<br>
>>> ${prefix}/share/proj/? or something, so that packaging systems can make<br>
>>> packages (one, separate?), for installation by use by end users.<br>
>><br>
>> For now the proj build system is still expected to install the gridshift<br>
>> files. This could possibly be separated in the future.<br>
><br>
> My real question is about the flow from repositories to releases of<br>
> tarballs to packaging system packages to bits in users' filesystems.  It<br>
> seems (but I could well be confused) that the points of proj-datumgrid<br>
> are<br>
><br>
>   - allow separate update cycle from proj proper<br>
>   - make size of proj itself smaller<br>
><br>
> Right now the pkgsrc proj package includes both proj and<br>
> proj-datumgrids.  That's perfectly workable, except that the version of<br>
> datumgrids isn't represented in the packaging system, which is perhaps<br>
> only cosmetic.<br>
<br>
</div></div>The proj package in Debian also includes the content of the<br>
proj-datumgrid archives.<br>
<span class=""><br>
> Is that how you think we should be doing things?   Or should the<br>
> datumgrids be a separate package, depending on proj, with its own<br>
> version?<br>
<br>
</span>proj needs to depend on proj-datumgrid assuming the projection files are<br>
included in proj and the grid shift files they use in proj-datumgrid.<br>
<br>
proj-datumgrid could become as more standalone package, but that require<br>
changing proj to not assume the grids are available in the nad directory.<br>
<div class="HOEnZb"><div class="h5"><br>
Kind Regards,<br>
<br>
Bas<br>
<br>
--<br>
 GPG Key ID: 4096R/6750F10AE88D4AF1<br>
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1<br>
<br>
</div></div><br>______________________________<wbr>_________________<br>
Proj mailing list<br>
<a href="mailto:Proj@lists.maptools.org">Proj@lists.maptools.org</a><br>
<a href="http://lists.maptools.org/mailman/listinfo/proj" rel="noreferrer" target="_blank">http://lists.maptools.org/<wbr>mailman/listinfo/proj</a><br></blockquote></div><br></div>