| Age | Commit message (Collapse) | Author |
|
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.
|
|
several auxiliary DBs
|
|
|
|
auxiliary DB
|
|
|
|
|
|
for intermediate objects
|
|
|
|
|
|
|
|
* Correction grid NKG:ETRF14 to EPSG:7922
* Added NKG:ITRF_TO_NO GIE test
* Correction grid no_kv_NKGETRF14_EPSG7922_2000 added to grid_alternatives.sql
* proj_method 'velocity_grid' added in check_grid_alternatives_proj_method. NKG velocity grid added to grid_alternatives.sql
Co-authored-by: Even Rouault <even.rouault@spatialys.com>
|
|
Make proj_lp_dist() and proj_geod() work on a PJ* CRS object
|
|
|
|
in sqlite >= 3.11
|
|
|