| Age | Commit message (Collapse) | Author |
|
Map it to 'Lambert Cylindrical Equal Area' / EPSG:9835 non-spherical
method, when the ellipsoid is not a sphere. And rationalize the
handling of this for other methods with spherical vs non-spherical formulations
|
|
19111
|
|
|
|
|
|
Times and Vertical Near Side Perspective projections
|
|
Earth 2 projection
|
|
|
|
|
|
Closes #1258
|
|
Fixes #1490
This is an extension of the Window-specific logic added recently to
Unix builds. This reuses parts of proposed past commit
https://github.com/OSGeo/PROJ/pull/1517/commits/82a07e51c6e24ddb936d131ababe29f1ac36ef14
(credits to @abellgithub)
|
|
|
|
|
|
Fixes #1750
|
|
(gr3df97a.txt) and map them to new +proj=xyzgridshift
|
|
look for .tif extension
|
|
Implement RFC5: Adopt GeoTIFF-based grids for grids delivered with PROJ
|
|
|
|
|
|
|
|
grid_alternatives, fix related entries and simplify/robustify logic to deal with EPSG 'Geographic3D to GravityRelatedHeight' methods
|
|
Fixes #1867
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
proj-datumgrid new filelist.csv file
|
|
|
|
|
|
|
|
Add scripts/grid_checks.py
|
|
Little script used lately to check consistency of the database
regarding the grid_transformation vs grid_alternatives tables.
And also check the content of the database vs proj-datumgrid
to identify gaps.
|
|
proj_create_conversion_pole_rotation_grib_convention() to address GRIB datasets using a pole rotation method
|
|
[ci skip]
|
|
|
|
Populated from realization_epoch column from EPSG
The 'publication_date' naming is from OGC Topic 2, and hasn't been yet adopted
by the EPSG dataset.
See http://docs.opengeospatial.org/as/18-005r4/18-005r4.html , Annex G, clause 11
and https://32zn56499nov99m251h4e9t8-wpengine.netdna-ssl.com/wp-content/uploads/2019/09/EPSG-relational-data-model-changes_2019-09-18.pdf
|
|
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()
|
|
|
|
Height Depth Reversal and use it in createOperations()
|
|
HEAD/1.90dev happy (fixes #1648)
|
|
arbitrary number of steps (fixes #1632)
EPSG:9103 (NAD27 to ITRF2014 (1)) is now handled.
Note:EPSG:9104 (NAD27 to ITRF2014 (2)) is not currently, since it uses
for step EPSG:8861 (NAD83(HARN) to NAD83(FBN) (1))
an unsupported transformation method (NADCON5 (3D), EPSG:1075).
|
|
In recent commits, we added a generalize_proj_crs_create_bound_vertical_crs_to_WGS84()
function, but there are situations where more accurate results can be obtained, if
instead of specifying WGS84 as the hub CRS, the user can specify the exact hub CRS.
For example the GEOID2018 grid is against NAD83(2011).
So replace this function with proj_crs_create_bound_vertical_crs()
|
|
The doxygen log-files was previously put in /tmp. This is usually fine
on UNIX-type systems but when building the docs on Windows with Cygwin/MSYS2
tools the script can fail since that path is guaranteed to exist. This
commit makes sure that the doxygen script outputs its files in a path
relative to the current working directory.
|
|
approximate as WKT1 that doesn't support it
|
|
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
|
|
Upgrade Travis CI distribution
|
|
* Split global before_install for apt and pip
* Use -qq option for apt-get, which implies -y
* Use list of targets with apt-get rather than one-per-line
* Use local variables for mingw32/install.sh
* Show version info for cppcheck, pip and python
* Simplify clang+llvm-6 path
|