[PROJ] Vertical Transformations?

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[PROJ] Vertical Transformations?

Paul Ramsey
Hey, all. Having gotten a working version of proj6 support running in
PostGIS, I'm trying to look for some of the goodies that users will
get when they upgrade. An obvious one is vertical transformations... I
tried this call:

postgis30=# select st_astext(st_transform('SRID=7406;POINT(-100 45
100)'::geometry, 5500));
                    st_astext
-------------------------------------------------
 POINT Z (-100.00039555444 44.9999807122224 100)
(1 row)

But as you can see, no vertical shift, even though 7406 is NGVD29 and
5500 is NAVD88. Is there another pairing I can use that should return
a vertical shift?

For reference the call is happening here:

https://github.com/pramsey/postgis/blob/svn-trunk-proj/liblwgeom/lwgeom_transform.c#L318

Maybe compound systems don't automatically do their thing when created
using proj_create_crs_to_crs() ?

Thanks!

P
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Vertical Transformations?

Even Rouault-2
Paul,

yet another interesting use case that exhibited a few defects that should be
adressed by https://github.com/OSGeo/proj.4/pull/1279

To get the best results for the NGVD29 height (ftUS) to NAVD88 height
transformation, you need to install in $install_prefix/share/proj the VERTCON
grids that are now part of the
https://download.osgeo.org/proj/proj-datumgrid-north-america-1.2RC1.tar.gz 
package
(see the README.md of https://github.com/OSGeo/proj-datumgrid/tree/master/
north-america)

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

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Vertical Transformations?

Greg Troxel-2
Even Rouault <[hidden email]> 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.

I wonder if transformations that need grid files for correct behavior
should fail rather than skip the transformation, at least by default.

_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Vertical Transformations?

Even Rouault-2
On mercredi 20 février 2019 08:12:34 CET Greg Troxel wrote:

> Even Rouault <[hidden email]> 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.

>
> I wonder if transformations that need grid files for correct behavior
> should fail rather than skip the transformation, at least by default.

That's a complex topic. There is no "correct" behavior per-se. All
transformations are approximations, so it is a matter of how accurate your
needs are. In the above example if you're fine with ~ 1 metre vertical
accuracy, you don't need the VERTCON grids.
The EPSG database can also reference some grids that can not necessarily
easily be found, are not free, or have no known conversion to a PROJ
recognized format.

Selection of a given transformation pipeline among all possible also involve a
number of arbitrary decisions (some transformations might have intersecting
area of validity). Playing with the new projinfo utility to list available
coordinate operations can show the complexity of this...

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Vertical Transformations?

andrew.bell.ia@gmail.com


On Wed, Feb 20, 2019 at 9:06 AM Even Rouault <[hidden email]> wrote:
On mercredi 20 février 2019 08:12:34 CET Greg Troxel wrote:

> Even Rouault <[hidden email]> 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
[hidden email]

_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Vertical Transformations?

Kristian Evers-2
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 <[hidden email]> wrote:



On Wed, Feb 20, 2019 at 9:06 AM Even Rouault <[hidden email]> wrote:
On mercredi 20 février 2019 08:12:34 CET Greg Troxel wrote:
> Even Rouault <[hidden email]> 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
[hidden email]
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj


_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Vertical Transformations?

andrew.bell.ia@gmail.com


On Wed, Feb 20, 2019 at 9:42 AM Kristian Evers <[hidden email]> wrote:
I’d rather we have a opt-in solution than an all-or-nothing solution with regards to the grids.

Why?

I don't know why end-users would want to deal with this.  I would think they'd want it to work out of the box without regard to the transform they happen to be handed.

--
Andrew Bell
[hidden email]

_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Vertical Transformations?

jmckenna
Administrator
I fully agree with Andrew here, when thinking of end-users.  Most do not
know what a grid is, and will unfortunately (as of now) use the
incorrect coordinates and later face grief trying to understand why
their data doesn't match in their application (I have that t-shirt).

For my upcoming MS4W version 4 release (already available in beta) it
contains all possible PROJ grid files, which I believe end-users really
really will appreciate.

-jeff



On 2019-02-20 10:50 AM, Andrew Bell wrote:

>
>
> On Wed, Feb 20, 2019 at 9:42 AM Kristian Evers <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     I’d rather we have a opt-in solution than an all-or-nothing solution
>     with regards to the grids.
>
>
> Why?
>
> I don't know why end-users would want to deal with this.  I would think
> they'd want it to work out of the box without regard to the transform
> they happen to be handed.
>
> --
> Andrew Bell
> [hidden email] <mailto:[hidden email]>
>
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Vertical Transformations?

