| Age | Commit message (Collapse) | Author |
|---|
|
as CompoundCRS with a VerticalCRS being an ellipsoidal height, which is
not conformant. But needed for LAS 1.4 that only supports WKT1
This is a partial backport of https://github.com/OSGeo/PROJ/pull/2450,
with only the new ALLOW_ELLIPSOIDAL_HEIGHT_AS_VERTICAL_CRS=YES option
of proj_as_wkt()
|
|
projinfo (unless --single-line is specified) (fixes #1543)
|
|
Update to EPSG 10.003 and make code base robust to dealing with WKT CRS with DatumEnsemble
|
|
AuthorityFactory::ObjectType::DYNAMIC_GEODETIC_REFERENCE_FRAME and DYNAMIC_VERTICAL_REFERENCE_FRAME, and make corresponding C API work
|
|
This is a peculiarity of the WKT grammar. Despite ISO 19111 saying that the
prime meridian is a component of the datum, in WKT, they are placed at the
same level, for backward compatibility with earlier WKT versions. So handle
exporting and importing that. The fix is only for situation where DATUM is
the top level object (was working fine otherwise), which is a uncommon use
case. And to limit the amount of issue, on export emit the prime meridian only
if it is not Greenwich.
|
|
from ObjectUsage
as mandated by ISO 19111:2019
|
|
accuracy, or derive it from the grid name if it is known
|
|
Geog2D+GravityRelatedHeight (US .gtx)' method used by Slovakian geoids correctly deal with axis order and unit conversion, to be used as 'standalone'. Also improves when using directly 'Geographic3D to GravityRelatedHeight' method
|
|
Fixes https://github.com/qgis/QGIS/issues/36111
|
|
|
|
|
|
|
|
This commit is the result of the squashing of rfc4_dev branch in a single
commit. It implements mostly RFC 4 related work.
* Grid handling:
- remove obsolete and presumably unfinished implementation of grid catalog functionality
- all grid functionality is in grids.cpp/.hpp
- vertical and horizontal grid shift: rework to no longer load whole grid into memory
- remove hgrids and vgrids member from PJ structure, and store them in hgridshift/vgridshift/deformation structures
- build systems: add optional libtiff dependency. Must be explicitly disabled if not desired
- add support for horizontal and vertical grids in GeoTIFF, if libtiff is available
- add GenericShiftGridSet and GenericShiftGrid classes, relying on TIFF grids, that can be used for generic purpose grid-based adjustment
- add a +proj=xyzgridshift method to perform geocentric translation by grid. Used for French NTF to RGF93 transformation using gr3df97a.tif grid
- deformation: add support for +grids= for GeoTIFF grids
- horizontal grid shift: fix failures on points slightly outside a subgrid (fixes #209)
* File management:
- add a filemanager.cpp/.hpp to deal with file related work
- test for legacy proj_api.h fileapi
- proj.h: add proj_context_set_fileapi() and proj_context_set_sqlite3_vfs_name() (fixes #866)
- add capability to read resource files from the user writable directory
* Network access:
- build systems: add optional curl dependency
- add a curl-based default implementation for network related functionality
- proj.h: add C API to control network functionality, and optionaly provide network callbacks
- add data/proj.ini with default settings
- add a SQLite3 local cache of downloaded chunks
- add proj_is_download_needed() and proj_download_file()
* Use Win32 Unicode APIs and expect all strings to be UTF-8 (fixes #1765)
For backward compatibility, if PROJ_LIB content is found to be not UTF-8 or
pointing to a non existing directory, then an attempt at interpretating it
in the ANSI page encoding is done.
proj_context_set_search_paths() now assumes strings to be in UTF-8, and
functions returning paths will also return values in UTF-8.
|
|
|
|
intermediates B and C, such there's a A->B operation and C->D operation, and A and C are not exactly the same CRS but use the same geodetic datum
|
|
This was introduced in 63857c92b271bbcd10df0a032304982011acb2a9. Due to
the fix done in the previous commit, we can mostly revert the above commit.
We just keep the added tests and the custom WGS 84<-->WGS 84 (Gxxxx) null
transformations.
|
|
operations that belong to different authorities. Should make the concept of geodetic_datum_preferred_hub introduced some time ago obsolete
|
|
a proj_create_vertical_crs_ex()
|
|
|
|
'NAVD88 (ftUS)' to X, where we now consider the available transformations from 'NAVD88' to X that might exist in the database
|
|
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).
|
|
- 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
|
|
to exported PROJJSON strings
|
|
Transformation and ConcatenatedOperation
|
|
|
|
|
|
|
|
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"
|
|
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
|
|
|
|
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
|
|
* 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)
|
|
ISO19111: remove PROJ.5 specific format for CRS (refs #1214)
|
|
simplified version of it
|
|
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...
|
|
|
|
|
|
|
|
to restrict and prioritize searches
|
