[PROJ] [EXTERNAL] Re: Proj 6 API questions

[Kristian Evers]

> On 28 Mar 2019, at 18:02, Lesparre, Jochem <Jochem.Lesparre at kadaster.nl> wrote:
> 
> Kristian,
> 
> I have the feeling that when we continue with what you call nit-picking, we might come to a better solution than either of us forsaw at the beginning.
> 

Don't get me wrong, I am enjoying this discussion immensely! I absolutely agree that there’s a good chance that a better solution is found when the problem is discussed properly.


> You are right that for a generic solution the datum transformation might be a bit tricky. The solution you proposed is ok, but could be a bit confusing to users.
> It might be clearer for users to give them the choice to compute distances in either the original CRS (default) or transformed to ITRS or any another CRS of choice.

I am proposing a better and more robust default solution than what is currently available in QGIS. I am all for a highly configurable setup but that is not available today. Personally I would be pleased to be able to twist and turn the knobs but I am not sure that is the best option for a GIS user who is not aware of the intricasies of geodesy.

> In that case it would make more sense to give the cartesian distance (for a projected or geocentric CRS) instead and only give ellisoidal distances for a geographic CRS.

I disagree. I think that will be the source of many very wrong distance and area calculations. But this is more of a user experience problem than a geodetic problem.

> That would give the user full controll; e.g. when computing the distance between points in a projected legacy CRS, by selecting the appropriate CRS (s)he can get: the planar distance in the projection plane, the ellispodal distance in the legacy CRS, the ellispoidal distance in ITRS with GRS80, the cartesian distance in geocentric coordinates (in ITRS), or any other option (s)he prefers.

Again, this would be cool to have, but I am not sure that it appeals to that many GIS user. I have seen something similar to this in a commercial GIS and I am glad that I had some knowledge about the topic beforehand, otherwise I would not have been able to figure it out. Sensible defaults should in my opinion be offered out of the box and not be hidden behind a configurable switchboard. Luckliy those two options are not mutually exclusive. Maybe some day we will see both :-) 

/Kristian