Kristian Evers-2
In reply to this post by andrew.bell.ia@gmail.com
>
> Why?
>
> I don't know why end-users would want to deal with this.  I would think they'd want it to work out of the box without regard to the transform they happen to be handed.


The same question can be asked for any package that has optional parts.
Why don’t GDAL include ALL possible drivers as standard? Surely that would
result in a better user experience? The same can be said for PDAL, QGIS and
a bunch of other applications in our little geospatial software ecosphere.

The answer is of course that it gives you more options. Some may want the
extra weight and some won’t.

Most of the end-users you talk about will be using PROJ via another
application such as QGIS, GDAL or PDAL. If it is important for those
projects that transformations works out of the box they can require
proj-datumgrid, proj-datumgrid-europe, proj-datumgrid-north-america
and proj-datumgrid-oceania as hard dependencies and let package systems
deal with installing everything that is needed. And the guys who run
PROJ on a small GNSS receiver can choose to not do that if they want to.


/Kristian

_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Vertical Transformations?

Martin Desruisseaux-3
In reply to this post by jmckenna
Le 20/02/2019 à 16:09, Jeff McKenna a écrit :

> Most do not know what a grid is, and will unfortunately (as of now)
> use the incorrect coordinates and later face grief trying to
> understand why their data doesn't match in their application
>
Even if all grids were supplied, transformations would still have a
limited accuracy. Users should look at the accuracy information in order
to judge if the transformation is okay for their needs (this implies
that QGIS, PostGIS, etc. should make this information easily available).
Users do not need to know the details of datum shift operations (i.e.
whether a grid is used of not), but the accuracy information is
mandatory for anyone doing scientific or engineering work. One could
object that not every users are scientist or engineer, but if a user
does not care about accuracy then he should not have grief if the data
appear shifted.

I think we should not push too far the desire to provide a black box. I
agree about hiding implementation details, but not about hiding the fact
that every transformations have a limited accuracy - this problem has
its root in the physical world and is above any map projection library.
Luring the users with the false impression that coordinate operations
have an infinite accuracy is one cause of problems we have with
inter-operability between software using different referencing libraries.

    Martin


_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Vertical Transformations?

jmckenna
Administrator
I'm actually quite fine with the current way of managing grid files.
But I believe everyone speaking here is the 1% of the 1% who understands
this (I even include me ha), so when Andrew mentioned end-users, he is
correct that 99.9% will not realize this requirement, and as packagers
we can help the end-users and include all grid files.  (maybe this
discussion is not for the PROJ list, but on a separate 'packagers' list,
but, it comes up often in the sharing community) -jeff



On 2019-02-20 11:55 AM, Martin Desruisseaux wrote:

> Le 20/02/2019 à 16:09, Jeff McKenna a écrit :
>
>> Most do not know what a grid is, and will unfortunately (as of now)
>> use the incorrect coordinates and later face grief trying to
>> understand why their data doesn't match in their application
>>
> Even if all grids were supplied, transformations would still have a
> limited accuracy. Users should look at the accuracy information in order
> to judge if the transformation is okay for their needs (this implies
> that QGIS, PostGIS, etc. should make this information easily available).
> Users do not need to know the details of datum shift operations (i.e.
> whether a grid is used of not), but the accuracy information is
> mandatory for anyone doing scientific or engineering work. One could
> object that not every users are scientist or engineer, but if a user
> does not care about accuracy then he should not have grief if the data
> appear shifted.
>
> I think we should not push too far the desire to provide a black box. I
> agree about hiding implementation details, but not about hiding the fact
> that every transformations have a limited accuracy - this problem has
> its root in the physical world and is above any map projection library.
> Luring the users with the false impression that coordinate operations
> have an infinite accuracy is one cause of problems we have with
> inter-operability between software using different referencing libraries.
>
>      Martin
>
>
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Vertical Transformations?

Even Rouault-2
In reply to this post by Kristian Evers-2
> 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)

The same could hold for the horizontal part where a missing grid might involve
~ 100m horizontal error. The new coordinate operation "computation" module
will return currently all potential coordinate operations, that is those using
grids, Helmert transformation, constant offsets, etc. and also synthetic/dummy
horizontal/vertical transformations. The sorting algorithm tries to sort first
the more relevant ones given their accuracy and grid availability.

The concept of optional grid with @ is normally not emitted by the new
computation module (except if you use the legacy nadgrids/geoidgrids terms by
using a PROJ CRS string), as it considers coordinate operations using a grid
or not as different coordinate operations

>
> 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.

