<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jul 24, 2020, at 3:16 AM, Sebastiaan Couwenberg <<a href="mailto:sebastic@xs4all.nl" class="">sebastic@xs4all.nl</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><div class="content-isolator__container"><div class="protected-part"><div class="protected-title">Signed PGP part</div><div class="protected-content">On 7/24/20 10:00 AM, Jürgen E. Fischer wrote:<br class=""><blockquote type="cite" class="">On Fri, 24. Jul 2020 at 09:41:02 +0200, Sebastiaan Couwenberg wrote:<br class=""><blockquote type="cite" class="">You could split up the grids per region and only depend on a subset<br class="">(excluding au_*, ca_*, de_* & us_* removes most of the very large grids)<br class="">and suggest the rest for the users to manually install when they need it.<br class=""></blockquote><br class="">I don't want to exclude de completely - esp. because there are grids that were<br class="">previously shipped among it. The ridiculously large Baden-Württemberg grid<br class="">wasn't and must be excluded.<br class=""></blockquote><br class="">Then perhaps split the grids by size similar to the<br class="">gmt-gshhg-{low,high,full} packages.<br class=""><br class="">The gmt package in Debian only Recommends gmt-gshhg-low because of size<br class="">constraints for OSGeoLive, despite the authors wanting the full package<br class="">installed by default.<br class=""></div></div></div></div></div></blockquote></div><br class=""><div class="">I'm not particularly sympathetic here. We cut the total size of the grids by ~60% and enabled them to be lazily downloaded to users' systems incrementally or at user direction in bulk with projsync. Everything is enabled with a global CDN that should be fast just about everywhere. </div><div class=""><br class=""></div><div class="">I would consider adding an optional box to your installer that completes the projsync operation for the user. Then the download cost is between them and the CDN, and data isn't duplicated in your installers. They would get the latest grids, and they could potentially choose which families of content to fetch. </div><div class=""><br class=""></div><div class="">As a backup, you could also make a static proj-data package in OSGeo4W, but this is going to rot in relation to the grids at <a href="http://cdn.proj.org" class="">cdn.proj.org</a> If users don't know to select it, their software might not behave as they expect. </div><div class=""><br class=""></div><div class="">The complaints about sizes are frustrating. For a fully functioning PROJ in the past, you needed 1.2 gb of grids, and you had to do a bunch of hand jamming to get them situated. The current configuration is much simpler and user friendly in my opinion.</div><div class=""><br class=""></div><div class="">Howard</div></body></html>