| Age | Commit message (Collapse) | Author |
|
NTv1 grid shift: fix file offset for reading of shift values in ntv1_can.dat
|
|
Add Lambert Conic Conformal (2SP Michigan) projection
|
|
|
|
|
|
Remove nmake build system
|
|
When investigating the format of NTv1 and comparing PROJ code with the actual
header of ntv1_can.dat, I discovered that the longitude & latitude shift values
started at offset 192, whereas PROJ assumed that the header was 176 bytes only.
This caused PROJ to use the wrong offsets values (shift of one grid sample by
longitude). So the effect was moderately visible, especially on the latitude,
but when comparing with NTv2, one can see that the longitude value after the
fix seems to closer to NTv2.
old:
echo "60.5 -100.5 0" | PROJ_LIB=/usr/share/proj src/cct -d 8 +proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +proj=hgridshift +grids=ntv1_can.dat +step +proj=unitconvert +xy_in=rad +xy_out=deg +step +proj=axisswap +order=2,1
60.50022624 -100.50040292 0.00000000 inf
new:
echo "60.5 -100.5 0" | PROJ_LIB=/usr/share/proj src/cct -d 8 +proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +proj=hgridshift +grids=ntv1_can.dat +step +proj=unitconvert +xy_in=rad +xy_out=deg +step +proj=axisswap +order=2,1
60.50022403 -100.50041841 0.00000000 inf
echo "60.5 -100.5 0" | PROJ_LIB=/usr/share/proj src/cct -d 8 +proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +proj=hgridshift +grids=$HOME/proj/proj-datumgrid/north-america/ntv2_0.gsb +step +proj=unitconvert +xy_in=rad +xy_out=deg +step +proj=axisswap +order=2,1
60.50022348 -100.50041978 0.00000000 inf
old:
$ echo "80.1 -70.9 0" | PROJ_LIB=/usr/share/proj src/cct -d 8 +proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +proj=hgridshift +grids=ntv1_can.dat +step +proj=unitconvert +xy_in=rad +xy_out=deg +step +proj=axisswap +order=2,1
80.10096789 -70.89746834 0.00000000 inf
new:
$ echo "80.1 -70.9 0" | PROJ_LIB=/usr/share/proj src/cct -d 8 +proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +proj=hgridshift +grids=ntv1_can.dat +step +proj=unitconvert +xy_in=rad +xy_out=deg +step +proj=axisswap +order=2,1
80.10096858 -70.89749190 0.00000000 inf
$ echo "80.1 -70.9 0" | PROJ_LIB=/usr/share/proj src/cct -d 8 +proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +proj=hgridshift +grids=$HOME/proj/proj-datumgrid/north-america/ntv2_0.gsb +step +proj=unitconvert +xy_in=rad +xy_out=deg +step +proj=axisswap +order=2,1
80.10096782 -70.89749276 0.00000000 inf
|
|
Before that, approximately half of the descriptions had a period at the
end, e.g. 'Cyl.' or 'Sph.' and the other half did not have those periods.
This commit drops all the dots in PROJ_HEAD descriptions.
|
|
|
|
of it (fixes #535)
|
|
The Geographic offsets transformation adds an offset to the geographic longitude,
latitude coordinates, and an offset to the ellipsoidal height.
This method is normally only used when low accuracy is tolerated. It is documented
as coordinate operation method code 9619 (for geographic 2D) and 9660 (for
geographic 3D) in the EPSG dataset.
It can also be used to implement the method Geographic2D with Height Offsets
(code 9618) by noting that the input vertical component is a gravity-related
height and the output vertical component is the ellispoid height (dh being
the geoid undulation).
It can also be used to implement the method Vertical offset (code 9616)
It is used for example to transform:
- from the old Greek geographic 2D CRS to the newer GGRS87 CRS
- from Tokyo + JSLD69 height to WGS 84
- from Baltic 1977 height to Black Sea height
It is also useful to document the implicit zero-offset transformation
we do in pipelines such as
+proj=pipeline +step +inv +proj=longlat +ellps=A
+step +proj=longlat +ellps=B
that can be explicited as
+proj=pipeline +step +inv +proj=longlat +ellps=A
+step +proj=geogoffset [+dlon=0 +dlat=0 +dh=0]
+step +proj=longlat +ellps=B
|
|
in +towgs84 case, we use sprintf() with floating-point formatter to output
the ellipsoid parameters. For a locale with decimal separtor != dot, the
resulting string will not be parsed correctly by proj_atof(), leading to
wrong numeric result.
The fix is similar to the one done in pj_latlong_from_proj()
Note for later: if using C++, we could use a locale-independent formatting
solution to avoid such issue.
|
|
|
|
- classification
- tests
- coding style
|
|
|
|
Remove misspelled-constant PJD_ERR_UNKNOW_UNIT_ID
|
|
Refactor proj
|
|
|
|
https://travis-ci.com/OSGeo/proj.4/jobs/147274068)
|
|
|
|
Closes #853
|
|
|
|
|
|
Rename nad/ as data/ and move nad/test* to test/old/*
|
|
|
|
We want to flag that proj_api_h is now deprecated. With this commit
it is now mandatory to #define ACCEPT_USE_OF_DEPRECATED_PROJ_API_H
before proj_api.h can be included.
proj_api.h is used internally a bunch of places. Therefore
ACCEPT_USE_OF_DEPRECATED_PROJ_API_H has been defined in projects.h
and a few other necessary files to ensure that PROJ compiles.
Closes #836
|
|
In version 6 we stop exposing the deprecated projects.h API to the world outside PROJ.
Closes #835
|
|
|
|
|
|
Increment age instead of revision for added interfaces, see:
https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
|
|
|
|
Previous to this commit cs2cs did not convert angular output to degrees
when using operations setting PJ->right = PJ_IO_UNITS_ANGULAR. This
commit adopts the conventions used after the introduction of pipelines.
In practice, this allows the following and similar transformations to
output in degrees and not radians:
```
echo 37.3916666667 -6.9325000 | cs2cs +proj=latlong +ellps=clrk80 \
+to +proj=molodensky +ellps=clrk80 +da=-112.145 +df=-0.54750714e-4 \
+dx=-175 +dy=-23 +dz=-303
37.39 -6.93 -8.2
```
|
|
Any text written after the coordinate input will automatically be
forwarded to the output stream. Text in columns before the coordinate
input is discarded in the output. This works for any combination of -c, -t
and -z parameters:
$ echo 12 56 100 2018.0 comment comment | cct +proj=merc
1335833.8895 7522963.2411 100.0000 2018.0000 comment commen
$ echo text 12 56 100 2018.0 comment | cct -c 2,3,4,5 +proj=merc
1335833.8895 7522963.2411 100.0000 2018.0000 comment
$ echo text 12 56 comment | cct -c 2,3 -t0 -z0 +proj=merc
1335833.8895 7522963.2411 0.0000 0.0000 comment
$ echo 12 56 comment | cct -t0 -z0 +proj=merc
1335833.8895 7522963.2411 0.0000 0.0000 comment
Closes #918
|
|
Specify number of decimals to display when transforming coordinates with either proj, cs2cs or cct.
|
|
This worked for cs2cs / pj_transform(), but not the new API
|
|
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10033. Credit to OSS Fuzz. master only
|
|
Complements f2b3604
|
|
Assorted fixes related to +geoc flag handing
|
|
[BREAKING] Helmert: add +convention=position_vector/coordinate_frame, forbids +transpose (fixes #1091)
|
|
|
|
|
|
forbids +transpose (fixes #1091)
As identified in #1091, Helmert implementation in PROJ 5.0 and 5.1 is confusing.
It happens that by default it used the coordinate_frame convention, contrary to
the position_vector convention used traditionaly for +towgs84. The documentation
of Helmert was also wrongly specifying that the default convention was
position_vector.
This commit:
- bans the confusing +transpose parameter
- removes the concept of a default convention, since in practice both are
equally found, and requires +convention as soon as a rotational term parameter
is present.
For translation only, convention is ignored and optional, as having no effect.
- fixes all the identified uses of proj=helmert in code, doc and tests
This is obviously a breaking change:
- users will have to adapt their pipeline expressions
- in particular, init files that would use helmert must be adapted
However, as designed, the break will be explicit, and not silent.
|
|
This is intended to supersed https://github.com/OSGeo/proj.4/pull/1080
with a number of differences.
What is kept from #1080 is not forcing the ellipsoid_params to be the one
of a sphere. This is not required for correct coordinate computation and
avoid lying on the various distorsion parameters.
For better interoperability with EPSG, we also no longer force the
lam0 parameter to 0, because
https://www.epsg-registry.org/export.htm?gml=urn:ogc:def:method:EPSG::1024
has a provision for it, even if in practice they will always be zero
phi0 should always be zero and is not used by the formulas.
Another difference with the #1080 approach is that we do not force the
WGS84 ellipsoid. Perhaps someone will use webmerc for another planet,
even if that is a crazy idea...
|
|
|
|
Those functions contain code specific of input != angular and output = angular
which to the best of my knowledge never happens in PROJ. Looking at that
code, I feel there are a number of errors in it, and anyway removing it shows
absolutely no change in the test suite, which shows it is unused. I've also
added exit(1) to verify that those code paths are never taken.
This was found while investigating the fix for
8cfc81380617ff4a17a06a97635f77c5e9ed7d5b
|
|
There is a regression in PROJ 5 regarding the handling of the +geoc flag,
specific to the case of +proj=longlat, and the inverse transformation,
which makes it a no-op:
echo "12 55 0 " | src/cct +proj=pipeline +step +proj=longlat +ellps=GRS80 +geoc +inv
12.0000000000 55.0000000000 0.0000 inf
With this fix, we now get:
echo "12 55 0 " | src/cct +proj=pipeline +step +proj=longlat +ellps=GRS80 +geoc +inv
12.0000000000 54.8189733083 0.0000 inf
The fix consists in making inv_prepare() do symetrically as fwd_finalize(), ie
skip a number of transforms when left and right units are angular,
and in inv_finalize() apply the (OUTPUT_UNITS==PJ_IO_UNITS_ANGULAR) processing
even if INPUT_UNITS == PJ_IO_UNITS_ANGULAR
|
|
Implement the Equal Earth projection (closes #1085)
|
|
DHDN_ETRS89 autoconf test
|
|
optimization issue with gcc 8.2 (fixes #1084)
|
|
torad_coord() of gie.c has this sequence:
```
if( cond )
axis = l->param + strlen ("axis=");
n = strlen (axis);
```
When the if branch is evaluated, n is always zero
even if on inspection axis is non empty
The reason is that the struct ARG_list which is the
type of l use a variable-length array for the param member
struct ARG_list {
paralist *next;
char used;
char param[1];
};
But this is not a proper way of declaring it, and
gcc 8 has apparently optimizations to detect that l->param + 5
points out of the array, hence it optimizes strlen() to 0.
Reported as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86914
According to https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html,
the proper way of declaring such arrays is to use [0]
|
|
src/pj_strerrno.c:96:20: runtime error: negation of -2147483648 cannot be represented in type 'int'; cast to an unsigned type to negate this value to itself
#0 in pj_strerrno proj/src/pj_strerrno.c:96:20
#1 in (anonymous namespace)::ProjErrnoStringTest_ProjErrnos_Test::TestBody() test/unit/proj_errno_string_test.cpp:47:5
ASAN UndefinedBehaviorSanitizer: signed-integer-overflow
Issue revealed by proj_errno_string_test.cpp add in
https://github.com/OSGeo/proj.4/commit/b87b59106879188ffc684a41a9de638ac5fd02bf
|