| Age | Commit message (Collapse) | Author |
|---|
|
Minor update w.r.t 9.5.5 that adds a few new coordinate operations.
|
|
more results
|
|
|
|
|
|
|
|
|
|
|
|
|
|
projections/ transformations/ tests/ subdirectories
|
|
|
|
|
|
|
|
transformations
|
|
|
|
|
|
|
|
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
|
|
|
|
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.
|
|
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
|
|
|
|
We want to flag that proj_api_h is now deprecated. With this commit
it is now mandatory to #define ACCEPT_USE_OF_DEPRECATED_PROJ_API_H
before proj_api.h can be included.
proj_api.h is used internally a bunch of places. Therefore
ACCEPT_USE_OF_DEPRECATED_PROJ_API_H has been defined in projects.h
and a few other necessary files to ensure that PROJ compiles.
Closes #836
|
|
Complete overhaul of HOWTO-RELEASE.
|
|
|
|
The release process is described in more details as well as adding
section covering release candidates and how to proceed after a
release.
|
|
with lcov/genhtml
|
|
|
|
Create man pages from the Sphinx documentation. Ideally the man pages
are updated completely automatic when running make dist and make install
but that is a quite complicated setup. For now a script that builds the
man pages and commits them has been created. This is to be run as part
of the release process so that man pages are aligned with the most
recent version of the docs.
|
|
travis/linux_gcc
|
|
|
|
|
|
|
