Open nirvn opened 4 years ago
avoid suggest best picks for transformation extents that don't fall straight within (or mostly) within the project extent.
I had recently a similar issue, with a dataset with a small footprint in California using NAD27 datum, and to be reprojected to EPSG:4326. QGIS told me that the best transformation was missing a grid that actually is only valid for Canada. Actually it just reflected what "projinfo -s NAD27 -t "WGS 84" --spatial-test intersects" outputs.
I'd flag this issue more as an improvement, than a bug however. With current behaviour, the user can still overrlde the default proposed
The resolution of this issue is far from being obvious to me. Even if the current datum choice proposal took into account the concept of an area of use, that would be messy to administrate. What if your next area of use for another project is not exactly the same as before ? What "Make default" should do then ? You could end up with a database of tens of entries like (input_crs_A, output_crs_B, area_of_use_1), (input_crs_A, output_crs_B, area_of_use_2), ... (input_crs_A, output_crs_B, area_of_use_N). How do you clean that, etc.. ?
Another consideration is that an area of use based on bounding box is itself an approximation. And this is also an issue valid for PROJ itself (see https://github.com/OSGeo/PROJ/issues/1461). The area_of_use table in the EPSG dataset is bbox based, but there are GML Polygon files also released with polygonal extent, generally based on country borders. So this could potentially be improved on PROJ side, but a non-trivial effort for sure.
@rouault , you are right, had a hard time choosing between issue vs improvement.
Valid point re [x] make default. In fact, should the option of making a given transform be default even exist outside the scope of a given project?
Regarding bounding boxes, while we shouldn't eliminate candidates on the basis of bounding box, we could likely still rely on that to improve the suggested / best-pick one.
I think a real fix for this relies on us adding a concept of a project "area of interest". The current canvas extent isn't suitable for determining the area of a project.
Describe the bug
The transformation selection dialog for PROJ6-enabled QGIS builds needs to refine the way it suggests the best pick. For e.g.:
In this example, my project boundaries is roughly the purple extent shown above. However, the transformation selection dialog suggests a best-pick transformation that for the most part falls outside the project extent.
It's misleading, and we could likely be a bit more clever and avoid suggest best picks for transformation extents that don't fall straight within (or mostly) within the project extent.
@nyalldawson , thoughts?