| Age | Commit message (Collapse) | Author |
|
|
|
Previous version was describing oea by mistake. It is also a projection
by Snyder and the isea docs was based on the paper on the oea
projection. This commit fixes that.
|
|
|
|
and IGNF init-files
|
|
(https://github.com/OSGeo/PROJ/pull/1755) regarding how resource files are looked for
|
|
(without recent Win32 specific addition)
|
|
Update README, install.rst and resource_files.rst
|
|
- Content partly borrowed from @kbevers ' suggestions of
https://github.com/OSGeo/PROJ/issues/1751#issuecomment-558976968
- Remove mention about Swiss grids. Included in the europe package
- Remove section about HARN / HPGN grids. Those have been included
in the north-america package, and there is no longer any point in
mentionning the particularities of how ancient ones had to be
used with PROJ.4
- Remove section about obsolete proj_defs.dat
|
|
PROJ is now a proper OSGeo project, let's advertise it as such!
|
|
|
|
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)
|
|
locations that require TLS/SSL, however the ssl module in Python is not available.'
|
|
|
|
|
|
about.rst
|
|
|
|
Affected parameters of Plate Motion Models.
Spotted by Xavier Collilieux on https://lists.osgeo.org/pipermail/proj/2019-November/009011.html
|
|
refreshed online version. Does not concern 6.2 branch itself)
[skip appveyor]
|
|
[Backport 6.2] Fix proj_assign_context()/pj_set_ctx() with pipelines and alternative coord operations
|
|
|
|
operations
Fixes https://github.com/OSGeo/gdal/issues/1989
pj_set_ctx() only changes the context to the main object. It should also
recurse down to the steps of the pipeline and the alternative coordinate
operations hold in alternativeCoordinateOperations
In the GDAL use case with multithreaded reprojection, and objects being transferred
between thread, this would cause a failed coordinate transformation to affect
an unrelated transformation of another thread...
|
|
[Backport 6.2] Doc: document oddity related to identification of CRS from ESRI WKT
|
|
Or more generally formulations that don't have an explicit axis order.
Refs https://github.com/pyproj4/pyproj/issues/475
projinfo 'GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137.0,298.257223563]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]]'
returns EPSG:4326 with 100% confidence.
But its axis order is not the same as EPSG:4326.
I've pondered about this, like decreasing the confidence of the match,
but this would have downstream effects on GDAL (shapefiles with the
above content in a .prj would no longer be identified as EPSG:4326).
So for now, document that oddity.
|
|
|
|
[Backport 6.2] updated docker URLs and added Fedora entry
|
|
|
|
|
|
|
|
[Backport 6.2] Doc: fixes in usage/transformation.rst
|
|
- Section about cs2cs no longer applies to PROJ 6. Ammended to underline
that.
- Remove no longer relevant/unclear caveats.
|
|
[Backport 6.2] createOperations(): in some circumstances we wrongly promoted a Helmert geog2D transformation to a geog3D
|
|
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
|
|
|
|
|
|
[Backport 6.2] Document PROJJSON
|
|
[Backport 6.2] createFromWkt(): be tolerant to missing scale_factor parameter (fixes #1700)
|
|
This is invalid WKT, but GDAL 2.4 used to accept it and make a reasonable
use of it...
Currently we default it to 0 which is non sensical. Better use 1 as GDAL 2.4
did, and emit a warning.
Other fix: proj_create_from_wkt() was documented to operate by default in
non-strict validation mode, but it was actually in strict mode. So do as
documented.
|
|
to its current location
|
|
More could probably be written, but at least this can serve as a
landing/reference page for other documents/specifications to point to.
|
|
|
|
|
|
|
|
|
|
|
|
[Backport 6.2] Add code of conduct
|
|
[Backport 6.2] importFromWkt(): fix axis orientation for non-standard ESRI WKT (fixes #1690)
|
|
|
|
|
|
[Backport 6.2] createOperations(): fix double vertical unit conversion from CompoundCRS to other CRS when the horizontal part of the projected CRS uses non-metre unit
|
|
(fixes #1678)
|