| Age | Commit message (Collapse) | Author | |
|---|---|---|---|
| 2019-11-21 | Fix typos in code comments | Even Rouault | |
| 2019-11-19 | createOperations(): in some situations, consider when going from A to D ↵ | Even Rouault | |
| intermediates B and C, such there's a A->B operation and C->D operation, and A and C are not exactly the same CRS but use the same geodetic datum | |||
| 2019-11-18 | createFromCRSCodesWithIntermediates(): do not consider intermediate CRS ↵ | Even Rouault | |
| whose datum has a publication date older than the source and target datums | |||
| 2019-11-18 | createGeodeticDatum(): query and set publicationDate | Even Rouault | |
| 2019-11-18 | createOperations(): fix so that GDA94 -> WGS 84 (G1762) still include a ↵ | Even Rouault | |
| result through ITRF2008. Was broken in master by the addition of the 'WGS84 -> WGS 84 (Gxxx)' null operations in the PROJ authority | |||
| 2019-11-18 | proj_trans(): tune selection of operation when there are several ↵ | Even Rouault | |
| alternatives, to select the operation with best accuracy | |||
| 2019-11-18 | createOperations(): small perf improvement. Do not attempt going through an ↵ | Even Rouault | |
| intermediate CRS if we found direct transformation(s) but had to eliminate them due to other criteria | |||
| 2019-11-18 | createOperations(): geocentric to geocentric operation synthetization: ↵ | Even Rouault | |
| distinguish null transform from ballpark transform | |||
| 2019-11-17 | createOperations(): remove the concept of geodetic_datum_preferred_hub | Even Rouault | |
| This was introduced in 63857c92b271bbcd10df0a032304982011acb2a9. Due to the fix done in the previous commit, we can mostly revert the above commit. We just keep the added tests and the custom WGS 84<-->WGS 84 (Gxxxx) null transformations. | |||
| 2019-11-17 | findsOpsInRegistryWithIntermediate(): tune it to be able to research ↵ | Even Rouault | |
| operations that belong to different authorities. Should make the concept of geodetic_datum_preferred_hub introduced some time ago obsolete | |||
| 2019-11-17 | typo fix in comment [ci skip] | Even Rouault | |
| 2019-11-16 | typo fix in comment [ci skip] | Even Rouault | |
| 2019-11-16 | proj_create_crs_to_crs(): fix autoselection logic of operation to compute ↵ | Even Rouault | |
| correctly the geographic coordinates of the input coord when the CRS is not Greenwich based | |||
| 2019-11-14 | import/export PROJJSON: support a interpolation_crs key to geoid_model for ↵ | Even Rouault | |
| faithful serialization of the geoid_geog_crs parameter of proj_create_vertical_crs_ex() | |||
| 2019-11-14 | createOperations(): fix transformation computation from/to a CRS with ↵ | Even Rouault | |
| +geoidgrids and +vunits != m | |||
| 2019-11-14 | Code reformat | Even Rouault | |
| 2019-11-09 | Doc: document oddity related to identification of CRS from ESRI WKT | Even Rouault | |
| Or more generally formulations that don't have an explicit axis order. Refs https://github.com/pyproj4/pyproj/issues/475 projinfo 'GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137.0,298.257223563]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]]' returns EPSG:4326 with 100% confidence. But its axis order is not the same as EPSG:4326. I've pondered about this, like decreasing the confidence of the match, but this would have downstream effects on GDAL (shapefiles with the above content in a .prj would no longer be identified as EPSG:4326). So for now, document that oddity. | |||
| 2019-11-04 | proj_create_vertical_crs(): enhance doc | Even Rouault | |
| 2019-11-04 | Merge remote-tracking branch 'origin/master' into geoid_model | Even Rouault | |
| 2019-11-03 | createOperations(): in some circumstances we wrongly promoted a Helmert ↵ | Even Rouault | |
| geog2D transformation to a geog3D Fixes for example EPSG:4979 to EPSG:2189, as raised in https://github.com/OSGeo/gdal/issues/1972#issuecomment-548814354 | |||
| 2019-11-03 | Import from WKT of VERT_CS: remove outdated EXTENSION.PROJ4_GRIDS for NAVD88 | Even Rouault | |
| 2019-11-03 | Import from WKT: add tweaks for Lidar WKT1 VERT_CS that embeds geoid model ↵ | Even Rouault | |
| in CRS name | |||
| 2019-11-02 | Merge pull request #1709 from rouault/improve_extent_filtering | Even Rouault | |
| Better filtering based on extent and performance improvements | |||
| 2019-11-02 | Add a geoid_model name in database, use GEOIDMODEL for transformations, add ↵ | Even Rouault | |
| a proj_create_vertical_crs_ex() | |||
| 2019-11-02 | WKT and PROJJSON: add import/export of geoid model of VertCRS | Even Rouault | |
| 2019-11-02 | Add tracing framework, and improve createOperations() performance | Even Rouault | |
| 2019-10-31 | Merge pull request #1703 from ↵ | Even Rouault | |
| rouault/improve_transformation_with_alternative_vertical_unit_and_direction Improve transformations with alternative vertical unit and direction | |||
| 2019-10-30 | createOperations(): try to recover extent of CRS from the database when they ↵ | Even Rouault | |
| are missing, especially for compound CRS. Helps having shorter/more relevant results | |||
| 2019-10-30 | createOperations() filtering: code changes regarding extent handling. No ↵ | Even Rouault | |
| functional changes | |||
| 2019-10-30 | createFromWkt(): be tolerant to missing scale_factor parameter (fixes #1700) | Even Rouault | |
| This is invalid WKT, but GDAL 2.4 used to accept it and make a reasonable use of it... Currently we default it to 0 which is non sensical. Better use 1 as GDAL 2.4 did, and emit a warning. Other fix: proj_create_from_wkt() was documented to operate by default in non-strict validation mode, but it was actually in strict mode. So do as documented. | |||
| 2019-10-30 | Rework importing of Vertical unit change from EPSG db, add support for ↵ | Even Rouault | |
| Height Depth Reversal and use it in createOperations() | |||
| 2019-10-29 | Vertical transformations: improve situations similar to transforming from ↵ | Even Rouault | |
| 'NAVD88 (ftUS)' to X, where we now consider the available transformations from 'NAVD88' to X that might exist in the database | |||
| 2019-10-29 | createOperations(): split gigantic method into many smaller ones. No ↵ | Even Rouault | |
| functional change expected | |||
| 2019-10-29 | Little tweaks in implicit 2D/3D geog conversions in compoundCRS to geogCRS ↵ | Even Rouault | |
| transformations | |||
| 2019-10-28 | createOperations(): avoid infinite recursion in a super weird case. Fixes ↵ | Even Rouault | |
| https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18587 | |||
| 2019-10-28 | Reformat | Even Rouault | |
| 2019-10-28 | Various fixes/workarounds to make cppcheck 1.72 (Ubuntu 16.04) and ↵ | Even Rouault | |
| HEAD/1.90dev happy (fixes #1648) | |||
| 2019-10-27 | Database: add an auxiliary concatenated_operation_step table to allow ↵ | Even Rouault | |
| arbitrary number of steps (fixes #1632) EPSG:9103 (NAD27 to ITRF2014 (1)) is now handled. Note:EPSG:9104 (NAD27 to ITRF2014 (2)) is not currently, since it uses for step EPSG:8861 (NAD83(HARN) to NAD83(FBN) (1)) an unsupported transformation method (NADCON5 (3D), EPSG:1075). | |||
| 2019-10-25 | importFromWkt(): fix axis orientation for non-standard ESRI WKT (fixes #1690) | Even Rouault | |
| 2019-10-24 | Generalize generalize_proj_crs_create_bound_vertical_crs_to_WGS84() | Even Rouault | |
| In recent commits, we added a generalize_proj_crs_create_bound_vertical_crs_to_WGS84() function, but there are situations where more accurate results can be obtained, if instead of specifying WGS84 as the hub CRS, the user can specify the exact hub CRS. For example the GEOID2018 grid is against NAD83(2011). So replace this function with proj_crs_create_bound_vertical_crs() | |||
| 2019-10-19 | createFromPROJString(): do not loop forever on malformed string. Fixes ↵ | Even Rouault | |
| https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17923. master only | |||
| 2019-10-18 | Merge pull request #1683 from rouault/fix_double_vertical_unit_conversion | Even Rouault | |
| createOperations(): fix double vertical unit conversion from CompoundCRS to other CRS when the horizontal part of the projected CRS uses non-metre unit | |||
| 2019-10-18 | createOperations(): fix double vertical unit conversion from CompoundCRS to ↵ | Even Rouault | |
| other CRS when the horizontal part of the projected CRS uses non-metre unit Fix issue reported on https://lists.osgeo.org/pipermail/proj/2019-October/008939.html | |||
| 2019-10-18 | Fix two sentences that seem to be copy-and-paste forgotten. | Martin Desruisseaux | |
| 2019-10-13 | Remove the sentence in documentation saying that CRS::coordinateSystem() may ↵ | Martin Desruisseaux | |
| return null. It is true for datum(), but does not apply to coordinateSystem(). | |||
| 2019-10-12 | Merge pull request #1665 from ↵ | Kristian Evers | |
| rouault/fix_custom_compound_crs_with_NAD83_2011_and_geoidgrid_to_WGS84_G1762 proj_create_crs_to_crs(): remove elimination of Ballpark operations that caused transformation failures in some cases | |||
| 2019-10-12 | createOperations(): allow transforming from a compoundCRS of a bound ↵ | Even Rouault | |
| verticalCRS to a 2D CRS | |||
| 2019-10-04 | Add a proj_crs_demote_to_2D(). Useful if forced to export a 3D CRS to a best ↵ | Even Rouault | |
| approximate as WKT1 that doesn't support it | |||
| 2019-10-04 | proj_normalize_for_visualization(): make it work with CRS objects | Even Rouault | |
| 2019-10-03 | DerivedGeographicCRS: allow exporting +proj=ob_tran +o_proj=longlat to PROJ ↵ | Even Rouault | |
| string | |||
