| Age | Commit message (Collapse) | Author |
|
renaming to sqlite3_utils.hpp/cpp
|
|
https://github.com/OSGeo/PROJ/pull/1839#pullrequestreview-345535380
|
|
|
|
|
|
(fixes #866)
|
|
|
|
(fixes #209)
|
|
|
|
WKT1_GDAL export: limit datum name massaging to names matching EPSG (fixes #1835)
|
|
createOperations(): fix dealing with projected 3D CRS whose Z units != metre
|
|
#1835)
|
|
The exception only affects C++ users. It was caught by the C layer.
|
|
|
|
|
|
|
|
Improvements regarding name aliases (refs #1823)
|
|
|
|
|
|
|
|
opened
|
|
|
|
#1823)
|
|
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.
|
|
|
|
fix exporting CoordinateSystem to PROJ JSON with ID
|
|
|
|
|
|
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>
```
|
|
|
|
|
|
PROJ_NETWORK_ENDPOINT or proj_context_set_url_endpoint()
|
|
and networking enabled
|
|
As on import of EPSG, we remove the supersession of Canadian NTv1 file w.r.t NTv2
(because the default behaviour of PROJ is to ignore superseded operations). However
the NTv1 operation is advertized with an accuracy of 1m, whereas NTv2 is advertized
with 1.5m. Consequently on areas where both files are valid, and if both files are
available, NTv1 would be selected. So as a workaround, worsen the NTv1 accuracy to
2m so that NTv2 is used in priority.
|
|
fails.
Relates to https://github.com/OSGeo/PROJ/issues/1808
|
|
proj_context_set_enable_network(ctx, true)
|
|
<--> vertical transformations
|
|
get_header_value(), and test
|
|
|
|
mapping between CGQ77-98.gsb and CQ77SCRS.GSB
|
|
filename substitution
|
|
|
|
|
|
rouault/improve_identification_with_datum_name_aliases
identify(): take into datum name aliases (fixes #1800)
|
|
BoundCRS::identify(): improvements to discard CRS that aren't relevant (fixes #1801)
|
|
|
|
Make EPSG:102100 resolve to ESRI:102100 (fixes #1730)
|
|
(fixes #1801)
Fix for
```
projinfo --identify "+proj=utm +zone=48 +a=6377276.345 +b=6356075.41314024 +towgs84=198,881,317,0,0,0,0 +units=m +no_defs +type=crs"
```
to only return BoundCRS of EPSG:3148: 70 %
Previously it also returned EPSG:23948 and EPSG:24048 whose projected CRS-only
parts where likely matches, but those 2 CRSs don't have a +towgs84=198,881,317,0,0,0,0,
so discard them.
|
|
rouault/restore_ob_tran_to_meter_compat_with_pj_transform
ob_tran: restore traditional handling of +to_meter with pj_transform() and proj utility (fixes #1782)
|
|
switching between (sub)grids (fixes #1663)
Given in.txt with
53.999759140 5.144478208 252.6995
Before the fix,
cct -t 0 -d 4 +proj=pipeline +step +proj=axisswap +order=2,1,3,4 +step +proj=hgridshift +inv +grids=rdtrans2018.gsb +step +proj=vgridshift +grids=naptrans2018.gtx +step +proj=sterea +lat_0=52.156160556 +lon_0=5.387638889 +k=0.9999079 +x_0=155000 +y_0=463000 +ellps=bessel in.txt
returned:
139079.8814 668306.0302 212.1724 0.0000
It now returns:
139079.8850 668306.0458 212.1724 0.0000
which meets with the 1mm accuracy the expected result of test point
```
30010049 53.999759140 5.144478208 252.6995 139079.8850 668306.0460 212.1723
```
|
|
|