The PROJ API has now a proj_coordoperation_is_instanciable(),
proj_coordoperation_get_grid_used_count() and
proj_coordoperation_get_grid_used() functions that can be used to know for a
given coordinate operation which grids are needed and if they are currently
available, and if not, where to download it when it is listed in the proj.db
database as a known grid.

>
> 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).

Yes, coordinate operations with synthetized/dummy horizontal or vertical
transformations will have a unknown accuracy.

e.g

$ src/projinfo -s EPSG:7406 -t EPSG:4979
Candidate operations found: 3
Note: using '--spatial-test intersects' would bring more results (64)
-------------------------------------
Operation n°1:

unknown id, NAD27 to WGS 84 (79) + Transformation from NGVD29 height (ftUS) to
WGS 84 (approximate transformation, without ellipsoid height to vertical
height correction), unknown accuracy, USA - CONUS including EEZ

PROJ string:
+proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert
+xy_in=deg +xy_out=rad +step +proj=hgridshift +grids=conus +step
+proj=unitconvert +xy_in=rad +z_in=us-ft +xy_out=deg +z_out=m +step
+proj=axisswap +order=2,1


> 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.

That would add a libcurl dependency. And/or add a callback mechanism to do the
download on behalf of PROJ. But as mentionned above, applications built on top
of PROJ have now what is needed to implement that.

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Vertical Transformations?

Greg Troxel-2
In reply to this post by Even Rouault-2
Even Rouault <[hidden email]> writes:

>> I wonder if transformations that need grid files for correct behavior
>> should fail rather than skip the transformation, at least by default.
>
> That's a complex topic. There is no "correct" behavior per-se. All
> transformations are approximations, so it is a matter of how accurate your
> needs are.

That's strictly true, but my understanding is there is a broad consensus
that VERTCON is the appropriate conversion for the general problem.

> In the above example if you're fine with ~ 1 metre vertical accuracy,
> you don't need the VERTCON grids.

Agreed that if you are ok with ~1m, you can assume they are the same and
not convert.  That more or less applies to all horizontal datum
conversions, with differing acceptable errors.  With NAD27, the errors
are so large that I suspect almost everyone would prefer an error to
assuming equivalence to ITRFxx, once they understood.

> The EPSG database can also reference some grids that can not necessarily
> easily be found, are not free, or have no known conversion to a PROJ
> recognized format.

So there is no real way for most people to convert to/from those datums.
That's too bad, and I agree those situations are intractable and proj
declining to convert them is not necessarily helpful.

> Selection of a given transformation pipeline among all possible also involve a
> number of arbitrary decisions (some transformations might have intersecting
> area of validity). Playing with the new projinfo utility to list available
> coordinate operations can show the complexity of this...

I realize this is all infinitely complicated.

In this case, my concern is that there is a consensus method to go
between NGVD29 and NAVD88, that I think almost everyone would agree is
the standard approach.  People who install proj but not optional
gridfiles will silently get a much coarser approximation.

So I would like to see the transform from NGVD29/NAVD88 error out when
the VERTCON grid file can't be opened, perhaps with some configuration
to say that it should assume 0 instead.  I think it's better to fail
during what I see as a misconfiguration than to fall back to a cruder
approximation.

Perhaps the evnironment variable "PROJ_NGVD29_COARSE" should be needed,
and this hint can be returned as the error from attempting to use the
gridfile.

I have ensured that the pkgsrc package for proj installs all of the
ok-licensed grid files, so it doesn't matter much to me personally.  I
see there are a lot more now, but it still seems best to include them in
the package.

I am assuming almost all use of proj other than by the developers is via
packaging systems.

It would be interesting to hear what other packagers do in terms of
grids (included, separate packages, not packaged, ?).
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Vertical Transformations?

Clifford J Mugnier

VERTCON is a "snapshot" of the differences between NGVD29 and NAVD88 as they existed in 1992.  Any subsequent vertical crustal movement since 1992 is not modeled in the data grids.  The results for major portions of Louisiana (subsidence) and the Midwest (glacial rebound & uplift) will be in error by a number of feet.  The errors will increase as time passes since the data grids will not be updated.  A similar conundrum will occur to a lesser magnitude (at first) with the new vertical datum to be published in 2022.  Someday, they may publish a VTDP (Vertical Time Dependent Positioning) model that might be "reliable."  So far, it's just a dream.  Clicking that mouse button will give you an answer, but it may be far from reality!


Clifford J. Mugnier, c.p., c.m.s.

Chief of Geodesy

LSU Center for GeoInformatics (ERAD 266)

Dept. of Civil Engineering (P.F. Taylor 3531)

