Closed internoot closed 2 years ago
Thanks! It can be done inside the same code base, with an extra argument to let it know what datum you're using. I have it in mind to add this to the next release assuming Geoscape don't change the GNAF schema & PIDs again!
A quick and dirty fix for you would be to do a string replace in all the gnaf-loader files to change the coordinate system SRID from 4283 to 7844. That "should" work.
I did essentially that - forked your repo and substituted the SRIDs, but also wrapped all the static polygon/point definitions inside ST_Transform
statements. I thought about adding an argument but the SQL scripts themselves have a lot of SRID references too and I couldn't think of a quick & easy way to handle those short of duplicating them and having both GDA94 and GDA2020 copies!
You can see the diff here: https://github.com/internoot/gnaf-loader/commit/9c16235522e324ecf8bc51be43db3377c8eff7e0
I'm just running it now on the GDA2020 admin boundaries, unsure if the fields for these actually differ from the GDA94 boudary files - if I don't have success then I will alter the arguments in import_shapefile_to_postgres()
to reproject the GDA94 files into GDA2020 on the way in.
FYI - I've deferred this for a week or 2 due to current workload. It'll be a separate release to the November 202111 release that just went live.
GDA2020 support added in PR #64
This is a very handy project, thanks for making it available to the world.
I'm curious if support for loading the GDA2020 admin boundaries is on the radar? Obviously maintaining 2 code paths isn't desirable but I imagine a lot of folks have migrated to GDA2020 some time ago.
If not, can you suggest an approach that might achieve the same outcome - ie loading the GDA94 boundaries and performing an in-place translation to the 2020 datum?