| Age | Commit message (Collapse) | Author |
|
Contributes to fixing issue raised in
https://lists.osgeo.org/pipermail/gdal-dev/2020-April/052003.html
|
|
looks like the one for WGS 84 / Pseudo Mercator (fixes https://github.com/OSGeo/gdal/issues/2433) (#2174)
|
|
Map it to 'Lambert Cylindrical Equal Area' / EPSG:9835 non-spherical
method, when the ellipsoid is not a sphere. And rationalize the
handling of this for other methods with spherical vs non-spherical formulations
|
|
(refs https://github.com/OSGeo/gdal/issues/2392)
|
|
(fixes #2115)
|
|
geographic CRS as 3D (fixes #2122)
|
|
[Backport 6.3] ESRI_WKT ingestion: make sure to identify to non-deprecated EPSG entry when possible (fixes #2116)
|
|
possible (fixes #2116)
|
|
compoundCRS (fixes #2108)
|
|
https://github.com/OSGeo/gdal/issues/2347)
|
|
representation of EPSG:2193
|
|
|
|
+nadgrids= and +pm= (#1998)
Fixes issue reported at
https://lists.osgeo.org/pipermail/gdal-dev/2020-February/051749.html
The generated pipeline assumes that the input coordinates for the grid transformation
were related to the non-Greenwich based datum, so we must compensate for that and
add logic to go back to Greenwich.
|
|
to it (fixes #1982)
|
|
|
|
Fix a few issues of #1906 found when running the test suite
on Ubuntu 16.04 with gcc 5.5 -m32. When applied on top of
the fix of #1912, make check succeeds
|
|
This should avoid issues with numerical stability as uncovered in
https://github.com/OSGeo/PROJ/issues/1906.
Practically speaking this change isn't going to affect real life
scenarios since the position of the center of the Earth is rarely
expressed in geodetic coordinates.
|
|
Fixes #1911
|
|
Fixes #1913
AuthorityFactory::createBetweenGeodeticCRSWithDatumBasedIntermediates() issued
a complex SQL query that pushes the SQLite3 query plan optimizer to its limits.
Was working reasonably with sqlite 3.11, but not with later versions.
So put less constraints in the main query and do post-processing checks and
auxiliary requests to avoid such issues.
For some unknown reason, this slightly slows down a bit execution time of the
whole test_cpp_api binary (~ 10%), but couldn't come with something better,
despite trying many variations of the main SQL query. It seems that in the
general case the non-filter LEFT JOIN on the supersession table helped,
except on this EPSG:7842 case.
|
|
Fixes #1881
Digging into the implementation of proj=cea, it appears that
k_0 and lat_ts are intended to be exclusive ways of specifying the
same concept. EPSG only models the variant using lat_s.
So if k_0 is found and lat_ts is absent, compute the equivalent
value of lat_ts from k_0.
Note: k_0 should normally be in the [0,1] range. In case creative users
would use something outside, we raise an exception, even if the cea
implementation could potentially deal with any k_0 value. Hopefully
this is a (reasonable) limitation that will address nominal use cases.
|
|
grid_alternatives, fix related entries and simplify/robustify logic to deal with EPSG 'Geographic3D to GravityRelatedHeight' methods
|
|
Fixes #1867
|
|
to units
Fixes bug reported in https://lists.osgeo.org/pipermail/gdal-dev/2020-January/051481.html
|
|
#1835)
|
|
|
|
The exception only affects C++ users. It was caught by the C layer.
|
|
|
|
|
|
As on import of EPSG, we remove the supersession of Canadian NTv1 file w.r.t NTv2
(because the default behaviour of PROJ is to ignore superseded operations). However
the NTv1 operation is advertized with an accuracy of 1m, whereas NTv2 is advertized
with 1.5m. Consequently on areas where both files are valid, and if both files are
available, NTv1 would be selected. So as a workaround, worsen the NTv1 accuracy to
2m so that NTv2 is used in priority.
|
|
fails.
Relates to https://github.com/OSGeo/PROJ/issues/1808
|
|
<--> vertical transformations
|
|
mapping between CGQ77-98.gsb and CQ77SCRS.GSB
|
|
filename substitution
|
|
|
|
rouault/improve_identification_with_datum_name_aliases
identify(): take into datum name aliases (fixes #1800)
|
|
BoundCRS::identify(): improvements to discard CRS that aren't relevant (fixes #1801)
|
|
|
|
Make EPSG:102100 resolve to ESRI:102100 (fixes #1730)
|
|
(fixes #1801)
Fix for
```
projinfo --identify "+proj=utm +zone=48 +a=6377276.345 +b=6356075.41314024 +towgs84=198,881,317,0,0,0,0 +units=m +no_defs +type=crs"
```
to only return BoundCRS of EPSG:3148: 70 %
Previously it also returned EPSG:23948 and EPSG:24048 whose projected CRS-only
parts where likely matches, but those 2 CRSs don't have a +towgs84=198,881,317,0,0,0,0,
so discard them.
|
|
rouault/restore_ob_tran_to_meter_compat_with_pj_transform
ob_tran: restore traditional handling of +to_meter with pj_transform() and proj utility (fixes #1782)
|
|
switching between (sub)grids (fixes #1663)
Given in.txt with
53.999759140 5.144478208 252.6995
Before the fix,
cct -t 0 -d 4 +proj=pipeline +step +proj=axisswap +order=2,1,3,4 +step +proj=hgridshift +inv +grids=rdtrans2018.gsb +step +proj=vgridshift +grids=naptrans2018.gtx +step +proj=sterea +lat_0=52.156160556 +lon_0=5.387638889 +k=0.9999079 +x_0=155000 +y_0=463000 +ellps=bessel in.txt
returned:
139079.8814 668306.0302 212.1724 0.0000
It now returns:
139079.8850 668306.0458 212.1724 0.0000
which meets with the 1mm accuracy the expected result of test point
```
30010049 53.999759140 5.144478208 252.6995 139079.8850 668306.0460 212.1723
```
|
|
|
|
and EPSG:32761 "WGS 84 / UPS South (N,E)"
Fixes https://github.com/qgis/QGIS/issues/33077
|
|
omit_fwd/omit_inv
|
|
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=19367
|
|
|
|
aggressive (refs #1787)
'EPSG:1304, Indian 1975 to WGS 84 (2), 5.0 m, Thailand - onshore and Gulf of Thailand'
was removed because considered useless w.r.t first result
'EPSG:1812, Indian 1975 to WGS 84 (4), 3.0 m, Thailand - onshore'
However the name of the area of use is not completely the same, so might be worth
keeping it.
|
|
|
|
proj utility (fixes #1782)
Fixes side-effect of https://github.com/OSGeo/PROJ/issues/1525 that went in 6.1.1
The correction is horribly hacky. Sorry...
|
|
(fixes #1779)
|