LOUISIANA STATE UNIVERSITY

Baton Rouge, LA  70803

Academic: (225) 578-8536

Research: (225) 578-4578

Cell:             (225) 328-8975

honorary lifetime member, lsps

fellow emeritus, asprs

member, apsg




From: PROJ <[hidden email]> on behalf of Greg Troxel <[hidden email]>
Sent: Wednesday, February 20, 2019 10:52 AM
To: Even Rouault
Cc: [hidden email]
Subject: Re: [PROJ] Vertical Transformations?
 
Even Rouault <[hidden email]> writes:

>> I wonder if transformations that need grid files for correct behavior
>> should fail rather than skip the transformation, at least by default.
>
> That's a complex topic. There is no "correct" behavior per-se. All
> transformations are approximations, so it is a matter of how accurate your
> needs are.

That's strictly true, but my understanding is there is a broad consensus
that VERTCON is the appropriate conversion for the general problem.

> In the above example if you're fine with ~ 1 metre vertical accuracy,
> you don't need the VERTCON grids.

Agreed that if you are ok with ~1m, you can assume they are the same and
not convert.  That more or less applies to all horizontal datum
conversions, with differing acceptable errors.  With NAD27, the errors
are so large that I suspect almost everyone would prefer an error to
assuming equivalence to ITRFxx, once they understood.

> The EPSG database can also reference some grids that can not necessarily
> easily be found, are not free, or have no known conversion to a PROJ
> recognized format.

So there is no real way for most people to convert to/from those datums.
That's too bad, and I agree those situations are intractable and proj
declining to convert them is not necessarily helpful.

> Selection of a given transformation pipeline among all possible also involve a
> number of arbitrary decisions (some transformations might have intersecting
> area of validity). Playing with the new projinfo utility to list available
> coordinate operations can show the complexity of this...

I realize this is all infinitely complicated.

In this case, my concern is that there is a consensus method to go
between NGVD29 and NAVD88, that I think almost everyone would agree is
the standard approach.  People who install proj but not optional
gridfiles will silently get a much coarser approximation.

So I would like to see the transform from NGVD29/NAVD88 error out when
the VERTCON grid file can't be opened, perhaps with some configuration
to say that it should assume 0 instead.  I think it's better to fail
during what I see as a misconfiguration than to fall back to a cruder
approximation.

Perhaps the evnironment variable "PROJ_NGVD29_COARSE" should be needed,
and this hint can be returned as the error from attempting to use the
gridfile.

I have ensured that the pkgsrc package for proj installs all of the
ok-licensed grid files, so it doesn't matter much to me personally.  I
see there are a lot more now, but it still seems best to include them in
the package.

I am assuming almost all use of proj other than by the developers is via
packaging systems.

It would be interesting to hear what other packagers do in terms of
grids (included, separate packages, not packaged, ?).
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj

_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Vertical Transformations?

Even Rouault-2
In reply to this post by Greg Troxel-2
> In this case, my concern is that there is a consensus method to go
> between NGVD29 and NAVD88, that I think almost everyone would agree is
> the standard approach.

You assume that PROJ has dedicated behaviour and knowledge for NGVD29, NADVD88
and the "consensus method" to convert between them. The reality is that, and
it is a feature, it has absolutely no clue about them, being (hopefully) fully
generic and "computes" potential transformations from the information in its
database, and the grids available.


> People who install proj but not optional
> gridfiles will silently get a much coarser approximation.
>
> So I would like to see the transform from NGVD29/NAVD88 error out when
> the VERTCON grid file can't be opened, perhaps with some configuration
> to say that it should assume 0 instead.  I think it's better to fail
> during what I see as a misconfiguration than to fall back to a cruder
> approximation.

Note that this is complicated by the fact that there is not a single NGVD29-
>NAVD88 "optimal" transformation, but 3 since there are 3 grids, depending on
the area of use. When using proj_create_crs_to_crs() with no specified area of
use, there's a dynamic selection mechanism of the actual transformation,
depending on the coordinate of the point to transform and comparing it with
the area of use of the available transformations. So, if you are working in an
area where all required grids are present, it is potentially fine to proceeed,
even if in some other area a required grid would be needed.

>
> Perhaps the evnironment variable "PROJ_NGVD29_COARSE" should be needed,
> and this hint can be returned as the error from attempting to use the
> gridfile.

That shouldn't be done like that. A more generic mechanism should be found.
Nyall Dawson contacted me about a similar need, related to the possibility of
tagging some GDA94->GDA2020 grid-based transformation as required, and hard
fail if not.
We could enhance the PROJ database with a table/column to flag required
transformation, but it is probably not trivial (area of use comes into the
equation), and that would put the PROJ project in a position of being an
"authority" to decide which transformation are required or not.

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Vertical Transformations?

