Invalid projection factors for PROJ test case (EPSG:5972) #58249
Comments
kannes
added
the
Bug
kannes
changed the title
|
Running proj on the command line for those coordinates in that CRS also works on my system and provides the wanted values: |
|
@kannes, I cannot replicate the issue on my Windows 10 system using QGIS 3.38.0 [PROJ 9.4.0 / EPSG Registry database version v11.004 (2024-02-24)]: crs = QgsCoordinateReferenceSystem.fromEpsgId(5972)
crs.factors(QgsPoint(9, 0))
<QgsProjectionFactors>
crs.factors(QgsPoint(9, 0)).isValid()
True
crs.factors(QgsPoint(9, 0)).meridionalScale()
0.9996000000506514 |
|
Huh, interesting! I cannot reproduce the issue on other systems as well:
Both get a valid The main difference is Proj 9.4.0 vs 9.4.1. |
|
Another one does have the same issue:
Again, Proj 9.4.1 |
|
@kannes, I've also tried using PROJ 9.4.1 [proj_9_4.dll and proj.db from anaconda] with QGIS 3.38.1 [from OSGeo4W]
and I have the same output in the Python console crs = QgsCoordinateReferenceSystem.fromEpsgId(5972)
crs.factors(QgsPoint(9, 0))
<QgsProjectionFactors>
crs.factors(QgsPoint(9, 0)).isValid()
True
crs.factors(QgsPoint(9, 0)).meridionalScale()
0.9996000000506514No issue also using both QGIS 3.38.1 and PROJ 9.4.1 from conda-forge with on Windows 11. |
|
Have you also tried QGIS from Flatpak and Spack? I think they have both PROJ 9.4.1. |
|
With this verision is working for me: <style type="text/css"> p, li { white-space: pre-wrap; } </style>
... and after updating conda as well <style type="text/css"> p, li { white-space: pre-wrap; } </style>
|
|
That CRS is a compound one https://spatialreference.org/ref/epsg/5972/ |
Now I remember that support for compound CRSs was added later: OSGeo/PROJ@6f9fd55 |
agiudiceandrea
added
Packaging
Projections/Transformations
|
25832 seems to work fine in my tests but I wanted to use external, definitely-correct data to validate if my plugin does things correctly. Is QGIS not able to handle such compound CRS correctly maybe? |
I don't think so. On my Windows 10 / Windows 11 systems (either using both QGIS 3.38.0 and PROJ 9.4.0 from OSGeo4W or QGIS 3.38.1 from OSGeo4W and PROJ 9.4.1 from conda or both QGIS 3.38.1 and PROJ 9.4.1 from conda) and on Ubuntu 22.04 (using QGIS 3.3.8.1 and PROJ 9.4.1 from conda as reported by @jjimenezshaw) the issue doesn't occur. |
It is working for other people. I think it is a problem in your QGIS, maybe using a different installed version of PROJ (due to any unknown reason). Maybe you can check in your linux exactly what libproj.so is opening your QGIS (not an ldd, but the actual file opened at runtime) with something like |
|
Sorry, totally posted in a hurry and missed the 3.38 + 9.4.1 combos working. Testing on the Manjaro oneThe proj binary works fine. QGIS does not. Both use the same QGISproj (entered
|
What is the bug or the crash?
Trying to debug a work-in-progress plugin of mine for projection factor visualisation I found some issues with https://qgis.org/pyqgis/master/core/QgsCoordinateReferenceSystem.html#qgis.core.QgsCoordinateReferenceSystem.factors
Trying to replicate the last test case (for EPSG:5972) from /~https://github.com/OSGeo/PROJ/blob/7d766a4ba112ec71c9e861c66d571cbdddd71009/test/cli/test_proj.yaml#L18-L21 I get an invalid result instead of the values in PROJ's test case.
The test case above those lines (for EPSG:27571) works fine.
Steps to reproduce the issue
Versions
<style type="text/css"> p, li { white-space: pre-wrap; } </style>Supported QGIS version
New profile
Additional context
Example value from the other, working test case:
QgsCoordinateReferenceSystem.fromEpsgId(27571).factors(QgsPoint(2.33722917, 49.5)).meridionalScale()->0.9998773409826835, which matches the test cases0.999877The text was updated successfully, but these errors were encountered: