search

OSGeo / PROJ-data

Repository for proj datum grids (for use by PROJ 7 or later)
Other
72 stars 33 forks source link

Add Australian AGQG_20201120 #63

Closed rouault closed 3 years ago

rouault commented 3 years ago

@kbevers It appears that EPSG v10.012 changed the status of the existing AGQG_20191107 grid to deprecated, and introduced AGQG_20201120 in replacement. As they are quite large grids (60 MB), what about removing AGQG_20191107 from this repository ? It would still be available on the CDN for people using older proj.db version (the synchronization process from git to the CDN adds new files and does not remove existing one), and in previous PROJ-data archives, so it shouldn't break existing workflows. I'd add a note in au_ga/au_ga_README.txt to mention it was available in PROJ-data 1.6 and was retired in 1.7

kbevers commented 3 years ago

what about removing AGQG_20191107 from this repository ?

By that you mean removing it from HEAD and onwards, right? As in it wouldn't be part of new PROJ-data distributions but older ones can still be created by checking out tags previos to 1.6.0. I'm good with that. Not keen on tampering with the git history (which you totally can and I just want to make absolutely sure we are on the same page here).

It would still be available on the CDN for people using older proj.db version (the synchronization process from git to the CDN adds new files and does not remove existing one), and in previous PROJ-data archives, so it shouldn't break existing workflows.

Seems fine to me. Do we have a backup plan in case the CDN for some unforseen reason is wiped of its contents? Before this PR restoring it would be easy as far as I can tell, maybe not so afterwards.

rouault commented 3 years ago

By that you mean removing it from HEAD and onwards, right?

yes, just from HEAD. no git history rewriting

Do we have a backup plan in case the CDN for some unforseen reason is wiped of its contents?

eh we pay a lot for the 99.999999999% durability of S3 storage ;-) . The back up plan would be to checkout all git tags and run the ./sync_to_cdn.sh script.

kbevers commented 3 years ago

eh we pay a lot for the 99.999999999% durability of S3 storage ;-)

I seem to recall that we get that free of charge from Amazon :-) But the durability should be the same! An unforeseen reason could also be a user error (i.e. me!). Just trying to think ahead here, the unexpected is bound to happen at some point. Checking out the tags and running the script is a sufficient backup plan at this point!