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