| Age | Commit message (Collapse) | Author |
|
ETRS89 (EPSG:4937), make sure that the vgridshift is applied first (ie on Amersfoort datum) before the hgridshift
|
|
geoidgrids
Fixes https://lists.osgeo.org/pipermail/proj/2019-May/008519.html
|
|
Reduce database size
|
|
|
|
return if the intersection of the areas is empty
|
|
|
|
|
|
|
|
doing geog2D<-->geog3D conversions of same datum
Seen when testing transformations between "CR 05" (EPSG:5365) and "CR-SIRGAS" (EPSG:8907)
which require going through their corresponding 3D GeogCRS to find a Helmert
transformation.
|
|
intermediate IDs (fixes #1343)
|
|
createOperations(): improve BoundCRS<-->non-bound-CRS case
|
|
Fixes #1301
This function takes the output PJ from proj_create_crs_to_crs(),
and add (or undo) the needed axis swap operations so that the
object returned by proj_normalize_for_visualization() has the usual
GIS axis order.
In this implementation, this does something only if the coordinate
system of the source or target CRS, geographic or projected, has
NORTH, EAST ordering.
CompoundCRS wrapping those objects are also handled.
|
|
Fixes #1388
Typically helps for
projinfo -s "+proj=longlat +ellps=GRS80 +towgs84=1,2,3 +type=crs" -t EPSG:4258
by researching operations from the pivot WGS84 implied by the towgs84 clause
to EPSG:4258.
|
|
|
|
Coverity CID 193519
|
|
Grid related fixes
|
|
the file system, but not in the database
|
|
even if there is one on upper node
This is a particular logic allowed by paragraph 7.3.3 Identifier
of OGC 18-010r6
|
|
- Allow ID[] in base CRS of Derived CRS
- Allow VERSION[] in non-conversion coordinate operations
- Use VERSION[] to set operationVersion member of CoordinateOperation
- Export operationVersion in WKT2:2018
|
|
|
|
|
|
|
|
|
|
|
|
Breathe 4.12.0 (as pulled by MacOSX builds such as
https://travis-ci.com/OSGeo/proj.4/jobs/185395222)
does not seem to like default initialization in documented C++ structs (regression/bug)
/Users/travis/build/OSGeo/proj.4/docs/source/development/reference/cpp/io.rst:6:Parsing of expression failed. Using fallback parser. Error was:
Error in postfix expression, expected primary expression or type.
If primary expression:
Invalid definition: Expected identifier in nested name. [error at 67]
std::string osgeo::proj::io::AuthorityFactory::CRSInfo::authName = {}
-------------------------------------------------------------------^
If type:
Invalid definition: Expected identifier in nested name. [error at 67]
std::string osgeo::proj::io::AuthorityFactory::CRSInfo::authName = {}
-------------------------------------------------------------------^
|
|
And publish link to corresponding promoted and public OGC doc:
http://docs.opengeospatial.org/as/18-005r4/18-005r4.html
|
|
-D_GLIBCXX_ASSERTIONS on WKT with PARAMETERFILE (fixes #1290)
|
|
transformations between geographic CRS of same datum (typically 3D to 2D)
|
|
horizontal transformation
|
|
|
|
used to know if it includes a very approximative transformation term
|
|
name we are lacking an ellipsoid height to vertCRS height correction
|
|
swap/unitconvert to avoid useless simplification rules
|
|
|
|
transformation when needed, and also sort Null geographic offset transformation in last
|
|
from X to X' in transformation name
|
|
substitution for VERTCON method
|
|
there is no direct transformation
|
|
table, should be considered as known to be sorted first
|
|
the push/pop v_3 operator to preserve the Z component
|
|
from +proj=helmert/molodensky since there are ambiguities
|
|
* Make tmerc an alias for etmerc
This switches the algorithm used in tmerc to the Poder/Engsager
tmerc algorithm. The original tmerc algorithm of Evenden/Snyder
origin can still be accessed by adding the +approx flag when
initializing a tmerc projection. The +approx flag can also
be used when initializing UTM projections, in which case the
Evenden/Snyder algorithm is used as well.
If a tmerc projection is instantiated on a spherical earth
the Evenden/Snyder algorithm is used as well since the
Poder/Engsager algorithm is only defined on the ellipsoid.
+proj=etmerc can still be instantiated for backwards compatibility
reasons.
Co-authored-by: Kristian Evers <kristianevers@gmail.com>
Co-authored-by: Even Rouault <even.rouault@spatialys.com>
|
|
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=12854. Credit to OSS Fuzz
|
|
bindins terms in generated pipeline (fixes #1232)
|
|
|
|
(fixes #1224)
|
|
parsed appropriately on the reading side
|
|
As discussed in https://github.com/OSGeo/proj.4/issues/1214#issuecomment-452084720,
the introduction of a new PROJ.5 format to export CRS using pipeline/unitconvert/axisswap
as an attempt of improving the PROJ.4 format used by GDAL and other products is
likely a dead-end since it is still lossy in many aspects and can cause confusion
with coodinate operations.
Consequently the PROJ_5 convention will be identical to PROJ_4 for CRS export.
Note: on the import side, I've kept the code that could parse unitconvert and
axisswap when building a CRS definition from a pipeline. It is there as a hidden
feature as it was kind of a tear to remove that code in case it might still be
useful...
|
|
operations when neededs (fixes #1197)
|
|
|