> 
> Kind regards, Jochem
> 
> 
> -----Original Message-----
> From: Kristian Evers <kreve at sdfe.dk> 
> Sent: Thursday, March 28, 2019 5:15 PM
> To: Lesparre, Jochem <Jochem.Lesparre at kadaster.nl>; Nyall Dawson <nyall.dawson at gmail.com>; Even Rouault <even.rouault at spatialys.com>
> Cc: PROJ <proj at lists.osgeo.org>
> Subject: SV: [PROJ] [EXTERNAL] Re: Proj 6 API questions
> 
> Jochem,
> 
> We are definitely in nit-picking territory at this stage. I agree with you that it is not going to do much harm in many cases but I can think of a few where it will. Mind you, for the specific use case in QGIS a generic solution is preferable (and likely required). I believe I have proposed such a solution.
> 
> /Kristian
> 
> -----Oprindelig meddelelse-----
> Fra: Lesparre, Jochem <Jochem.Lesparre at kadaster.nl>
> Sendt: 28. marts 2019 17:00
> Til: Kristian Evers <kreve at sdfe.dk>; Nyall Dawson <nyall.dawson at gmail.com>; Even Rouault <even.rouault at spatialys.com>
> Cc: PROJ <proj at lists.osgeo.org>
> Emne: RE: [PROJ] [EXTERNAL] Re: Proj 6 API questions
> 
> Kristian,
> 
> For the Dutch national CRS (named RD), the datum transformation has an absolute precision of <1mm (since we define it by the transformation ITRS-ETRS89-RD). Here, transforming to ITRF would be more accurate since it would remove the scale error of the national CRS of 4mm/km and the NTv2-corrections of up to 25 cm. 
> 
> For some of the Dutch Caribbean islands, the scale factor is really large. Although the datum transformation is only known at metre level, I convinced that despite this inaccuracy, transforming to ITRS would give more reliable distances. I've done some consultancy in other countries too, and, I don't think the inaccuray of the datum transformation in general would harm more than the inaccuracy of legacy CRSs.
> 
> Kind regards, Jochem
> 
> 
> -----Original Message-----
> From: Kristian Evers <kreve at sdfe.dk>
> Sent: Wednesday, March 27, 2019 12:09 PM
> To: Lesparre, Jochem <Jochem.Lesparre at kadaster.nl>; Nyall Dawson <nyall.dawson at gmail.com>; Even Rouault <even.rouault at spatialys.com>
> Cc: PROJ <proj at lists.osgeo.org>
> Subject: SV: [PROJ] [EXTERNAL] Re: Proj 6 API questions
> 
> This approach assumes that a sufficiently accurate transformation between the legacy CRS and the modern CRS exists. That cannot be guaranteed and it most cases I would argue that such a transformation comes with a fair amount of uncertainty. Not doing a datum shift and simply working within the original datum avoids the introduction of errors and ensures consistency with the coordinates as they were originally measured.
> 
> I am most familiar with Danish systems and for those I would not be comfortable adding a datum shift into the mix. The transformations are simply not accurate enough across the entirety of the country (near control points everything is good, between them... who knows?).
> 
> /Kristian
> 
> -----Oprindelig meddelelse-----
> Fra: Lesparre, Jochem <Jochem.Lesparre at kadaster.nl>
> Sendt: 27. marts 2019 11:54
> Til: Kristian Evers <kreve at sdfe.dk>; Nyall Dawson <nyall.dawson at gmail.com>; Even Rouault <even.rouault at spatialys.com>
> Cc: PROJ <proj at lists.osgeo.org>
> Emne: RE: [PROJ] [EXTERNAL] Re: Proj 6 API questions
> 
> Kristian is right that just using a modern ellipsoid for distances/areas in an old but still used national CRS would give errors.
> However, I think computing distances/areas using the old ellipsoid of that CRS is also not correct for most users. Therefore, I suggest:
> 
> 1. Back-project the projected coordinates to geodetic coordinates using the Ellipsoid parameters of the CRS datum.
> 2. Perform datum transformation to the most recent realisation of the currently accepted scientific CRS of that planet (currently ITRF2014 for Earth) with its ellipsoid (currently GRS80 for Earth).
> 3. Perform geodesic calculations using this ellipsoid parameters of this CRS datum.
> 
> Kind regards, Jochem
> 
> 
> 
> Disclaimer:
> De inhoud van dit bericht is uitsluitend bestemd voor geadresseerde.
> Gebruik van de inhoud van dit bericht door anderen zonder toestemming van het Kadaster is onrechtmatig. Mocht dit bericht ten onrechte bij u terecht komen, dan verzoeken wij u dit direct te melden aan de verzender en het bericht te vernietigen. 
> Aan de inhoud van dit bericht kunnen geen rechten worden ontleend.
> 
> Disclaimer:
> The content of this message is meant to be received by the addressee only.
> Use of the content of this message by anyone other than the addressee without the consent of the Kadaster is unlawful. If you have received this message, but are not the addressee, please contact the sender immediately and destroy the message.
> No rights can be derived from the content of this message
> 
> 
> Disclaimer:
> De inhoud van dit bericht is uitsluitend bestemd voor geadresseerde.
> Gebruik van de inhoud van dit bericht door anderen zonder toestemming van het Kadaster is onrechtmatig. Mocht dit bericht ten onrechte bij u terecht komen, dan verzoeken wij u dit direct te melden aan de verzender en het bericht te vernietigen. 
> Aan de inhoud van dit bericht kunnen geen rechten worden ontleend.
> 
> Disclaimer:
> The content of this message is meant to be received by the addressee only.
> Use of the content of this message by anyone other than the addressee without the consent of the Kadaster is unlawful. If you have received this message, but are not the addressee, please contact the sender immediately and destroy the message.
> No rights can be derived from the content of this message
> 
> 
> Disclaimer:
> De inhoud van dit bericht is uitsluitend bestemd voor geadresseerde.
> Gebruik van de inhoud van dit bericht door anderen zonder toestemming van het Kadaster 
> is onrechtmatig. Mocht dit bericht ten onrechte bij u terecht komen, dan verzoeken wij u 
> dit direct te melden aan de verzender en het bericht te vernietigen. 
> Aan de inhoud van dit bericht kunnen geen rechten worden ontleend.
> 
> Disclaimer:
> The content of this message is meant to be received by the addressee only.
> Use of the content of this message by anyone other than the addressee without the consent 
> of the Kadaster is unlawful. If you have received this message, but are not the addressee, 
> please contact the sender immediately and destroy the message.
> No rights can be derived from the content of this message