[PROJ] Motion: adopt RFC 5

Even Rouault even.rouault at spatialys.com
Wed Jan 29 05:11:02 PST 2020


Kristian,

>(I guess we will call that proj-data-1.0?)

Just changed to that

> but how is that archive produced? Similar to the old grid
> packages, e.g. 
> mkdir build
> cd build
> cmake ..
> make dist

You guessed correctly ! 

> Would be nice to have a HOWTORELEASE file to capture this knowledge.

Sure, proposed one in https://github.com/OSGeo/PROJ-data/pull/8

> 
> Does the release procedure also require as CDN sync or is that done when
> new files are registered?

I've added in the above HOWTO-RELEASE a step for that. But I'd expect the 
sync_to_cdn.sh script to be run more regularly, once a new grid has been 
merged into PROJ-data & registered in proj.db, so that users tracking PROJ 
master & using network capabilities can immediately use it.

We could probably run it automatically through Travis or a GitHub action once 
a PR is merged, but for now, I think it's probably best if you keep manual 
control on when we resync the CDN. This allows to do manual testing after 
merging a PR & before resynchronizing the CDN.

One thing I didn't mention is that pull requests submitted to PROJ-data run a 
few sanity checks by
https://github.com/OSGeo/PROJ-data/blob/master/travis/check_new_grids.sh (run 
by .travis.yml)
New or modified TIFF grids are first submitted to gdalinfo, so one can see the 
output in the Travis log
And the check_gtiff_grid.py script is run on them. If errors are found, then 
the Travis build fail. Warnings or information are displayed in the log, but 
do not fail the build.

See https://travis-ci.org/rouault/PROJ-data-tmp/builds/643019546 for a 
simulation I did with a test repository

Bottom line is to look at the Travis logs to have a first outlook of what is 
being submitted.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com


More information about the PROJ mailing list