[QGIS-Developer] QGIS and Proj 6

[Régis Haubourg]

Let me strongly second Calvin here.
I followed your work on the PROJ mailing lists and it's a big hat off for
you Nyall. Understanding the geodesic issues and making it available into
QGIS so soon is brilliant.
I'd also like to thank your funder whoever it is, because he allowed a huge
step forward. Not so many funders are able to invest into such low level
stuff.
And I don't forget the PROJ team, we all rely on the shoulders of giants,
truly.
Big up, you rock!
Régis

Le lun. 3 juin 2019 à 15:02, C Hamilton <adenaculture at gmail.com> a écrit :

> 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
>
> _______________________________________________
> 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/d5d684d2/attachment.html>