[QGIS-Developer] QGIS and Proj 6

[C Hamilton]

Nyall,

I just wanted to thank you for doing this. QGIS is already awesome, but
this makes it even more awesome.

Calvin

On Mon, Jun 3, 2019 at 3:28 AM Nyall Dawson <nyall.dawson at gmail.com> wrote:

> Hi all,
>
> Following the merge of https://github.com/qgis/QGIS/pull/30040 , I now
> consider QGIS' port to the Proj 6 API complete. Here's a bit of a
> summary of what's been done here (on builds based on proj 6.1 and
> later only, more on that later[1])
>
> - The Proj CRS database is now used to populate QGIS' internal CRS
> database. We no longer use the combination of GDAL CSV files and
> manual QGIS overrides we've used till now. This means that ALL
> responsibility for CRS definitions and updating these sit were they
> belong, upstream in the proj library. It also means we'll be an exact
> match wrt projections as other tools which have completed the port,
> such as GDAL 3.0. (All this goodness is thanks to the GDAL barn
> raising effort). We still HAVE an internal projection database, in
> order not to break existing 3.x API, so we'll need to revisit that at
> 4.0 and see if it can be safely removed then.
>
> - We rely entirely on Proj 6's wonderful logic for generating the best
> coordinate operation to transform between CRS pairs now. This means
> (amongst other stuff), we correctly support complex things like
> operations which require a "pivot datum", e.g. transformation to and
> from GDA2020 coordinate systems. Again, this is thanks to the GDAL
> barn raising effort... if it wasn't for that, we'd be... YEARS away
> from even dreaming about supporting these correctly. Seriously, hats
> off to the proj/GDAL teams here, they've done a brilliant effort, and
> have been tirelessly answering tons of questions on their mailing
> lists.
>
> - Instead of the older approach QGIS used for datum transformations
> (carrying around our own table of when grid shift files can be used),
> we now use proj to determine these. This considerably changes the user
> interface shown when a user has opted into selecting manually a
> transform to use when multiple transforms exist, and we now show a
> simplified list of available (and non-available) pathways.
>
> - We also use proj's database to populate lists of available
> ellipsoids for use in distance and area calculations. This has cleaned
> up the ellipsoid choices considerably, and added many additional
> ellipsoid definitions as a result. (woohoo... no more duplicate
> "WGS84"/"WGS 84" entries!)
>
> - The UX for notifying users about issues in coordinate transforms is
> greatly improved, e.g. users are now alerted when a more accurate
> transform is possible, but not usable on their system (e.g. due to
> missing .gsb grid shift files). Wherever possible, we present users
> with direct download links to obtain these required/desired grid shift
> files. The intention here is to ensure users are informed when
> transforms can be improved, instead of silently falling back to less
> accurate options.
>
> - Users also now have the option of placing grid shift files in "proj"
> folder off their user profile. This means users can install grid shift
> files and make them available in QGIS without requiring administrative
> rights (possibly in future we could make QGIS fire up a background
> task which automatically downloads and installs grids on demand...)
>
> - We've also completed a project which began back in the lead-up to
> 3.0, which ensures that project-specific transformation pathway
> settings are correctly respected EVERYWHERE a coordinate transform is
> performed. This also means we're ready for the next stage in handling
> 4d coordinate transforms (when these start to land in 2020 and beyond)
>
> As noted above, a lot of this is only possible thanks to improvements
> in the proj and gdal libraries, which landed as a result of the GDAL
> barn raising effort. On the QGIS side, it was ONLY possible thanks to
> funding from the Australian ICSM. It's been a HUGE undertaking, so I'm
> extremely grateful that the ICSM has had the foresight to invest into
> QGIS and open source software development in this way.
>
> Nyall
>
> [1] Note that building 3.8 using the Proj 6 library requires a minimum
> of Proj 6.1 -- it's not possible to build using Proj 6.0. There was an
> API call added in 6.1 which we require, and I couldn't work around.
> Sorry for any inconveniences this causes!
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20190603/64bab76e/attachment.html>