| Age | Commit message (Collapse) | Author |
|---|
|
|
|
WGS84
|
|
|
|
|
|
|
|
|
|
when possible
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
I've found that if building PROJ with lto, but GDAL without lto, exceptions
thrown in PROJ are not properly captured by try {} blocks in PROJ C API,
and unexpectedly go back up to GDAL.
Might be a defect of the particular compiler I use (gcc 5.4 Ubuntu 16.04)
|
|
|
|
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
|
|
- 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
|
|
|
|
Closes #1107
|
|
Disallow use of non-projection operations in proj (was: Don't convert non-angular inputs to proj to radians)
|
|
Since the introduction of other operations types than projections it has
been unclear how proj should treat those. This commit sets record
straight once and for all: proj is only allowed to initialize operations
that take angular input and produces non-angular output, i.e.
projections. This is true to the version of proj before the introduction
of the pipeline and other non-projection operations. Users can still
initiliaze pipelines with proj as long as the resulting concatenated
operation requires angular input and outputs non-angular output.
|
|
|
|
static'ify them
|
