| Age | Commit message (Collapse) | Author |
|---|
|
to 2D CRS / add --3d to cs2cs
Previously, when computing transformation between a compound CRS and a
geographic/projected 2D CRS, the behaviour was similar to implicitly
promoting the 2D CRS to 3D CRS in the pipeline computation logic, hence
a geoid model could be applied. But note that when doing a geographic 3D
to geographic/projected 2D CRS transformation, we *did* not do this implicit
promotion and if a Helmert transformation existed between the datums, it
was done only in 2D. So this is a bit inconsistent and triggered the
comment in https://github.com/OSGeo/PROJ/issues/2318#issuecomment-1068924513
With this commit, we no longer do any vertical transformation when doing
compound CRS to the 2D CRS, but just take the transformation of the
horizontal part of the compound CRS to the 2D CRS.
Said otherwise, NAD83+NAVD88 to NAD83 will no longer lead to the
application of the geoid model. Unless you explicitly ask for the
promotion NAD83 to 3D.
Also related, in https://github.com/OSGeo/PROJ/issues/1563 that went to 6.3.0,
I changed cs2cs to automatically promote to 3D the CRS as soon as one of
them was compound, for the sake of being consistent with the past
behaviour. But it then becomes difficult to predict PROJ behaviour
depending on which level of it you consider...
This commit undoes that and adds an explicit --3d switch to cs2cs, similarly to
projinfo, to ask for promotion.
Other bug fix found in the process, when using legacy syntax, +init=epsg:4979,
(WGS 84 3D), the resulting CRS was 2D and not 3D.
|
|
https://lwn.net/Articles/?offset=50 was an entertaining reading where we
learn that the fact that argv[0] contains the name of the binary is
purely a convention, normally taken by the shell that launches the
process, but not guaranteed by the execve() system call that does the
job.
The following test program tested against cct, cs2cs, geod, gie and proj
make them cause a null pointer dereference
```
#include <unistd.h>
#include <stdio.h>
extern char **environ;
int main()
{
char* argv[] = { NULL };
printf("%d\n", execve("/path/to/some/proj/binary", argv, environ));
return 0;
}
```
|
|
This also fixes conversion between geocentric latlong and geodetic latlong
with cs2cs. This was dealt with in PR 1093, but in the wrong direction
(the geocentric latitude must be <= in absolute value to the geodetic one)
The issue here was linked to the semantics of the +geoc specifier, which
affects the semantics of the input coordinates in the forward direction
(+geoc means that the input coordinate is is a geocentric latitude),
which defeats the logic of doing A to B by using the inverse path of A
and the forward path of B.
|
|
|
|
|
|
control where coordinate operations are looked for (fixes #2442)
|
|
operations (fixes #2423)
|
|
|
|
|
|
result as soon as it is produced
This is needed when working with pipes, when stdout is not an interactive terminal,
and thus the behaviour is to have it buffered as a regular file, whereas with
an interactive terminal, each newline character causes an implicit flush.
|
|
|
|
(fixes #2012)
|
|
|
|
It promotes use of deprecated paramters +datum and +towgs84 which we
don't want to encourage.
Closes #1308
|
|
|
|
|
|
termination
|
|
|
|
#124)
|
|
Coverity fixes
|
|
Doc: Be consistent in use of +opts
|
|
|
|
+opt represents one parameter. An ellipsis indicates additional
instances of the previous parameter may be given.
Spaces are used between parameters and before an ellipsis, not purely to
format brackets. See man(1) SYNOPSIS conventions.
|
|
This is a bit of a hack, 4D coordinates *will* be written to STDOUT
but the output format speficied with -f is not respected for the
t component, rather it is forward verbatim from the input.
Fixes #1354
|
|
|
|
|
|
make proj_create() do more or less what proj_create_from_user_input() did before (fixes #1214)
|
|
CRS objects (refs #1214)
|
|
|
|
|
|
|
|
structures
|
|
|
|
projections/ transformations/ tests/ subdirectories
|
