aboutsummaryrefslogtreecommitdiff
path: root/test
AgeCommit message (Collapse)Author
2018-12-05experimental C API: add proj_obj_convert_conversion_to_other_method()Even Rouault
2018-12-05Allow ellipsoid flattening to be set to zeroKristian Evers
Issue raised in https://github.com/OSGeo/proj.4/issues/1191.
2018-12-04Add proj_obj_create_vertical_crs() and proj_obj_create_compound_crs()Even Rouault
2018-12-04WKT1 export of LOCAL_CS: add UNIT if explicitly setEven Rouault
2018-12-04export to WKT1 of geocentric CRS: do not emit a TOWGS84 node if the datum is ↵Even Rouault
WGS84
2018-12-04Improve management of 'deprecated' suffix in object namesEven Rouault
2018-12-04Improve recognition of WKT1 datum namesEven Rouault
2018-12-03Merge pull request #1189 from rouault/projinfo_improvementsEven Rouault
Projinfo improvements: output operation summary and add --area option
2018-12-03projinfo: add a --area option (refs #1188)Even Rouault
2018-12-03Merge pull request #1182 from rouault/plug_new_codeEven Rouault
Remove data/epsg, IGNF and esri.* files / support legacy +init=epsg:XXXX syntax
2018-12-03projinfo: output operation summary, even in non summary mode (refs #1188)Even Rouault
2018-12-03Export to ESRI WKT: make it use verbatim WKT definition from the database ↵Even Rouault
when possible
2018-12-03WKTParser: fix to avoid creation of empty nodesEven Rouault
2018-12-02identify: improve GeographicCRS identification when the CRS name has no matchEven Rouault
2018-12-02improve identify() for projected and bound CRSEven Rouault
2018-12-01Add testing of projinfo utilityEven Rouault
2018-12-01Fix PROJ_GRID_AVAILABILITY_IGNOREDEven Rouault
2018-12-01Rename test/old/ to test/cli/ to better reflect their natureEven Rouault
2018-12-01importFromWKT: deal with uncommon formulation of EPSG:3857Even Rouault
2018-12-01importFromWKT: morph GDAL_WKT1 datum names into their EPSG spellingEven Rouault
2018-11-30API: move all advanced PJ_OBJ creation functions in a dedicated ↵Even Rouault
proj_experimental.h header
2018-11-30C API: do not 'cache' PROJ context in PJ_OBJ objectsEven Rouault
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.
2018-11-29importFromWKT v1: properly handle latitude_of_origin=0 for Mercator_1SPEven Rouault
2018-11-29proj_create_crs_to_crs(): rename arguments, update doc, and add a few test casesEven Rouault
2018-11-29C API extensions and renamingEven Rouault
- 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
2018-11-29Preserve EPSG code when importFromWKT WKT1_GDAL of EPSG:3857Even Rouault
2018-11-29exportToWKT WKT1_GDAL: export axis by default for GeocentricCRSEven Rouault
2018-11-29importFromWKT: check we have a valid unit where we need oneEven Rouault
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-29Add unit test for pj_tranform() now that cs2cs no longer use itEven Rouault
2018-11-29Reformat test .cpp filesEven Rouault
2018-11-29cs2cs: upgrade to use proj_create_crs_to_crs()Even Rouault
2018-11-26test/fuzzers/build_google_oss_fuzzers.sh: statically link against sqlite3Even Rouault
2018-11-26test/fuzzers/build_google_oss_fuzzers.sh: link against libsqlite3Even 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-22Fix transformation between geographic CRS that differ by axis order and unitsEven Rouault
2018-11-21Move 'builtins' test of src/gie.c to test/unit/gie_self_tests.cppEven Rouault
2018-11-21createFromUserInput("authname:code"): make it case insensitive regarding ↵Even Rouault
authname
2018-11-20Database: use official IGNF.xml registry to create content from the IGNF ↵Even Rouault
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.
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
2018-10-27Implement Molodensky-Badekas transform (fixes #1160)Even Rouault
2018-10-15Add Tobler-Mercator projectionIvan Veselov
2018-10-11Merge pull request #1133 from Fil/bertin1953Kristian Evers
the Bertin 1953 projection
2018-10-11Merge remote-tracking branch 'osgeo/master' into bertin1953Kristian Evers
2018-10-11Merge pull request #1144 from rouault/ntv1_fixKristian Evers
NTv1 grid shift: fix file offset for reading of shift values in ntv1_can.dat
2018-10-11Support LCC 2SP Michigan projectionIvan Veselov
2018-10-08NTv1 grid shift: fix file offset for reading of shift values in ntv1_can.datEven Rouault
When investigating the format of NTv1 and comparing PROJ code with the actual header of ntv1_can.dat, I discovered that the longitude & latitude shift values started at offset 192, whereas PROJ assumed that the header was 176 bytes only. This caused PROJ to use the wrong offsets values (shift of one grid sample by longitude). So the effect was moderately visible, especially on the latitude, but when comparing with NTv2, one can see that the longitude value after the fix seems to closer to NTv2. old: echo "60.5 -100.5 0" | PROJ_LIB=/usr/share/proj src/cct -d 8 +proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +proj=hgridshift +grids=ntv1_can.dat +step +proj=unitconvert +xy_in=rad +xy_out=deg +step +proj=axisswap +order=2,1 60.50022624 -100.50040292 0.00000000 inf new: echo "60.5 -100.5 0" | PROJ_LIB=/usr/share/proj src/cct -d 8 +proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +proj=hgridshift +grids=ntv1_can.dat +step +proj=unitconvert +xy_in=rad +xy_out=deg +step +proj=axisswap +order=2,1 60.50022403 -100.50041841 0.00000000 inf echo "60.5 -100.5 0" | PROJ_LIB=/usr/share/proj src/cct -d 8 +proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +proj=hgridshift +grids=$HOME/proj/proj-datumgrid/north-america/ntv2_0.gsb +step +proj=unitconvert +xy_in=rad +xy_out=deg +step +proj=axisswap +order=2,1 60.50022348 -100.50041978 0.00000000 inf old: $ echo "80.1 -70.9 0" | PROJ_LIB=/usr/share/proj src/cct -d 8 +proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +proj=hgridshift +grids=ntv1_can.dat +step +proj=unitconvert +xy_in=rad +xy_out=deg +step +proj=axisswap +order=2,1 80.10096789 -70.89746834 0.00000000 inf new: $ echo "80.1 -70.9 0" | PROJ_LIB=/usr/share/proj src/cct -d 8 +proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +proj=hgridshift +grids=ntv1_can.dat +step +proj=unitconvert +xy_in=rad +xy_out=deg +step +proj=axisswap +order=2,1 80.10096858 -70.89749190 0.00000000 inf $ echo "80.1 -70.9 0" | PROJ_LIB=/usr/share/proj src/cct -d 8 +proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +proj=hgridshift +grids=$HOME/proj/proj-datumgrid/north-america/ntv2_0.gsb +step +proj=unitconvert +xy_in=rad +xy_out=deg +step +proj=axisswap +order=2,1 80.10096782 -70.89749276 0.00000000 inf
2018-10-01Add a affine transformation method, and make geogoffset as a particular case ↵Even Rouault
of it (fixes #535)
2018-10-01Add geographic offset transformation method.Even Rouault
The Geographic offsets transformation adds an offset to the geographic longitude, latitude coordinates, and an offset to the ellipsoidal height. This method is normally only used when low accuracy is tolerated. It is documented as coordinate operation method code 9619 (for geographic 2D) and 9660 (for geographic 3D) in the EPSG dataset. It can also be used to implement the method Geographic2D with Height Offsets (code 9618) by noting that the input vertical component is a gravity-related height and the output vertical component is the ellispoid height (dh being the geoid undulation). It can also be used to implement the method Vertical offset (code 9616) It is used for example to transform: - from the old Greek geographic 2D CRS to the newer GGRS87 CRS - from Tokyo + JSLD69 height to WGS 84 - from Baltic 1977 height to Black Sea height It is also useful to document the implicit zero-offset transformation we do in pipelines such as +proj=pipeline +step +inv +proj=longlat +ellps=A +step +proj=longlat +ellps=B that can be explicited as +proj=pipeline +step +inv +proj=longlat +ellps=A +step +proj=geogoffset [+dlon=0 +dlat=0 +dh=0] +step +proj=longlat +ellps=B
generated by cgit v1.2.3 (git 2.25.1) at 2026-02-05 15:59:02 +0000