Greg Troxel-2
Even Rouault <[hidden email]> writes:

> We could enhance the PROJ database with a table/column to flag required
> transformation, but it is probably not trivial (area of use comes into the
> equation), and that would put the PROJ project in a position of being an
> "authority" to decide which transformation are required or not.

That sounds like a good path.

I don't see the authority problem; when implementing a transformation
that is defined to use a grid file, it's pretty clear that it can't be
done the same way without it.

If you mean the issue of a coarser transformation with assumed zero
shift, it seems that introducing that transformation as avlid is what's
problematic.

My real issue is people not getting the answer that is expected because
of not spending time on grid files that they might not even know exist.

Thanks for the discussion; we are either at (or beyond :-) the point
where further comments from me are helpful, and as always I learned
something.


Earlier I said that I included the grid files with proj, and I meant the
base proj-datumgrids, which I had thought were viewed as optional.  I
see now that they are declared as required, and that there are new
regional datumngrid files that have arisen in the last year (which have
the NGVD29 stuff).  I'm in the process of updating the pkgsrc package to
have the new regional files also.
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Vertical Transformations?

Even Rouault-2
On mercredi 20 février 2019 13:25:07 CET Greg Troxel wrote:

> Even Rouault <[hidden email]> writes:
> > We could enhance the PROJ database with a table/column to flag required
> > transformation, but it is probably not trivial (area of use comes into the
> > equation), and that would put the PROJ project in a position of being an
> > "authority" to decide which transformation are required or not.
>
> That sounds like a good path.
>
> I don't see the authority problem; when implementing a transformation
> that is defined to use a grid file, it's pretty clear that it can't be
> done the same way without it.

For horizontal datum transformations, EPSG has generally both grid-based and
Helmert-based transformations. Which are both declared as valid. Generally the
grid-based one will have a better declared accuracy, so might be prefered. But
that doesn't invalidate the Helmert-based one. Failing if the grid is not
available would be a PROJ specific policy, and not always desirable.

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Vertical Transformations?

Martin Desruisseaux-3
Le 20/02/2019 à 20:06, Even Rouault a écrit :
>
> For horizontal datum transformations, EPSG has generally both
> grid-based and Helmert-based transformations. Which are both declared
> as valid. Generally the grid-based one will have a better declared
> accuracy, so might be prefered. But that doesn't invalidate the
> Helmert-based one. Failing if the grid is not available would be a
> PROJ specific policy, and not always desirable.
>
I support this position. Both are valid transformations, differing in
their accuracy and some others considerations (performance, etc.). If
PROJ reports the accuracy of coordinate operations, users can decide if
it is good enough for their need. For example if a map is displayed on a
screen at a scale where each pixel is 1 km large, the accuracy provided
by grids is unperceptible and the Helmert-based alternative may have
performance advantages (in some cases) for this rendering purpose. An
application may want to switch between the two methods depending on the
scale of rendered map.

    Martin


_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Vertical Transformations?

Sebastiaan Couwenberg
In reply to this post by Greg Troxel-2
On 2/20/19 7:25 PM, Greg Troxel wrote:
> I'm in the process of updating the pkgsrc package to
> have the new regional files also.

Note that if your distribution requires fine-grained documentation of
license & copyright information for the files in the regional
proj-datumgrid archives, the maintenance burden is non-trivial.

This is why I will not be packaging the regional proj-datumgrid packages
for Debian. Users will need to download the tarballs and unpack their
content into /usr/share/proj themselves.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Vertical Transformations?

Greg Troxel-2
Sebastiaan Couwenberg <[hidden email]> writes:

> On 2/20/19 7:25 PM, Greg Troxel wrote:
>> I'm in the process of updating the pkgsrc package to
>> have the new regional files also.
>
> Note that if your distribution requires fine-grained documentation of
> license & copyright information for the files in the regional
> proj-datumgrid archives, the maintenance burden is non-trivial.

A good point.  I scanned them and they seem to be all Free licenses, and
we worry about the details far more when licenses are problematic.

If any of the licenses don't meet the DFSG (or the FSF Free definitinon),
I would be interested in knowing that, as that seems a much bigger deal
than simply not wanting to spend the time doing license bookeeping about
licenses that are ok.

> This is why I will not be packaging the regional proj-datumgrid packages
> for Debian. Users will need to download the tarballs and unpack their
> content into /usr/share/proj themselves.

Thanks for letting me know how you're handling it.
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
12