| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
proj_experimental.h header
|
|
We store the PJ_CONTEXT* in the PJ_OBJ objects, but this
might cause issues in multi-threaded uses.
For example, before this change, let's imagie:
- a PJ_OBJ is created in thread A with a PJ_CONTEXT that
is specific to this thread A
- PJ_OBJ is transfered to another thread that operates on
it. It might thus use the PJ_CONTEXT that was TLS(A)
- in the meantime thread A does completely different things,
but still operate on its PJ_CONTEXT. We might get a
concurrent use of the PJ_CONTEXT despite working on
different PJ_OBJ
Another situation is when using constructor functions that
take two PJ_OBJ. Up to now, we arbitrarily selected the context
of one of the arguments to attach it to the new object.
So better be explicit on which context is used.
For reference, in those wrappers of the C++ API, the
context is mostly used for two things:
- reporting C++ exceptions as PROJ errors with the error handler
attached to the PJ_CONTEXT
- using the database handle that is associated with the PJ_CONTEXT.
|
|
|
|
|
|
- proj_obj_create_projected_XXXXX() are renamed to
proj_obj_create_conversion_snake_case() and just instanciate
a Conversion object
- Advanced manipulation functions are moved to a dedicated
section at bottom of proj.h
- New C API needed for GDAL OGRSpatialReference
|
|
|
|
|
|
|
|
the data/epsg and data/IGNF files
|
|
|
|
|
|
|
|
of use argument, and make createFromUserInput() recognize init=epsg: / init=IGNF: in legacy mode, that is when proj_context_get_use_proj4_init_rules() is used
|
|
|
|
|
|
authname
|
|
authority
Up to now, we re-processed the data/IGNF PROJ.4 definition to ingest it into proj.db,
but this file originally come from a processing of IGNF.xml
( http://librairies.ign.fr/geoportail/resources/IGNF.xml )
The end result is not strictly equivalent, as data/IGNF has some 'magic' to create
towgs84 / nadgrids, since IGNF.xml doesn't necessary contain all transformations
from its geodetic systems to WGS84. I've tried to re-add some of those missing transforms
(null Helmert transforms), so it can be used for pivoting, but that might be incomplete.
|
|
- createFromPROJString(): take into account axisswap step for Krovak and Transverse Mercator (South Orientated)
- Geocentric export to PROJ4: use datum when possible, and add explicit units=m
- ESRI WKT parser: make it case insensitive to parameter and projection names, and more tolerant about possible parameter name aliases
- import from WKT1 for Polar_Stereographic: don't be case sensitive
- importFromPROJString: allow pm to override datum
- Equidistant cylindrical: add support for non-standard latitude of natural origin, used in a GDAL test case
- tmerc export to PROJString: use 'k' instead of 'k_0'
- pj_ellps: use official value from EPSG for reverse flattening of Airy ellipsoid
- GDAL compatibility: add support for importing odd formulations of Mercator as WKT1, but rejecting them when exporting to PROJ
- Add export of 'Geostationary Satellite (Sweep X)' to WKT1_GDAL via EXTENSION.PROJ4 node
- importFromPROJString: add support for +f
- WKT1 / PROJ4: add support for EXTENSION.PROJ4 nodes and +wktext
- exportToWKT: change way we deal with AXIS by default for WKT1_GDAL
- Improve etmerc handling
- Fix WKT import of peg_point_heading for Spherical_Cross_Track_Height
- International Map of the World Polyconic: change parameter mapping
- exportToPROJ: add alpha parameter
- Hotine_Oblique_Mercator_Two_Point_Natural_Origin: GDAL_WKT1 related fix
- GDAL compatibility improvements in import from PROJ4 / WKT1 for polar stereographic
- Add support for +towgs84 when importing a +proj=geocent
- import from WKT1: add support for an odd Mercator_1SP formulation handled by GDAL
- export to proj4 strings: add +units=m to projected CRS for better GDAL compatibility
- export to proj4 strings: add +no_defs to CRS for better GDAL compatibility
|
|
This work mostly consists of:
- a C++ implementation of the ISO-19111:2018 / OGC Topic 2
"Referencing by coordinates" classes to represent Datums,
Coordinate systems, CRSs (Coordinate Reference Systems) and
Coordinate Operations.
- methods to convert between this C++ modeling and WKT1, WKT2
and PROJ string representations of those objects
- management and query of a SQLite3 database of CRS and Coordinate Operation definition
- a C API binding part of those capabilities
This is all-in-one squashed commit of the work of
https://github.com/OSGeo/proj.4/pull/1040
|
|
Modifications for Intel compilers
|
|
|
|
|
|
|
|
Nigrated from:
schwehr/gdal-autotest2:cpp/third_party/proj/pj_phi2_test.cc@master
License intentionally changed from Apache 2 to match PROJ.
|
|
|
|
Refines #1034
|
|
For CMake builds, latest googletest 1.8.0 is downloaded.
Following officially recommended integration for CMake-enabled projects
https://github.com/google/googletest/blob/master/googletest/README.md
"Use CMake to download GoogleTest as part of the build's configure step.
This is just a little more complex, but doesn't have the limitations
of the other methods."
Since, our copy of test/googletest
- is a very minimalist copy of googletest
- does not include any official CMake scripts
- would require copying parts of googletest CMakeLists.txt, compilater/linker flags (e.g. -lpthreads)
for reliable multi-platform builds, it is reasoanable to rely on download
All pros and cons advantages are discussed in teh README.md linked above.
Closes #1033
|
|
builds only (CMake integration to be done)
|
|
|
|
|
