| Age | Commit message (Collapse) | Author |
|
Relates to #2115
With the fix of https://github.com/OSGeo/PROJ/pull/2128, transforming between
EPSG:4326+3855 and EPSG:4269+5703 leads to many operations with many grids,
and opening a file handle for each operation saturates the limit of 1024
file handles opened simunalteously. This fix defers grid opening when a
transformation has already been instanciated with the same grid.
|
|
(fixes #2115)
|
|
|
|
|
|
|
|
createFromUserInput(): allow compound CRS with the 2 parts given by names, e.g. 'WGS 84 + EGM96 height'
|
|
e.g. 'WGS 84 + EGM96 height'
|
|
|
|
geographic CRS as 3D (fixes #2122)
|
|
possible (fixes #2116)
|
|
pj_phi2(): speed-up computation (and thus inverse ellipsoidal Mercator and LCC)
|
|
grid_transformation_custom.sql for geoid grids (fixes #2112)
|
|
compoundCRS (fixes #2108)
|
|
Approximate tmerc (Snyder): speed optimizations
|
|
Extended tmerc (Poder/Engsager): speed optimizations
|
|
* Use instead of CMAKE_SOURCE_DIR and CMAKE_BINARY_DIR
* Also PROJECT_SOURCE_DIR and PROJECT_BINARY_DIR, which are similar
* Set properties with a list variable rather than a long line
* Correction to 'proj_test_set_properties' function, rename ENVIRONMENT:
- PROJ_IGNORE_USER_WRITABLE_DIRECTORY (ignored)
- PROJ_SKIP_READ_USER_WRITABLE_DIRECTORY (used by filemanager.cpp)
|
|
equal to a ESRI alias (fixes #2099)
|
|
(#2102)
Fixes #2096
|
|
|
|
https://github.com/OSGeo/gdal/issues/2347)
|
|
NAD_1983_HARN_StatePlane_Colorado_North_FIPS_0501 with Foot_US unit (fixes #2086)
|
|
proj_create_crs_to_crs_from_pj()
|
|
* Checks CMake's find_package(PROJ) and find_package(PROJ4)
* Checks pkg-config used with a Makefile (Linux and macOS only)
* Use proj.h / libproj with a simple 'testappprojinfo'
|
|
rouault/fix_proj_get_suggested_operation_with_operations_without_area_of_use
proj_get_suggested_operation(): fix when there are only operations without area of use
|
|
area of use
|
|
|
|
(fixes #2012)
|
|
Deprecate proj_list_angular_units(). Follow-up of https://github.com/OSGeo/PROJ/pull/2065
|
|
https://github.com/OSGeo/PROJ/pull/2065
|
|
Using {PROJVERSION} and {PROJDATAVERSION} substitutes the macro for the current
version numbers of PROJ and PROJ-data.
Rephrased a few sections regarding grid packages.
Closes #2072
Co-authored-by: Mike Taves <mwtoews@gmail.com>
|
|
Add proj_get_suggested_operation()
|
|
|
|
Add proj_get_units_from_database() (fixes #2004)
|
|
|
|
|
|
Return the index of the operation that would be the most appropriate to
transform the specified coordinates.
This operation may use resources that are not locally available, depending
on the search criteria used by proj_create_operations().
This could be done by using proj_create_operations() with a punctual bounding
box, but this function is faster when one needs to evaluate on many points
with the same (source_crs, target_crs) tuple.
|
|
|
|
|
|
|
|
https://github.com/OSGeo/PROJ-data/pull/16
|
|
|
|
representation of EPSG:2193
Adresses https://github.com/OSGeo/gdal/issues/2303 by raising the
identification confidence from 25% to 90% (90% means equivalent for
all purposes, but name not strictly the EPSG official one)
|
|
|
|
This does not change the numeric values returned by the method,
as far as I could see on a few samplings.
The tricks used save a call to sin() and atan() at each iteration.
This directly affects speed of inverse Mercator and LCC (among others),
in their ellipsoidal formulation.
Timings on inverse Mercator show a 31% speed-up at mid-latitudes
where pj_phi2() needs 5 iterations, and 24% at latitudes close to 0 or
90deg where it needs one iteration.
|
|
opposed to the spherical one)
Instead of 'elliptical'.
Was suggested by @cffk in https://github.com/OSGeo/PROJ/pull/2030#issuecomment-596132341
An elliptical projection is a projection whose global shape fits inside an
ellipsoid, like Mollweide. At least according to
https://www.merriam-webster.com/dictionary/elliptical%20projection
and
https://en.wikipedia.org/wiki/Mollweide_projection
|
|
|
|
ENOMEM was wrongly set after setting PJD_ERR_ELLIPSOID_USE_REQUIRED
Note: it is a bit strange to forbid the pure spherical case whereas the
maths would allow it. I presume this is due to the typical usage of those
methods.
|
|
https://github.com/OSGeo/PROJ/issues/2032 (#2037)
|
|
Map ESRI Transverse_Mercator_Complex to Transverse Mercator
|
|
According to https://gis.stackexchange.com/questions/226679/complex-utm-projection
it is highly likely that Transverse_Mercator_Complex corresponds to our
extended/enhanced/Poder-Engsager transverse mercator method (etmerc), or something
similarly precise. So we can map that to the standard Transverse Mercator
method, since etmerc is used for it.
|