Repository navigation
chore(deps): bump proj4rs from 0.2.1 to 0.3.0 - #1199
Merged
Merged
Conversation
Bumps [proj4rs](https://github.com/3liz/proj4rs) from 0.2.1 to 0.3.0. - [Commits](https://github.com/3liz/proj4rs/commits) --- updated-dependencies: - dependency-name: proj4rs dependency-version: 0.3.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
Contributor
|
Important Review skippedBot user detected. To trigger a single review, invoke the
 |
Member
|
The Pushing a commit that:
|
…read back The bump to 0.3.0 makes the oblique Mercator, Cassini-Soldner, the polyconic and Equal Earth parse, so the EPSG codes using them (Oman's grid, Malaysia's RSO, Tobago's and Berlin's, Brazil's polyconic, Equal Earth) are written as WKT and read back by their parameters, checked against PROJ 9.9. An oblique Mercator at azimuth 90° stays refused (proj4rs' omerc is degenerate there; the Swiss case keeps somerc). The map and engine tests that refused +proj=poly pin the still-unimplemented Laborde instead, the EPSG:2056 row of the WKT2 corpus takes the ground truth of PROJ's own pipeline, and the user guide's list of refused methods names Laborde now. (#1199)
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Contributor
Code reviewReviewed PR #1199 (Dependabot bump of proj4rs 0.2.1 → 0.3.0). The diff goes well beyond a version bump. It also adds Hotine oblique Mercator, Cassini-Soldner, polyconic and Equal Earth support, changes reference data, and updates tests and docs. I could not build or run tests here, so nothing below is verified by execution. Bugs
Security
Performance
Quality
AGENTS.md
Change sizeCompared with the base branch (merge base 6692b1b to PR head 2813f33). Sizes are file sizes, not line counts.
|
Contributor
📖 Docs preview
GitHub Pages takes a minute or two to publish a new commit. |
An azimuth of 270° is the same east-west centre line as 90°, and the omerc formula is degenerate there in proj4rs and PROJ alike (verified: PROJ 9.9's own `omerc +no_uoff +alpha=90` lands 10 Mm off), so the guard matches modulo 180°. Cassini and the polyconic take no scale factor, so the reader stops emitting `+k_0`. The ESRI table's notes say they were checked against proj4rs 0.2, and the user guide lists the methods that read from parameters now.
| assert!(e.contains("labrd"), "{e}"); | ||
| // proj4rs 0.3 added Cassini, the polyconic, Equal Earth and the oblique Mercator: their | ||
| // codes are accepted (EPSG:5880's polyconic, whose refusal was #208), and draw where PROJ | ||
| // does: (5 000 000, 8 894 145) for 10°W 54°S of SIRGAS 2000's origin, its false northing |
Contributor
There was a problem hiding this comment.
Nit: the comment has the axes swapped. Coord::new(-54.0, -10.0) on the next line is 54°W, 10°S, not "10°W 54°S". The expected 8_894_145.167 also has no stated provenance. The repo's convention is pyproj-derived expected values, so please name the source (for example "pyproj 3.7.x, EPSG:5880") next to the constant.
Member
There was a problem hiding this comment.
Fixed (a7e971d), with the provenance named: pyproj 3.8.0's EPSG:5880.
Contributor
Code reviewBugs
Security
Performance
Quality
AGENTS.md
Not verified: I could not run Change sizeCompared with
|
…asked for The oblique Mercator, Equal Earth, Cassini and polyconic round trips couldn't catch a wrong formula, both sides being the same code: each now has a point checked against pyproj 3.8.0 (EPSG:4326 to the code). The corpus header says the Swiss row's x,y is pyproj's own EPSG:2056 pipeline of its round point, and lists CH1903+ among the systems whose longitude and latitude are WGS 84. The ESRI WKT1 name for the Hotine variant A is real input (ArcGIS writes Hotine_Oblique_Mercator_Azimuth_Natural_Origin, pyproj's EPSG:3078 included), so the reader arm stays, said so; the Swiss guard gets a note on why it checks the azimuth exactly, and the polyconic test says 54°W 10°S, not 10°W 54°S.
| available. Swiss oblique Mercator and the standard Krovak East/North variant are supported from | ||
| their parameters. | ||
| available. Swiss oblique Mercator, the standard Krovak East/North variant, and the oblique | ||
| Mercator, Cassini-Soldner, polyconic and Equal Earth methods are supported from their |
Contributor
There was a problem hiding this comment.
Nit (docs overstate support): the code refuses the two-point Hotine form (no AZIMUTH, see wkt.rs around line 685), so "the oblique Mercator" needs qualifying. Confidence: high.
Suggested change
| Mercator, Cassini-Soldner, polyconic and Equal Earth methods are supported from their | |
| Mercator (its azimuth form), Cassini-Soldner, polyconic and Equal Earth methods are supported from their |
| EPSG:4087 0.0 0.0 0.0 0.0 PROJCRS["WGS 84 / World Equidistant Cylindrical",BASEGEOGCRS["WGS 84",ENSEMBLE["World Geodetic System 1984 ensemble",MEMBER["World Geodetic System 1984 (Transit)"],MEMBER["World Geodetic System 1984 (G730)"],MEMBER["World Geodetic System 1984 (G873)"],MEMBER["World Geodetic System 1984 (G1150)"],MEMBER["World Geodetic System 1984 (G1674)"],MEMBER["World Geodetic System 1984 (G1762)"],MEMBER["World Geodetic System 1984 (G2139)"],MEMBER["World Geodetic System 1984 (G2296)"],ELLIPSOID["WGS 84",6378137,298.257223563,LENGTHUNIT["metre",1]],ENSEMBLEACCURACY[2.0]],PRIMEM["Greenwich",0,ANGLEUNIT["degree",0.0174532925199433]],ID["EPSG",4326]],CONVERSION["World Equidistant Cylindrical",METHOD["Equidistant Cylindrical",ID["EPSG",1028]],PARAMETER["Latitude of 1st standard parallel",0,ANGLEUNIT["degree",0.0174532925199433],ID["EPSG",8823]],PARAMETER["Longitude of natural origin",0,ANGLEUNIT["degree",0.0174532925199433],ID["EPSG",8802]],PARAMETER["False easting",0,LENGTHUNIT["metre",1],ID["EPSG",8806]],PARAMETER["False northing",0,LENGTHUNIT["metre",1],ID["EPSG",8807]]],CS[Cartesian,2],AXIS["easting (X)",east,ORDER[1],LENGTHUNIT["metre",1,ID["EPSG",9001]]],AXIS["northing (Y)",north,ORDER[2],LENGTHUNIT["metre",1,ID["EPSG",9001]]]] | ||
| EPSG:27572 549771.5393519275 2192985.1139478907 1.6800000000000002 46.735 PROJCRS["NTF (Paris) / Lambert zone II",BASEGEOGCRS["NTF (Paris)",DATUM["Nouvelle Triangulation Francaise (Paris)",ELLIPSOID["Clarke 1880 (IGN)",6378249.2,293.466021293627,LENGTHUNIT["metre",1]]],PRIMEM["Paris",2.5969213,ANGLEUNIT["grad",0.0157079632679489]],ID["EPSG",4807]],CONVERSION["Lambert zone II",METHOD["Lambert Conic Conformal (1SP)",ID["EPSG",9801]],PARAMETER["Latitude of natural origin",52,ANGLEUNIT["grad",0.0157079632679489],ID["EPSG",8801]],PARAMETER["Longitude of natural origin",0,ANGLEUNIT["grad",0.0157079632679489],ID["EPSG",8802]],PARAMETER["Scale factor at natural origin",0.99987742,SCALEUNIT["unity",1],ID["EPSG",8805]],PARAMETER["False easting",600000,LENGTHUNIT["metre",1],ID["EPSG",8806]],PARAMETER["False northing",2200000,LENGTHUNIT["metre",1],ID["EPSG",8807]]],CS[Cartesian,2],AXIS["easting (X)",east,ORDER[1],LENGTHUNIT["metre",1,ID["EPSG",9001]]],AXIS["northing (Y)",north,ORDER[2],LENGTHUNIT["metre",1,ID["EPSG",9001]]]] | ||
| EPSG:2056 2659938.9861671347 1184470.9666418221 8.225 46.81 PROJCRS["CH1903+ / LV95",BASEGEOGCRS["CH1903+",DATUM["CH1903+",ELLIPSOID["Bessel 1841",6377397.155,299.1528128,LENGTHUNIT["metre",1]]],PRIMEM["Greenwich",0,ANGLEUNIT["degree",0.0174532925199433]],ID["EPSG",4150]],CONVERSION["Swiss Oblique Mercator 1995",METHOD["Hotine Oblique Mercator (variant B)",ID["EPSG",9815]],PARAMETER["Latitude of projection centre",46.9524055555556,ANGLEUNIT["degree",0.0174532925199433],ID["EPSG",8811]],PARAMETER["Longitude of projection centre",7.43958333333333,ANGLEUNIT["degree",0.0174532925199433],ID["EPSG",8812]],PARAMETER["Azimuth at projection centre",90,ANGLEUNIT["degree",0.0174532925199433],ID["EPSG",8813]],PARAMETER["Angle from Rectified to Skew Grid",90,ANGLEUNIT["degree",0.0174532925199433],ID["EPSG",8814]],PARAMETER["Scale factor at projection centre",1,SCALEUNIT["unity",1],ID["EPSG",8815]],PARAMETER["Easting at projection centre",2600000,LENGTHUNIT["metre",1],ID["EPSG",8816]],PARAMETER["Northing at projection centre",1200000,LENGTHUNIT["metre",1],ID["EPSG",8817]]],CS[Cartesian,2],AXIS["(E)",east,ORDER[1],LENGTHUNIT["metre",1,ID["EPSG",9001]]],AXIS["(N)",north,ORDER[2],LENGTHUNIT["metre",1,ID["EPSG",9001]]]] | ||
| EPSG:2056 2660019.111857919 1184616.167839863 8.225 46.81 PROJCRS["CH1903+ / LV95",BASEGEOGCRS["CH1903+",DATUM["CH1903+",ELLIPSOID["Bessel 1841",6377397.155,299.1528128,LENGTHUNIT["metre",1]]],PRIMEM["Greenwich",0,ANGLEUNIT["degree",0.0174532925199433]],ID["EPSG",4150]],CONVERSION["Swiss Oblique Mercator 1995",METHOD["Hotine Oblique Mercator (variant B)",ID["EPSG",9815]],PARAMETER["Latitude of projection centre",46.9524055555556,ANGLEUNIT["degree",0.0174532925199433],ID["EPSG",8811]],PARAMETER["Longitude of projection centre",7.43958333333333,ANGLEUNIT["degree",0.0174532925199433],ID["EPSG",8812]],PARAMETER["Azimuth at projection centre",90,ANGLEUNIT["degree",0.0174532925199433],ID["EPSG",8813]],PARAMETER["Angle from Rectified to Skew Grid",90,ANGLEUNIT["degree",0.0174532925199433],ID["EPSG",8814]],PARAMETER["Scale factor at projection centre",1,SCALEUNIT["unity",1],ID["EPSG",8815]],PARAMETER["Easting at projection centre",2600000,LENGTHUNIT["metre",1],ID["EPSG",8816]],PARAMETER["Northing at projection centre",1200000,LENGTHUNIT["metre",1],ID["EPSG",8817]]],CS[Cartesian,2],AXIS["(E)",east,ORDER[1],LENGTHUNIT["metre",1,ID["EPSG",9001]]],AXIS["(N)",north,ORDER[2],LENGTHUNIT["metre",1,ID["EPSG",9001]]]] |
Contributor
There was a problem hiding this comment.
Fixture changed to fit the new output, not checked against PyProj (medium confidence). The EPSG:2056 row's x,y moved by about 80 m (2659938.98 to 2660019.11) and its lon/lat columns now mean WGS 84 instead of CH1903+. The header explains the change, but the five new codes in checked are the only pyproj-verified values in the PR, and this row isn't one of them. Please add it to the checked table, computed by pyproj from the WGS 84 round point, so the test doesn't just echo RustGIS's output.
Contributor
Code reviewThis PR is titled and described as a Dependabot bump of proj4rs 0.2.1 to 0.3.0, but the diff also adds new projection support (Hotine oblique Mercator by azimuth, Cassini-Soldner, polyconic, Equal Earth), changes which EPSG codes are refused, rewrites a fixture row and edits docs. None of that is in the title or body. Bugs
Security
Performance
Quality
AGENTS.md
Change sizeCompared: the whole PR against main (merge base 6692b1b to PR head a7e971d).
|
pyproj's EPSG:4326 to the EPSG code applies the datum registry's own transformation, which for SAD69 (EPSG:29100) differs from the definition's bundled three-parameter shift by some 46 m. Against the definition itself, pyproj and proj4rs agree bit for bit, and the comparison keeps the bundled shift the reader emits.
| EPSG:4087 0.0 0.0 0.0 0.0 PROJCRS["WGS 84 / World Equidistant Cylindrical",BASEGEOGCRS["WGS 84",ENSEMBLE["World Geodetic System 1984 ensemble",MEMBER["World Geodetic System 1984 (Transit)"],MEMBER["World Geodetic System 1984 (G730)"],MEMBER["World Geodetic System 1984 (G873)"],MEMBER["World Geodetic System 1984 (G1150)"],MEMBER["World Geodetic System 1984 (G1674)"],MEMBER["World Geodetic System 1984 (G1762)"],MEMBER["World Geodetic System 1984 (G2139)"],MEMBER["World Geodetic System 1984 (G2296)"],ELLIPSOID["WGS 84",6378137,298.257223563,LENGTHUNIT["metre",1]],ENSEMBLEACCURACY[2.0]],PRIMEM["Greenwich",0,ANGLEUNIT["degree",0.0174532925199433]],ID["EPSG",4326]],CONVERSION["World Equidistant Cylindrical",METHOD["Equidistant Cylindrical",ID["EPSG",1028]],PARAMETER["Latitude of 1st standard parallel",0,ANGLEUNIT["degree",0.0174532925199433],ID["EPSG",8823]],PARAMETER["Longitude of natural origin",0,ANGLEUNIT["degree",0.0174532925199433],ID["EPSG",8802]],PARAMETER["False easting",0,LENGTHUNIT["metre",1],ID["EPSG",8806]],PARAMETER["False northing",0,LENGTHUNIT["metre",1],ID["EPSG",8807]]],CS[Cartesian,2],AXIS["easting (X)",east,ORDER[1],LENGTHUNIT["metre",1,ID["EPSG",9001]]],AXIS["northing (Y)",north,ORDER[2],LENGTHUNIT["metre",1,ID["EPSG",9001]]]] | ||
| EPSG:27572 549771.5393519275 2192985.1139478907 1.6800000000000002 46.735 PROJCRS["NTF (Paris) / Lambert zone II",BASEGEOGCRS["NTF (Paris)",DATUM["Nouvelle Triangulation Francaise (Paris)",ELLIPSOID["Clarke 1880 (IGN)",6378249.2,293.466021293627,LENGTHUNIT["metre",1]]],PRIMEM["Paris",2.5969213,ANGLEUNIT["grad",0.0157079632679489]],ID["EPSG",4807]],CONVERSION["Lambert zone II",METHOD["Lambert Conic Conformal (1SP)",ID["EPSG",9801]],PARAMETER["Latitude of natural origin",52,ANGLEUNIT["grad",0.0157079632679489],ID["EPSG",8801]],PARAMETER["Longitude of natural origin",0,ANGLEUNIT["grad",0.0157079632679489],ID["EPSG",8802]],PARAMETER["Scale factor at natural origin",0.99987742,SCALEUNIT["unity",1],ID["EPSG",8805]],PARAMETER["False easting",600000,LENGTHUNIT["metre",1],ID["EPSG",8806]],PARAMETER["False northing",2200000,LENGTHUNIT["metre",1],ID["EPSG",8807]]],CS[Cartesian,2],AXIS["easting (X)",east,ORDER[1],LENGTHUNIT["metre",1,ID["EPSG",9001]]],AXIS["northing (Y)",north,ORDER[2],LENGTHUNIT["metre",1,ID["EPSG",9001]]]] | ||
| EPSG:2056 2659938.9861671347 1184470.9666418221 8.225 46.81 PROJCRS["CH1903+ / LV95",BASEGEOGCRS["CH1903+",DATUM["CH1903+",ELLIPSOID["Bessel 1841",6377397.155,299.1528128,LENGTHUNIT["metre",1]]],PRIMEM["Greenwich",0,ANGLEUNIT["degree",0.0174532925199433]],ID["EPSG",4150]],CONVERSION["Swiss Oblique Mercator 1995",METHOD["Hotine Oblique Mercator (variant B)",ID["EPSG",9815]],PARAMETER["Latitude of projection centre",46.9524055555556,ANGLEUNIT["degree",0.0174532925199433],ID["EPSG",8811]],PARAMETER["Longitude of projection centre",7.43958333333333,ANGLEUNIT["degree",0.0174532925199433],ID["EPSG",8812]],PARAMETER["Azimuth at projection centre",90,ANGLEUNIT["degree",0.0174532925199433],ID["EPSG",8813]],PARAMETER["Angle from Rectified to Skew Grid",90,ANGLEUNIT["degree",0.0174532925199433],ID["EPSG",8814]],PARAMETER["Scale factor at projection centre",1,SCALEUNIT["unity",1],ID["EPSG",8815]],PARAMETER["Easting at projection centre",2600000,LENGTHUNIT["metre",1],ID["EPSG",8816]],PARAMETER["Northing at projection centre",1200000,LENGTHUNIT["metre",1],ID["EPSG",8817]]],CS[Cartesian,2],AXIS["(E)",east,ORDER[1],LENGTHUNIT["metre",1,ID["EPSG",9001]]],AXIS["(N)",north,ORDER[2],LENGTHUNIT["metre",1,ID["EPSG",9001]]]] | ||
| EPSG:2056 2660019.111857919 1184616.167839863 8.225 46.81 PROJCRS["CH1903+ / LV95",BASEGEOGCRS["CH1903+",DATUM["CH1903+",ELLIPSOID["Bessel 1841",6377397.155,299.1528128,LENGTHUNIT["metre",1]]],PRIMEM["Greenwich",0,ANGLEUNIT["degree",0.0174532925199433]],ID["EPSG",4150]],CONVERSION["Swiss Oblique Mercator 1995",METHOD["Hotine Oblique Mercator (variant B)",ID["EPSG",9815]],PARAMETER["Latitude of projection centre",46.9524055555556,ANGLEUNIT["degree",0.0174532925199433],ID["EPSG",8811]],PARAMETER["Longitude of projection centre",7.43958333333333,ANGLEUNIT["degree",0.0174532925199433],ID["EPSG",8812]],PARAMETER["Azimuth at projection centre",90,ANGLEUNIT["degree",0.0174532925199433],ID["EPSG",8813]],PARAMETER["Angle from Rectified to Skew Grid",90,ANGLEUNIT["degree",0.0174532925199433],ID["EPSG",8814]],PARAMETER["Scale factor at projection centre",1,SCALEUNIT["unity",1],ID["EPSG",8815]],PARAMETER["Easting at projection centre",2600000,LENGTHUNIT["metre",1],ID["EPSG",8816]],PARAMETER["Northing at projection centre",1200000,LENGTHUNIT["metre",1],ID["EPSG",8817]]],CS[Cartesian,2],AXIS["(E)",east,ORDER[1],LENGTHUNIT["metre",1,ID["EPSG",9001]]],AXIS["(N)",north,ORDER[2],LENGTHUNIT["metre",1,ID["EPSG",9001]]]] |
Contributor
There was a problem hiding this comment.
Reference value changed for EPSG:2056 (LV95), about 80 m east and 146 m north. The old row is replaced by a value that the new code produces. The row was previously in by_code_only, so it was never checked numerically. It is now checked to 1 m against this row, so the row and the code agree by construction. The header attributes the new value to PROJ 9.8.1, but PROJ version bumps don't usually move LV95 by about 150 m. The likely cause is a different datum operation (the bundled Helmert versus a grid, or a changed CH1903+ transformation), not the projection formula.
Confidence: medium. I could not verify this offline. Before merging, please state which PROJ operation produced the new value, and check it against an independent source such as swisstopo's published LV95 coordinates for a reference point. If the 150 m shift is not explained, keep the old value and investigate the Swiss path separately.
| // arrives as the plain name through the METHODS table. | ||
| "HOTINE_OBLIQUE_MERCATOR" | "HOTINE_OBLIQUE_MERCATOR_AZIMUTH_NATURAL_ORIGIN" if get(&["AZIMUTH"]).is_some() => omerc(true)?, | ||
| // EPSG's methods 9806 and 9818 have no scale factor; PROJ's cass and poly ignore one. | ||
| "CASSINI_SOLDNER" => format!("+proj=cass +lat_0={lat0} {at}"), |
Contributor
There was a problem hiding this comment.
Possible gap: ArcGIS's .prj name for Cassini-Soldner may not match. The reader matches only CASSINI_SOLDNER, which is the normalized form of GDAL's Cassini_Soldner. ArcGIS, as I recall it, writes Cassini. Such files are refused with an error rather than drawn wrong, so this is not silent. It is still a gap for the ESRI systems the PR mentions as candidates.
Confidence: low to medium, unverified here. If it's right, add the alias and a test with an ESRI Cassini .prj:
Suggested change
| "CASSINI_SOLDNER" => format!("+proj=cass +lat_0={lat0} {at}"), | |
| "CASSINI_SOLDNER" | "CASSINI" => format!("+proj=cass +lat_0={lat0} {at}"), |
| available. Swiss oblique Mercator and the standard Krovak East/North variant are supported from | ||
| their parameters. | ||
| available. Swiss oblique Mercator, the standard Krovak East/North variant, and the oblique | ||
| Mercator, Cassini-Soldner, polyconic and Equal Earth methods are supported from their |
Contributor
There was a problem hiding this comment.
The docs overstate the oblique Mercator support. Only the azimuth forms are supported. The two-point Hotine form (no AZIMUTH, ESRI 53025 and 54025) is still refused, as esri.rs says. Suggest "the azimuth forms of the oblique Mercator". The same applies to the refusal list in docs/user-guide/maps.md (around line 329), which now omits the two-point case. Confidence: high.
Contributor
Code reviewScope: This PR is titled "chore(deps): bump proj4rs from 0.2.1 to 0.3.0", but the diff also adds about 200 lines of new projection support: Hotine oblique Mercator, Cassini-Soldner, polyconic and Equal Earth, plus tests and docs. The PR body is Dependabot's text and says none of this. The bump and the feature should be split into separate PRs or commits. Bugs
Security: No issues found. The new WKT paths use Performance: Nothing notable. Quality
AGENTS.md
Change sizeCompared: the whole PR against main (merge base 6692b1b to PR head 85cb511).
|
Buffer's fix lets a long line and polygons agree with the reference, and the test fails on a marked case that agrees. The point and road cases still differ, within their looser tolerance, so they keep theirs.
…ot/cargo/proj4rs-0.3.0
| # The tests' Zstandard-compressed GeoTIFFs (the version the tiff crate decodes with). | ||
| zstd = { version = "0.14", default-features = false } | ||
| proj4rs = { version = "0.2", default-features = false } | ||
| proj4rs = { version = "0.3", default-features = false } |
Contributor
There was a problem hiding this comment.
Bugs (CI): fuzz/Cargo.lock still pins proj4rs 0.2.1 and proj4rs-geodesic 0.1.1. The fuzz crate is its own workspace and builds rustgis-data by path, so it now needs proj4rs 0.3. .github/workflows/fuzz.yml runs cargo deny --manifest-path fuzz/Cargo.toml --locked check licenses, which fails when the lock would need an update. That job runs on ci:fuzz-labelled PRs and nightly. Fix: run cargo update -p proj4rs --manifest-path fuzz/Cargo.toml (or cargo generate-lockfile there) and commit the lock. Confidence: high.
Comment on lines
+1178
to
+1179
| // does: 54°W 10°S lands at (5 000 000, 8 894 145.167) in pyproj 3.8.0's EPSG:5880, its | ||
| // false easting less a million-odd metres. |
Contributor
There was a problem hiding this comment.
Quality: the comment is wrong about which offset is which. x = 5 000 000 is EPSG:5880's false easting, so it isn't "its false easting less a million-odd metres". The offset is in the northing: 10 000 000 − 8 894 145 ≈ 1.1 million m. Confidence: medium-high (from the EPSG:5880 parameters, not checked against the file).
Suggested change
| // does: 54°W 10°S lands at (5 000 000, 8 894 145.167) in pyproj 3.8.0's EPSG:5880, its | |
| // false easting less a million-odd metres. | |
| // does: 54°W 10°S lands at (5 000 000, 8 894 145.167) in pyproj 3.8.0's EPSG:5880: the | |
| // false easting itself, and the false northing (10 000 000) less about 1.1 million metres. |
Contributor
Code reviewBugs
Security
Performance
Quality
AGENTS.md
No other findings survived. I did not run the test suite, since this review had no execution tool; the pyproj-derived expectations are unverified. Change sizeCompared with
|
Member
|
@coderabbitai review |
Contributor
Action not completed
|
| //! planetary ones (Moon, Mars), whose bodies the map can't hold; | ||
| //! - the seven PROJ can't write as a PROJ string (Hammer–Aitoff, Fuller, Cube, Tobler …) and the | ||
| //! two oblique Mercators it refuses (53025, 54025). | ||
| //! two two-point oblique Mercators (53025, 54025), for which RustGIS has no WKT form. |
Contributor
There was a problem hiding this comment.
Nit (wording, high confidence): "for which RustGIS has no WKT form" makes it sound as if these two codes have no WKT at all. ESRI's WKT1 does have a two-point form, and RustGIS refuses it (the azimuth-less case in wkt.rs, around line 685). The previous wording, "it refuses", said that. The doubled "two two-point" also reads awkwardly.
Suggested change
| //! two two-point oblique Mercators (53025, 54025), for which RustGIS has no WKT form. | |
| //! two-point oblique Mercators (53025, 54025), which RustGIS refuses. |
Contributor
Code reviewI read the full diff against the staged AGENTS.md and the prior threads. I checked the new Hotine/omerc guard and its WKT1/WKT2 method mapping, the Bugs
Security
Performance
Quality
AGENTS.md
Earlier threads
Change sizeCompared: the whole PR against main (merge base 4392fc2 to PR head 255d8ce).
|
Member
|
@coderabbitai resume |
Contributor
Action not completed
|
deniial00
approved these changes
Nov 2, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bumps proj4rs from 0.2.1 to 0.3.0.
Commits
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)