| Age | Commit message (Collapse) | Author |
|---|
|
Fixes #1301
This function takes the output PJ from proj_create_crs_to_crs(),
and add (or undo) the needed axis swap operations so that the
object returned by proj_normalize_for_visualization() has the usual
GIS axis order.
In this implementation, this does something only if the coordinate
system of the source or target CRS, geographic or projected, has
NORTH, EAST ordering.
CompoundCRS wrapping those objects are also handled.
|
|
|
|
|
|
used to know if it includes a very approximative transformation term
|
|
there is no direct transformation
|
|
|
|
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.
|
|
make proj_create() do more or less what proj_create_from_user_input() did before (fixes #1214)
|
|
vs the ones of the C++ API (fixes #1213) (#1215)
|
|
proj_context_set_search_paths() (refs #1150)
|
|
|
|
The rest of the C API is structured such that type definitions goes into
one page and functions to another. This commit makes sure the same is
done for the C bindings to the ISO19111 C++ API by defining two doxygen
groups in proj.h, which is then organized into the proper pages with
Sphinx and breathe.
|
|
|
|
|
|
|
|
|
|
|
|
proj_destroy_string_list to proj_string_list_destroy for consistency (refs #1198)
|
|
#1198)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
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
|
|
With projects.h not being available to outside users anymore we need to
define PJ_UNITS, PJ_ELLPS, PJ_PRIME_MERIDIANS and PJ_OPERATIONS
elsewhere.
Related pj_get_*_ref() functions have been removed in favour
of their proj_ namespaced counterparts.
char pointers have been changed to const char pointers.
Resolves #983
Resolved #1147
Make char pointers const
|
|
|
|
|
|
Found on https://github.com/OSGeo/proj.4/commit/2f082b70cbdafdea49bb123e027406089e7ad65b
http://clang.llvm.org/extra/clang-tidy/checks/readability-inconsistent-declaration-parameter-name.html
function 'proj_log_level' has a definition with different parameter names
src/pj_internal.c:374:14: the definition seen here
src/proj.h:364:14: differing parameters are named here: ('level'), in definition: ('log_level')
|
|
|
|
This will help avoiding issues for people tracking proj master and GDAL
See https://lists.osgeo.org/pipermail/gdal-dev/2018-March/048285.html
|
|
Add proj_errno_string function
|
|
Equivalent to pj_strerrno.
|
|
Changes use of 'PJ_COORD coo' to 'PJ_COORD coord' so that variable names in
public function prototypes are consistent.
Closes #842.
|
|
|
|
Make 4D API fully 4D:
Remove PJ_XY, PJ_LP, PJ_XYZ, PJ_LPZ etc. from the API surface and
make all formal parameters of the API fully 4D PJ_COORD.
This operation primarily influences the proj_XXX_dist functions,
which mostly work by calling Charles Karney's geodesic
subsystem, keeping the distance, and throwing away the start and
end azimuths for the geodesic computed.
Also a PJ_GEOD(esic) persona is introduced for the PJ_COORD type.
The proj_geod function returns a PJ_GEOD, representing the geodesic
between the points represented by its PJ_COORD arguments.
Finally, the proj_factors functions had its lp argument changed
from PJ_LP to PJ_COORD.
|
