[PROJ] Vertical Transformations?

[Kristian Evers]

I’d rather we have a opt-in solution than an all-or-nothing solution with regards to the grids.
There’s a few things we can do to make life a bit easier for everyone though:

1. Some transformations absolutely require a grid to work and should fail if the grid is not found.
    This behaviour is already in effect if grids are not prefixed by @’s in proj-strings. Determing which
    grids are optional can be difficult, but at least any grid that is used to change vertical datum from
    an ellipsoid to a local height system should fail (case in point, in Denmark that’s a ~40 m vertical
    offset)

2. For transformations with an optional grid usage, a warning should be issued stating
    “Grid xxx is missing, install proj-datumgrid-yyy package”. Grids not part of a proj-datumgrid
    package should be linked to if possible, otherwise give the user a friendly message saying
    that they are on their own.

3. When a transformation is performed without a grid the accuracy of the transformation should
    be lowered. Possibly, this is already be done (I can’t remember and am too lazy to check).

Not all of this is immediately possible. At the moment we lack a proper way of issuing warnings
to the user and it is probably not easy to come up with a list of transformations that require grids
versus ones where grids can be regarded as optional. This is out of scope for the upcoming 6.0
release but can be included in 6.1 if someone is willing to do the work.


I have a dream that one day we will replace the datumgrid packages with a download service
where as many grids as possible can be served from. PROJ should have the ability to either
download grids when the need arises (or at least make it easy for users to do so themselves).
At this point it is just a vision and I am not particularly keen on taking on this task myself but I
would be very happy to see this happen within the next couple of years.

/Kristian

On 20 Feb 2019, at 15:14, Andrew Bell <andrew.bell.ia at gmail.com<mailto:andrew.bell.ia at gmail.com>> wrote:



On Wed, Feb 20, 2019 at 9:06 AM Even Rouault <even.rouault at spatialys.com<mailto:even.rouault at spatialys.com>> wrote:
On mercredi 20 février 2019 08:12:34 CET Greg Troxel wrote:
> Even Rouault <even.rouault at spatialys.com<mailto:even.rouault at spatialys.com>> writes:
> > With the vertconc.gtx grid available, you'll get
> >
> > $ echo "45 -100 100" | cs2cs -f "%.8f" EPSG:7406 EPSG:5500
> > 44.99998071 -100.00039555 30.85853056
> >
> > Without it, you'll get just us-ft to metre for the vertical part:
> > 44.99998071 -100.00039555 30.48006096
>
> With the grids being in separate distribution files, it seems easy to
> end up with them not installed.

Yes, but as the number of grids is growing over time, putting them in a single
package would be an annoyance for people who have local needs.

People have so much bandwidth and space now...

Perhaps it would be good to have the default be everything and allow a reduced set to be available for those who need that?

--
Andrew Bell
andrew.bell.ia at gmail.com<mailto:andrew.bell.ia at gmail.com>
_______________________________________________
PROJ mailing list
PROJ at lists.osgeo.org<mailto:PROJ at lists.osgeo.org>
https://lists.osgeo.org/mailman/listinfo/proj

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20190220/9bafa4be/attachment-0001.html>