aboutsummaryrefslogtreecommitdiff
path: root/test/gie
AgeCommit message (Collapse)Author
2020-01-20Address @hobu 's review comment of ↵Even Rouault
https://github.com/OSGeo/PROJ/pull/1839#pullrequestreview-345535380
2020-01-17Merge branch 'master' into rfc4_merge_back_masterEven Rouault
2020-01-14Add test/unit/test_grids.cpp to improve testing coverageEven Rouault
2020-01-08Add capability to read resource files from the user writable directoryEven Rouault
2020-01-07geotiff_grids.gie: add commentEven Rouault
2020-01-05Make sure tests pass if extra grids are presentEven Rouault
Should fix the issue reported in https://lists.osgeo.org/pipermail/proj/2020-January/009188.html Some extra north-american grids present in data/ can affect the results of some tests, so create a data/for_tests/ subdirectory in which we copy only select grids.
2019-12-30deformation: add support for +grids= for GeoTIFF gridsEven Rouault
This option is to load grid(s) that have both the horizontal and vertical velocities in the same file. Can be tested with the following grid https://github.com/rouault/sample_proj_gtiff_grids/blob/master/nkgrf03vel_realigned.tif converted from the original .ct2 and .gtx with ``` gdal_translate nkgrf03vel_realigned.vrt nkgrf03vel_realigned.tif -co COMPRESS=DEFLATE -co PREDICTOR=3 -co BLOCKYSIZE=241 -co INTERLEAVE=BAND ``` where nkgrf03vel_realigned.vrt is ``` <VRTDataset rasterXSize="223" rasterYSize="241"> <SRS dataAxisToSRSAxisMapping="2,1">GEOGCRS["Unknown based on GRS80", DATUM["Unknown based on GRS80", ELLIPSOID["GRS 1980",6378137,298.257222101, LENGTHUNIT["metre",1]]], PRIMEM["Greenwich",0, ANGLEUNIT["degree",0.0174532925199433]], CS[ellipsoidal,2], AXIS["geodetic latitude (Lat)",north, ORDER[1], ANGLEUNIT["degree",0.0174532925199433]], AXIS["geodetic longitude (Lon)",east, ORDER[2], ANGLEUNIT["degree",0.0174532925199433]]] </SRS> <GeoTransform> 2.9166666666666670e+00, 1.6666666666666666e-01, 0.0000000000000000e+00, 7.3041666666666686e+01, 0.0000000000000000e+00, -8.3333333333333329e-02</GeoTransform> <Metadata> <MDI key="DESCRIPTION"></MDI> <MDI key="area_of_use">Nordic and Baltic countries</MDI> <MDI key="AREA_OR_POINT">Point</MDI> <MDI key="TIFFTAG_COPYRIGHT">The Nordic Geodetic Commission. Creative Commons Attribution 4.0 https://creativecommons.org/licenses/by/4.0/</MDI> <MDI key="TIFFTAG_DATETIME">2019:12:30 00:00:00</MDI> <MDI key="TIFFTAG_IMAGEDESCRIPTION">Deformation model covering the Nordic and Baltic countries. Used in transformations between global reference frames and the local realisations of ETRS89 in the Nordic and Baltic countries</MDI> <MDI key="TYPE">VELOCITY</MDI> </Metadata> <VRTRasterBand dataType="Float32" band="1"> <Description>east_velocity</Description> <UnitType>mm/year</UnitType> <SimpleSource> <SourceFilename relativeToVRT="0">/home/even/proj/proj-datumgrid/europe/nkgrf03vel_realigned_xy.ct2</SourceFilename> <SourceBand>2</SourceBand> <!-- GDAL exposes the first physical component of the file (longitude offset normally, here east velocity) as the second band --> <SrcRect xOff="0" yOff="0" xSize="223" ySize="241" /> <DstRect xOff="0" yOff="0" xSize="223" ySize="241" /> </SimpleSource> </VRTRasterBand> <VRTRasterBand dataType="Float32" band="2"> <Description>north_velocity</Description> <UnitType>mm/year</UnitType> <SimpleSource> <SourceFilename relativeToVRT="0">/home/even/proj/proj-datumgrid/europe/nkgrf03vel_realigned_xy.ct2</SourceFilename> <SourceBand>1</SourceBand> <!-- and the second physical component (latitude offset normally, here north velocity) as the first band --> <SrcRect xOff="0" yOff="0" xSize="223" ySize="241" /> <DstRect xOff="0" yOff="0" xSize="223" ySize="241" /> </SimpleSource> </VRTRasterBand> <VRTRasterBand dataType="Float32" band="3"> <Description>up_velocity</Description> <UnitType>mm/year</UnitType> <SimpleSource> <SourceFilename relativeToVRT="0">/home/even/proj/proj-datumgrid/europe/nkgrf03vel_realigned_z.gtx</SourceFilename> <SourceBand>1</SourceBand> <SrcRect xOff="0" yOff="0" xSize="223" ySize="241" /> <DstRect xOff="0" yOff="0" xSize="223" ySize="241" /> </SimpleSource> </VRTRasterBand> </VRTDataset> ```
2019-12-11test/gie/geotiff_grids.gie: use of subset of gr3df97a.tif for systematic testingEven Rouault
2019-12-11Add a +proj=xyzgridshift method to perform geocentric translation by grid. ↵Even Rouault
Used for French NTF to RGF93 transformation using gr3df97a.tif grid
2019-12-10Add support for horizontal and vertical grids in GeoTIFFEven Rouault
2019-12-06vertical grid shift: rework to no longer load whole grid into memoryEven Rouault
2019-11-25Pipeline: support +omit_fwd and +omit_inv keywordsEven Rouault
Inspired from syntax of https://github.com/OSGeo/PROJ/pull/453/files but 'rebased' on top of previous commit that cleans up the pipeline implementation Different situations: - +omit_fwd: the step when followed in the forward path will be omitted the step when followed in the reverse path will be executed - +omit_fwd +inv: the step when followed in the forward path will be omitted the step when followed in the reverse path will be executed (with the inv method) - +omit_inv: the step when followed in the forward path will be executed the step when followed in the reverse path will be omitted - +omit_inv +inv: the step when followed in the forward path will be executed (with the inv method) the step when followed in the reverse path will be omitted This will be used in the next commit to optimize constructs like +step +proj=hgridshift +grids=foo +step +proj=vgridshift +grids=bar +step +inv +proj=hgridshift +grids=foo Such steps are used for CRS to CRS transformations where applying the vertical grid requires to do a transformation to an interpolating CRS. One can notice that in the last step will just restore the horizontal coordinates before the first step, so doing an inverse hgridshift is overkill. So that could be optimized as: +step +proj=push +v_1 +v_2 +step +proj=hgridshift +grids=foo +omit_inv +step +proj=vgridshift +grids=bar +step +inv +proj=hgridshift +grids=foo +omit_fwd +step +proj=pop +v_1 +v_2 In the forward path, this will be equivalent to: +step +proj=push +v_1 +v_2 +step +proj=hgridshift +grids=foo +step +proj=vgridshift +grids=bar +step +prop=pop +v_1 +v_2 And similarly in the reverse path, this will be quivalent to: +step +proj=push +v_1 +v_2 +step +proj=hgridshift +grids=foo +step +inv +proj=vgridshift +grids=bar +step +proj=pop +v_1 +v_2
2019-10-22Fix test tolerance to run on powerpc architectureEven Rouault
2019-10-03aeqd: for spherical forward path, go to higher precision ellipsoidal case ↵Even Rouault
when the point coordinates are super close to the origin (fixes #1654)
2019-10-01Add rotation support to the HEALPix projection (#1638)Simon Schneegans
2019-09-28test/gie/builtins.gie: remove unused parametersEven Rouault
2019-09-17ell_set.cpp: avoid division by zero in R_lat_a case. Fixes ↵Even Rouault
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=16130
2019-09-17eqdc: avoid potential division by zero. Fixes ↵Even Rouault
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17190
2019-09-10Fix gie test after applying fix to bertin1953Kristian Evers
2019-06-21Use HTTPS URLs for download.osgeo.orgPaul Menzel
Change all occurrences with the command below. git grep -l http://download.osgeo.org/ | xargs sed -i 's,http://download.osgeo.org/,https://download.osgeo.org/,g' Fixes: https://github.com/OSGeo/PROJ/issues/1521
2019-05-05geos: avoid division by zeroEven Rouault
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14602 Credit to OSS Fuzz
2019-05-02lagrng: avoid division by zero when latitude is very close to 90Even Rouault
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14477 Credit to OSS Fuzz
2019-04-25gs50 and other mod_ster projections: avoid divison by zeroEven Rouault
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14421 Credit to OSS Fuzz
2019-04-22airy: avoid division by zeroEven Rouault
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14410 Credit to OSS Fuzz
2019-04-20omerc: validate lat_1 and lat_2 to avoid divison by zeroEven Rouault
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14384 Credit to OSS Fuzz
2019-04-19Inverse cart: better deal with x,y,z equal of very close to zeroEven Rouault
In that case, for a non-spherical ellipsoid, a phi = 180deg was returned, which caused a division by zero in the foward path of moll.cpp Fixup the latitude to be 0 when that happens. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14348 Credit to OSS Fuzz
2019-04-18tpers: avoid division by zeroEven Rouault
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14342 Credit to OSS Fuzz
2019-04-18isea: avoid invalid integer shiftEven Rouault
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14286 Credit to OSS Fuzz
2019-04-18Merge pull request #1429 from rouault/vgridshift_full_worldEven Rouault
vgridshift: handle longitude wrap-around for grids with 360deg longitude extent
2019-04-16vgridshift: handle longitude wrap-around for grids with 360deg longitude extentEven Rouault
Like egm96_15.gtx Fixes #1415 Technically, a similar fix could be done for horizontal grids, but world extent is less common for them.
2019-04-16omerc: avoid division by zeroEven Rouault
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14279 Credit to OSS Fuzz
2019-04-14lcc: avoid division by zeroEven Rouault
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14250 Credit to OSS Fuzz
2019-04-12Validate lat_0 range in general case, lat_1 and lat_2 for lcc and eqdcEven Rouault
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14211 Credit to OSS Fuzz
2019-04-11omerc: avoid division by zeroEven Rouault
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14138 Credit to OSS Fuzz
2019-04-11omerc: avoid division by zero when |lat_0|=90Even Rouault
Partially revert e3346bb39c860883ed9a8ada0657139118e21ef0 (#195) Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14136 Credit to OSS Fuzz
2019-04-10lsat: avoid division by zero in inverseEven Rouault
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14135 Credit to OSS Fuzz
2019-04-05imw_p: avoid division by zero in inverseEven Rouault
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14062 Credit to OSS Fuzz
2019-04-05krovak: avoid division by zeroEven Rouault
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14061 Credit to OSS Fuzz
2019-04-05lcc: avoid division by zeroEven Rouault
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14058 Credit to OSS Fuzz
2019-04-04Reject negative e parameter to avoid division by zeroEven Rouault
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14044 Credit to OSS Fuzz
2019-04-03Merge pull request #1408 from rouault/ossfuzz_14015Kristian Evers
Fixes Ossfuzz 14015 and gie bug
2019-04-02gie: fix tolerance checkingEven Rouault
When comparing expected result with got result, in the case the distance computation returns NaN, gie incorrectly considered the test to be OK. Adapt / comment out a few broken tests revealed after that fix.
2019-04-02Krovak: avoid divison by zeroEven Rouault
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14015 Credit to OSS Fuzz
2019-04-02Make sure that ISO19111 C++ code sets pj_errno on errorsKristian Evers
2019-04-02Merge pull request #1401 from rouault/ossfuzz_14003_14010Even Rouault
Ossfuzz 14003 14010
2019-04-02Merge pull request #1391 from kbevers/noopKristian Evers
Add no-op operation. It does nothing.
2019-04-01bonne: avoid division by zeroEven Rouault
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14010 Credit to OSS Fuzz
2019-04-01pj_gauss_ini(): fix division by zeroEven Rouault
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14003 Credit to OSS Fuzz
2019-03-29tpeqd: avoid division by zeroEven Rouault
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13948 Credit to OSS Fuzz
2019-03-29unitconvert: prevent division by zeroEven Rouault
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13947 Credit to OSS Fuzz
generated by cgit v1.2.3 (git 2.25.1) at 2026-02-23 19:29:52 +0000