PROJ - Forked from https://github.com/OSGeo/PROJ

Age	Commit message (Collapse)	Author
2022-01-04	Fix doc generation with Doxygen 1.9.3	Even Rouault
	Since the update to Doxygen 1.9.3, doc generation was broken. With bisection of doxygen, it was found this was due to commit https://github.com/doxygen/doxygen/commit/ee8f3fb7a2ed74ee30ae3202707617e97f6641ff which makes Doxygen honour nested @cond . This revealed bad pairing of @cond / @endcond in our code, fixed by this commit.
2021-10-17	exportToPROJStringGeneric(): avoid harmless floating-point division by zero ↵	Even Rouault
	if conversion factor is 0. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=40050
2021-04-23	Database: update to EPSG v10.019	Even Rouault
	Non-trivial updates: - some vertical CRS are now encoded as DerivedVerticalCRS. e.g EPSG:8228 "NAVD88 height (ft)", with base EPSG:5703 "NAVD88 height". As we don't have support in our PROJ db model for DerivedVerticalCRS, modify the import script to 'resolve' the derivation up to the original datum. - Method EPSG:1069 'Change of Vertical Unit' is no longer used. It is replaced by a generic-purpose EPSG:1104 method that doesn't take any conversion factor. And generic conversions EPSG:7812 and EPSG:7813 are now used in concatenated operations, which require code changes as well.
2021-03-03	Reformat code with clang-format-10 from ubuntu 20.04	Even Rouault

2021-02-10	Allow a BoundCRS to use a PROJ string transformation	Even Rouault
	Related to https://lists.osgeo.org/pipermail/proj/2021-February/010040.html Given test.wkt with ``` BOUNDCRS[ SOURCECRS[ GEOGCRS["unknown", DATUM["Unknown based on GRS80 ellipsoid", ELLIPSOID["GRS 1980",6378137,298.257222101, LENGTHUNIT["metre",1], ID["EPSG",7019]]], PRIMEM["Greenwich",0, ANGLEUNIT["degree",0.0174532925199433], ID["EPSG",8901]], CS[ellipsoidal,2], AXIS["longitude",east, ORDER[1], ANGLEUNIT["degree",0.0174532925199433, ID["EPSG",9122]]], AXIS["latitude",north, ORDER[2], ANGLEUNIT["degree",0.0174532925199433, ID["EPSG",9122]]]]], TARGETCRS[ GEOGCRS["WGS 84", DATUM["World Geodetic System 1984", ELLIPSOID["WGS 84",6378137,298.257223563, LENGTHUNIT["metre",1]]], PRIMEM["Greenwich",0, ANGLEUNIT["degree",0.0174532925199433]], CS[ellipsoidal,2], AXIS["latitude",north, ORDER[1], ANGLEUNIT["degree",0.0174532925199433]], AXIS["longitude",east, ORDER[2], ANGLEUNIT["degree",0.0174532925199433]], ID["EPSG",4326]]], ABRIDGEDTRANSFORMATION["Transformation from unknown to WGS84", METHOD["PROJ-based operation method: +proj=pipeline +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +proj=axisswap +order=2,1 +step +proj=cart +ellps=GRS80 +step +proj=helmert +convention=coordinate_frame +exact +step +inv +proj=cart +ellps=WGS84 +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=rad +xy_out=deg"]]] ``` ``projinfo -s @test.wkt -t "WGS 84" -o PROJ -q`` outputs: ``` +proj=pipeline +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +proj=axisswap +order=2,1 +step +proj=cart +ellps=GRS80 +step +proj=helmert +convention=coordinate_frame +exact +step +inv +proj=cart +ellps=WGS84 +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=rad +xy_out=deg ```
2020-12-12	Split coordinateoperation.cpp in many files in iso19111/operation directory	Even Rouault
	The big size of coordinateoperation.cpp could require significant amount of RAM to build it with -O2 level, and cause compiler crashes in some environments.