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 <[email protected]> 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 > [email protected] > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
