| Age | Commit message (Collapse) | Author |
|---|
|
Height/Depth reversal methods
- For instantiation from urn combined references, create a better name,
using conventions of EPSG vertical CRS
- For exportToWKT(), allow export in WKT < WKT2 for such
DerivedVerticalCRS
|
|
|
|
to list all geoid model names that apply to a vertical CRS
|
|
test_network.cpp: try to fix 'Please include winsock2.h before windows.h' warning with msys
|
|
warning with msys
```
In file included from D:/a/_temp/msys/msys64/mingw64/include/curl/system.h:422,
from D:/a/_temp/msys/msys64/mingw64/include/curl/curl.h:38,
from D:/a/PROJ/PROJ/test/unit/test_network.cpp:48:
D:/a/_temp/msys/msys64/mingw64/x86_64-w64-mingw32/include/winsock2.h:15:2: warning: #warning Please include winsock2.h before windows.h [-Wcpp]
15 | #warning Please include winsock2.h before windows.h
| ^~~~~~~
```
Seems to be what is described in https://curl.se/mail/lib-2016-12/0047.html
|
|
|
|
syntax
|
|
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.
|
|
|
|
PROJ_SPATIAL_CRITERION_PARTIAL_INTERSECTION if area is specified"
This reverts commit ebe3425bf66287e004958eb53976d3837f88b9e1.
It was found to break gdalwarp usage in
https://github.com/OSGeo/gdal/issues/3695 when passing a bbox that is
quite large.
|
|
createFromUserInput(): change name of CRS built from URN combined references to match the convention of EPSG projected CRS
|
|
createOperations(): fix Geog to Geog when one is deprecated (fix master regression)
|
|
to match the convention of EPSG projected CRS
|
|
regression)
|
|
Closes #2667
|
|
|
|
ESRI:103668+EPSG:5703 (#2669)
|
|
proj_get_crs_info_list_from_database() filter on and return celestial body name
|
|
CRS::normalizeForVisualization(): propagate domains/extent of original CRS (fixes #2603)
|
|
specified name
|
|
|
|
|
|
(fixes #2603)
|
|
|
|
|
|
|
|
syntax
|
|
syntax
|
|
|
|
e.g:
http://www.opengis.net/def/crs/EPSG/0/4326
http://www.opengis.net/def/crs-compound?1=http://www.opengis.net/def/crs/EPSG/0/4326&2=http://www.opengis.net/def/crs/EPSG/0/3855
|
|
Database: decrease db size
|
|
CI: build and test on MSYS2 with Windows
|
|
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)
|
|
createBetweenGeodeticCRSWithDatumBasedIntermediates() reachable...
... and optimize its execution time by rewriting it completely.
This code path was no longer triggered in tests since EPSG got a direct
transformation for GDA94 to WGS 84 (G1762).
|
|
+hyperbolic
|
|
/ Vanua Levu Grid'
|
|
names
|
|
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.
|
|
|
|
Issue spotted by GDAL autotest suite.
|
|
(fixes #2588)
when the source and target CRS share the same geog CRS, but the interpolation
CRS of the vertical transformation isn't the same, and a Helmert
transformation exists between them...
For example, for "CH1903+ + EGM96" to CH1903+ 3D where the interpolation
CRS is WGS84.
|
|
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
|
|
|
|
methods and params lacking an explicit EPSG id
|
|
Add capability to get SQL statements to add custom CRS in the database
|
|
proj.h: add PROJ_COMPUTE_VERSION, PROJ_VERSION_NUMBER, PROJ_AT_LEAST_VERSION macros
|
|
be returned by proj_create_crs_to_crs()
|
|
macros
Makes it easier for users to test if they build against a PROJ version
later than a given x.y.z version.
|
