| Age | Commit message (Collapse) | Author |
|
Relates to https://github.com/OSGeo/gdal/issues/1856
|
|
When we had a transformation between a compoundCRS and a target geographicCRS,
we did not take into account that in the vertical->other_geog_CRS transformation
we used, the other_geog_CRS was an implicit interpolation CRS. Thus before
doing vertical adjustment, we must go to this interpolation CRS.
The workflow is thus:
source CRS -> interpolation CRS + vertical adjustment + interplation CRS -> target CRS
|
|
Currently very few transformations from/to WGS84 (Gxxxx) are registered
in the EPSG database, and there isn't even transformations between WGS84 EPSG:4326
and those ones. Consequently transformations to those realizations often
ended up as no-operation, whereas going through WGS84 EPSG:4326 will bring
more meaningful results. So register those EPSG:4326<-->WGS 84 (Gxxx)
null transformations, and when having WGS 84 (Gxxx) as source/target,
consider EPSG:4326 as an intermediate.
This change has no effect on the existing direct transformations
from/to WGS 84 (Gxxx).
|
|
proj_crs_create_projected_3D_crs_from_2D() (fixes #1587)
Also add a --3d switch to projinfo
|
|
include/proj/internal/include_nlohmann_json.hpp and include/proj/internal/esri_projection_mappings.hpp
|
|
Use in API and utilities WKT2_2019 instead of WKT2_2018 (fixes #1578)
|
|
- C API: PJ_GUESSED_WKT2_2019 is added, PJ_GUESSED_WKT2_2018 aliased to it
- C API: PJ_WKT2_2019[_SIMPLIFIED] is added, PJ_WKT2_2018[_SIMPLIFIED] alias to it
- C++ API: similarly for WKTFormatter::Convention::WKT2_2019[_SIMPLIFIED]
Those above changes should be fully backward API and ABI compatible.
projinfo changes:
- accept WKT2_2019 as value for -o switch. WKT2_2018 is still accepted (undocumented)
- output now uses 'WKT2_2019 string:', so might break scripts that would rely on that.
Other internal code references to WKT2_2018 changes to WKT2_2019, included
in tests.
|
|
|
|
+datum=NAD27 and +over, where the datum was just replaced by its ellipsoid
|
|
database (fixes #1565)
|
|
to exported PROJJSON strings
|
|
Dynamic[Geodetic|Vertical]ReferenceFrame
|
|
Transformation and ConcatenatedOperation
|
|
|
|
|
|
|
|
|
|
metadata from a grid filename
|
|
ETRS89 (EPSG:4937), make sure that the vgridshift is applied first (ie on Amersfoort datum) before the hgridshift
|
|
from their components
Support following syntaxes:
- OGC URN combining references for compoundCRS:
e.g. "urn:ogc:def:crs,crs:EPSG::2393,crs:EPSG::5717"
- its GDAL shortcut: e.g. "EPSG:2393+5717"
- OGC URN combining references for concatenated operations:
e.g. "urn:ogc:def:coordinateOperation,coordinateOperation:EPSG::3895,coordinateOperation:EPSG::1618"
|
|
CMake: better support for Intel compiler
|
|
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.
|
|
|
|
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.
|
|
even if there is one on upper node
This is a particular logic allowed by paragraph 7.3.3 Identifier
of OGC 18-010r6
|
|
This is a particular logic allowed by paragraph 7.3.3 Identifier
of OGC 18-010r6
|
|
This is the standard logic, that is now possible since ID is
allowed in BASEGEOGCRS and similar node
|
|
|
|
- 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
|
|
Normalize CMake with cmakelint, 2-space indent
|
|
|
|
- coordinateoperation_internal.hpp: missing 'explicit' keyword
- proj.cpp: unused 'generic' member in enumeration
- init.cpp: useless assignment to a_orig and es_orig, because done again a
few lines below.
- crs.cpp: unused variable
- datum.cpp: inefficient use of find() function
- io.cpp:
* missing 'static' qualifier for method
* useles ternary test (left and right have same value)
- aeqd.cpp: useless assignment of inv and fwd, snice done again a few lines
below
- isea.cpp: useless assignment of resolution and aperture since done again a
few lines below, and with default values when params are absent
- mod_ster.cpp: useless assignment of lp.lam, overriden in below code paths.
- stere.cpp: false positive, but better not modify another variable than the
iterator in a for() loop.
|
|
|
|
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
|
|
|
|
|
|
used to know if it includes a very approximative transformation term
|
|
transformation when needed, and also sort Null geographic offset transformation in last
|
|
there is no direct transformation
|
|
* 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>
|
|
This method is intended to be used typically by GUI that lists all possible CRS.
What is does could be done by previously existing functions, but it is much faster.
It typically runs in less than 0.1s (hot run) versus ~0.5s with the method that
consists in enumerating all codes and instanciating a PJ object for each of them.
|
|
|
|
bindins terms in generated pipeline (fixes #1232)
|
|
|
|
Unify proj_create(), proj_create_from_user_input() and proj_create_from_proj_string() (fixes #1214)
|
|
make proj_create() do more or less what proj_create_from_user_input() did before (fixes #1214)
|
|
(fixes #1224)
|
|
CRS objects (refs #1214)
|