| Age | Commit message (Collapse) | Author |
|
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.
|
|
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.
|
|
|
|
<--> vertical transformations
|
|
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)
|
|
|
|
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)
|
|
Mercator projection, but with subtlely different parameters (fixes https://github.com/OSGeo/gdal/issues/2087)
|
|
|
|
operation that involves a vertical axis reversal
|
|
CRS and Projected CRS
|
|
Optimize pipelines involving horizontal shift grid, vertical shift grid, inverse horizontal shift grid (take 2)
|
|
createOperations(): optimize compoundCRS to geogCRS, when the geogCRS of the compoundCRS is the same as the target geogCRS
|
|
Add proj_create_derived_geographic_crs() and proj_create_conversion_pole_rotation_grib_convention() to address GRIB datasets using a pole rotation method
|
|
inv constructs
Given an initial pipeline with
+step +proj=hgridshift +grids=foo
+step +proj=vgridshift +grids=bar
+step +inv +proj=hgridshift +grids=foo
Transform it as
+step +proj=push +v_1 +v_2
+step +proj=hgridshift +grids=foo +omit_inv
+step +proj=vgridshift +grids=bar
+step +inv +proj=hgridshift +grids=foo +omit_fwd
+step +proj=pop +v_1 +v_2
So as to avoid doing a double application of the hgridshift.
|
|
not mess the derivingConversion object of the original object (fixes #1736)
normalizeForVisualization(), promoteTo3D(), demoteTo2D(), alterGeodeticCRS(),
alterCSLinearUnit() and alterParametersLinearUnit() all used the object
returned by derivingConversionRef() to create a new ProjectedCRS. While doing
so, this caused the derivingConversion of the original object to have its
targetCRS set to the object returned by normalizeForVisualization() and similar.
If that object died, then the weak pointer would be reset, and the original
ProjectedCRS() has now its derivingConversionRef()->targetCRS() nullptr
So bottom line is use derivingConversion() for anything that is not pure
reading !!!
This is confirmed to be the fix for the QGIS scenario in
https://github.com/qgis/QGIS/issues/30569#issuecomment-540060919
In QGIS use case, the issue arised when using a projected CRS with a non-GIS
friendly axis (that is where normalizeForVisualization() created a new projectedCRS)
|
|
compoundCRS is the same as the target geogCRS
|
|
proj_create_conversion_pole_rotation_grib_convention() to address GRIB datasets using a pole rotation method
|
|
|
|
whose datum has a publication date older than the source and target datums
|
|
|
|
Populated from realization_epoch column from EPSG
The 'publication_date' naming is from OGC Topic 2, and hasn't been yet adopted
by the EPSG dataset.
See http://docs.opengeospatial.org/as/18-005r4/18-005r4.html , Annex G, clause 11
and https://32zn56499nov99m251h4e9t8-wpengine.netdna-ssl.com/wp-content/uploads/2019/09/EPSG-relational-data-model-changes_2019-09-18.pdf
|
|
distinguish null transform from ballpark transform
|
|
faithful serialization of the geoid_geog_crs parameter of proj_create_vertical_crs_ex()
|
|
+geoidgrids and +vunits != m
|
|
|
|
geog2D transformation to a geog3D
Fixes for example EPSG:4979 to EPSG:2189, as raised in
https://github.com/OSGeo/gdal/issues/1972#issuecomment-548814354
|
|
in CRS name
|
|
03, 06, 09 and 18. Related to https://github.com/OSGeo/proj-datumgrid/pull/60 that add those grids in proj-datumgrid-north-america
|
|
Better filtering based on extent and performance improvements
|