aboutsummaryrefslogtreecommitdiff
path: root/include/proj/io.hpp
AgeCommit message (Collapse)Author
2019-03-16Run scripts/reformat_cpp.shEven Rouault
2019-03-16Fix doc generation with Breathe 4.12.0Even Rouault
Breathe 4.12.0 (as pulled by MacOSX builds such as https://travis-ci.com/OSGeo/proj.4/jobs/185395222) does not seem to like default initialization in documented C++ structs (regression/bug) /Users/travis/build/OSGeo/proj.4/docs/source/development/reference/cpp/io.rst:6:Parsing of expression failed. Using fallback parser. Error was: Error in postfix expression, expected primary expression or type. If primary expression: Invalid definition: Expected identifier in nested name. [error at 67] std::string osgeo::proj::io::AuthorityFactory::CRSInfo::authName = {} -------------------------------------------------------------------^ If type: Invalid definition: Expected identifier in nested name. [error at 67] std::string osgeo::proj::io::AuthorityFactory::CRSInfo::authName = {} -------------------------------------------------------------------^
2019-03-01Doc: rename to ISO-19111:2019Even Rouault
And publish link to corresponding promoted and public OGC doc: http://docs.opengeospatial.org/as/18-005r4/18-005r4.html
2019-02-11Make tmerc an alias for etmerc. (#1234)Kristian Evers
* Make tmerc an alias for etmerc This switches the algorithm used in tmerc to the Poder/Engsager tmerc algorithm. The original tmerc algorithm of Evenden/Snyder origin can still be accessed by adding the +approx flag when initializing a tmerc projection. The +approx flag can also be used when initializing UTM projections, in which case the Evenden/Snyder algorithm is used as well. If a tmerc projection is instantiated on a spherical earth the Evenden/Snyder algorithm is used as well since the Poder/Engsager algorithm is only defined on the ellipsoid. +proj=etmerc can still be instantiated for backwards compatibility reasons. Co-authored-by: Kristian Evers <kristianevers@gmail.com> Co-authored-by: Even Rouault <even.rouault@spatialys.com>
2019-02-07Add proj_get_crs_info_list_from_database()Even Rouault
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.
2019-01-22Coordinate operation computation with boundcrs / wktext: drop useless early ↵Even Rouault
bindins terms in generated pipeline (fixes #1232)
2019-01-18Merge pull request #1223 from rouault/unify_proj_createKristian Evers
Unify proj_create(), proj_create_from_user_input() and proj_create_from_proj_string() (fixes #1214)
2019-01-17Remove proj_create_from_proj_string() and proj_create_from_user_input(), and ↵Even Rouault
make proj_create() do more or less what proj_create_from_user_input() did before (fixes #1214)
2019-01-17Remove wrong use of PROJ_CONST_DECL and replace it with PROJ_PURE_DECL ↵Even Rouault
(fixes #1224)
2019-01-17import/export PROJ strings from ISO19111 code: require/output +type=crs for ↵Even Rouault
CRS objects (refs #1214)
2019-01-09Merge pull request #1217 from rouault/remove_proj_5_crs_exportEven Rouault
ISO19111: remove PROJ.5 specific format for CRS (refs #1214)
2019-01-09proj.db search: use pj_find_file() mechanism instead of hand coded ↵Even Rouault
simplified version of it
2019-01-08ISO19111: remove PROJ.5 specific format for CRS (refs #1214)Even Rouault
As discussed in https://github.com/OSGeo/proj.4/issues/1214#issuecomment-452084720, the introduction of a new PROJ.5 format to export CRS using pipeline/unitconvert/axisswap as an attempt of improving the PROJ.4 format used by GDAL and other products is likely a dead-end since it is still lossy in many aspects and can cause confusion with coodinate operations. Consequently the PROJ_5 convention will be identical to PROJ_4 for CRS export. Note: on the import side, I've kept the code that could parse unitconvert and axisswap when building a CRS definition from a pipeline. It is there as a hidden feature as it was kind of a tear to remove that code in case it might still be useful...
2018-12-17Add WKT1 grammar validation; change prototype of proj_obj_create_from_wkt()Even Rouault
2018-12-07Various speed optimizationsEven Rouault
2018-12-06Add API to retrieve non-deprecated equivalent of an objectEven Rouault
2018-12-06Coordinate operation search: add a authority_to_authority_preference table ↵Even Rouault
to restrict and prioritize searches
2018-12-06Take into account supersession information to filter out irrelevant ↵Even Rouault
transformations
2018-12-04Improve recognition of WKT1 datum namesEven Rouault
2018-12-03projinfo: add a --area option (refs #1188)Even Rouault
2018-12-03Export to ESRI WKT: make it use verbatim WKT definition from the database ↵Even Rouault
when possible
2018-11-29Redirect epsg:XXXX and IGNF:XXXX CRS expansions to the database, and remove ↵Even Rouault
the data/epsg and data/IGNF files
2018-11-29cs2cs: upgrade to use proj_create_crs_to_crs()Even Rouault
2018-11-22Make proj_create_crs_to_crs() use proj_obj_create_operations() and use area ↵Even Rouault
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
2018-11-19Assorted set of fixes for PROJString to ISO19111 model:Even Rouault
- 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
2018-11-14Implement RFC 2: Initial integration of "GDAL SRS barn" workEven Rouault
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