<div dir="ltr"><div>Nyall,</div><div><br></div><div>I just wanted to thank you for doing this. QGIS is already awesome, but this makes it even more awesome.</div><div><br></div><div>Calvin<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 3, 2019 at 3:28 AM Nyall Dawson <<a href="mailto:nyall.dawson@gmail.com">nyall.dawson@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br>
<br>
Following the merge of <a href="https://github.com/qgis/QGIS/pull/30040" rel="noreferrer" target="_blank">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!<br>
_______________________________________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></blockquote></div>