| 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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Update database layout version number to 1.2 consequently
This new capability will be used by IAU planetary CRS (refs #2601)
|
|
This seriously impacts French CRS users with the introduction of new
datums, geodetic CRS and projected CRS based on "RGF 93 v2" and "RGF 93 v2b",
and the previous single "RGF 93" being renamed as "RGF 93 v1".
To be noted too, the addition of a null transformation between NAD83(2011)
and WGS 84, which impacts a number of tests in the test suite.
|
|
|
|
authority_citation, uri) for parity with WKT2:2019
|
|
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.
|
|
Fix issue reported in https://lists.osgeo.org/pipermail/proj/2021-July/010318.html
|
|
is contained within a larger one
Relates to https://github.com/OSGeo/gdal/issues/3998
Before that change, cs2cs on a NAD83(HARN) to WGS84 transformation would
use the "NAD83(HARN) to WGS 84 (1)" transformation (a null Helmert
shift) that is valid for whole US, including non-CONUS areas, even when
used on points located on CONUS that has a "NAD83(HARN) to WGS 84 (3)"
transformation (non-null Helmert shift) with same accuracy (1m).
But if doing EPSG:2874 "NAD83(HARN) / California zone 5 (ftUS)" to
WGS84, we would use this later "NAD83(HARN) to WGS 84 (3)"
transformation because the area of use of EPSG:2874 restricts to CONUS.
This isn't consistant.
With that change, we now have more consistent behavior, even if it can
be argued which of the 2 transformations is the best...
$ echo 34 -120 | src/cs2cs -d 8 EPSG:4326 "NAD83(HARN)" | src/cs2cs "NAD83(HARN)" EPSG:2874
5955507.74 1828410.98 0.00
$ echo 34 -120 | src/cs2cs EPSG:4326 EPSG:2874
5955507.74 1828410.98 0.00
|
|
None of our tables are indexed by a INTEGER PRIMARY KEY, but most of
them are by a (auth_name, code) primary key. Consequently they can
benefit from being created as WITHOUT ROWID tables
(https://sqlite.org/withoutrowid.html), which avoids an index to be
created on the rowid we don't use. WITHOUT ROWID is a feature added in
SQLite 3.8.2, so as our baseline is 3.11, we can use it.
This decreases the DB size from 7,749,632 to 7,229,440 bytes, without
any measurable consequence on performance.
|
|
* Add a PROJ_DATA.VERSION in proj.db to indicate the target PROJ-data
package version
* Make projsync use that information and the version_added and
version_removed properties added in https://github.com/OSGeo/PROJ-data/pull/67
to filter out files that are not relevant
* Add --no-version-filtering and --verbose switches
|
|
|
|
|
|
Non-trivial updates:
- some vertical CRS are now encoded as DerivedVerticalCRS. e.g EPSG:8228
"NAVD88 height (ft)", with base EPSG:5703 "NAVD88 height". As we don't
have support in our PROJ db model for DerivedVerticalCRS, modify the
import script to 'resolve' the derivation up to the original datum.
- Method EPSG:1069 'Change of Vertical Unit' is no longer used. It is
replaced by a generic-purpose EPSG:1104 method that doesn't take any
conversion factor. And generic conversions EPSG:7812 and EPSG:7813 are
now used in concatenated operations, which require code changes as
well.
|
|
CRS::normalizeForVisualization(): propagate domains/extent of original CRS (fixes #2603)
|
|
specified name
|
|
|
|
|
|
Database: decrease db size
|
|
If using the proposed patch in PR #2616 refreshed as,
```
diff --git a/src/4D_api.cpp b/src/4D_api.cpp
index c7725d3a..3bd58a97 100644
--- a/src/4D_api.cpp
+++ b/src/4D_api.cpp
@@ -998,7 +998,7 @@ static void reproject_bbox(PJ* pjGeogToCrs,
constexpr int XY_SIZE = N_STEPS_P1 * 4;
std::vector<double> x(XY_SIZE);
std::vector<double> y(XY_SIZE);
- const double step_lon = (east_lon - west_lon) / N_STEPS;
+ const double step_lon = (((east_lon >= west_lon) ? east_lon : east_lon + 360) - west_lon) / N_STEPS;
const double step_lat = (north_lat - south_lat) / N_STEPS;
for( int j = 0; j <= N_STEPS; j++ )
{
@@ -1244,7 +1244,7 @@ std::vector<PJCoordOperation> pj_create_prepared_operations(PJ_CONTEXT *ctx,
{
const bool isOffshore =
areaName && strstr(areaName, "- offshore");
- if( west_lon <= east_lon )
+ if( true || west_lon <= east_lon )
{
op = add_coord_op_to_list(i, op,
west_lon, south_lat, east_lon, north_lat,
```
we'd get an incorrect result on one point, using the 'Pulkovo 1942 to WGS 84 (16)' less accurate transformation
due to mis-computation of bounding boxes.
```
--- ../test/cli/tv_out.dist 2021-04-07 22:29:02.706095239 +0200
+++ test/cli/tv_out 2021-04-07 22:29:35.809579495 +0200
@@ -499,7 +499,7 @@
##############################################################
Check that we can use a transformation spanning the antimeridian (should use Pulkovo 1942 to WGS 84 (20))
50 179.999999999 49d59'59.36"N 179d59'52.133"W 0.000
-50 -179.999999999 49d59'59.36"N 179d59'52.133"W 0.000
+50 -179.999999999 49d59'59.422"N 179d59'52.184"W 0.000
##############################################################
Check that we can use a transformation spanning the antimeridian (should use Pulkovo 1942 to WGS 84 (20))
5540944.47 499999.999 49d59'59.36"N 179d59'52.133"W 0.000
```
|
|
We never select by those columns, so don't set them. Reduce from 8.4 to
7.9 MB.
Upgrade the minor version of the database layout. (that database can
still be read by PROJ 8.0)
|
|
if the replacement uses a grid unknown to us.
Fixes issue reported at https://lists.osgeo.org/pipermail/gdal-dev/2021-March/053771.html
The issue comes from the fact that EPSG has created 2 transformations
using grids BALR2009.gsb ad PENR2009.gsb that supersede the one which
uses the single grid SPED2ETV2 we have in PROJ-data.
|
|
This will help getting more consistent results between the 2D and 3D
cases, as identified in
https://github.com/OSGeo/PROJ/issues/2587#issue-836061171
|
|
several auxiliary DBs
|
|
|
|
for intermediate objects
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
control where coordinate operations are looked for (fixes #2442)
|
|
cs2cs: add --area and --bbox options to restrict candidate coordinate operations (fixes #2423)
|
|
unused ones
|
|
operations (fixes #2423)
|
|
output by cct (#2453)
Currently the output of the cct utility is different between radians
and degrees (as expected by cct), because of a bug in cct:
$ printf "1 2\n" | cct -z 0 -t 0 +proj=pipeline +step +proj=unitconvert +xy_in=deg +xy_out=rad
1.0000000000 2.0000000000 0.0000 0.0000
$ printf "1 2\n" | cct -z 0 -t 0 +proj=pipeline +step +proj=unitconvert +xy_in=deg +xy_out=deg
1.0000 2.0000 0.0000 0.0000
The arguments to the printf format string are as follows:
* radians: width 14, precision 10
* degrees: width 13, precision 4 (this is by mistake. bug!)
After the suggested fix has been applied, output will be the same for
both radians and degrees:
$ printf "1 2\n" | cct -z 0 -t 0 +proj=pipeline +step +proj=unitconvert +xy_in=deg +xy_out=rad
1.0000000000 2.0000000000 0.0000 0.0000
$ printf "1 2\n" | cct -z 0 -t 0 +proj=pipeline +step +proj=unitconvert +xy_in=deg +xy_out=deg
1.0000000000 2.0000000000 0.0000 0.0000
The cause of the bug is that cct does test if it "has radians to output",
but "neglects" to test if it "has degrees to output", resulting in using
different arguments to the printf format string in the latter case.
The fix makes cct test if it "has either radians or degrees to output".
|
|
|
|
GEOIDMODEL[]
|
|
Similarly as for projinfo, allow "cct @filename" to mean read filename and
use its content as if it was provided inline. Useful for WKT or PROJJSON
And a tiny improvements, when the object definition contains ':', only try
proj_create_from_database() if the left part (authority name) matches a known
authority, to avoid a warning.
|
|
Running cct like
cct EPSG:8366
or
cct "ITRF2014 to ETRF2014 (1)"
is now possible.
|
|
|
|
DatumEnsemble, typically for WGS 84 and ETRS89 ('breaking change')
|
|
PROJ one
|
