QGIS "Ballpark Transformations" #34983

northrivergeo · 2020-03-11T00:42:44Z

I received an email from two users with 3.12 asking about "Ballpark Transformations" - the exact phrase was "Used a Ballpark transformation from EPSG:4326 to EPSG: 2274".

I've been able to generate the message twice by:

changing the projection of a new project with no data from 4326 to 2274
adding data with an incorrect spatial extent that I believe was in 4326 and applied to a project in 2274 (I think - I currently don't have access to that data to confirm but the user sent me a screenshot)

I've found mention of it here: https://qgis.org/api/classQgsCoordinateTransform.html#a16adb051fafc25058c0040a310f1606b

The expanded message in QGIS is:

An alternative, ballpark-only transform was used when transforming coordinates between >EPSG:4326 - WGS 84 and EPSG:2274 - NAD83 / Tennessee (ftUS). The results may not match >those obtained by using the preferred operation:

Possibly an incorrect choice of operation was made for transformations between these reference >systems. Check the Project Properties and ensure that the selected transform operations are >applicable over the whole extent of the current project.

If I check the project properties there is no Datum Transformation defined after all this happens.

I'm assuming that if a project has no data and one jumps datums by changing the projection it's saying "Hey since there is no data this transformation is a "ballpark" i.e. not exact".

northrivergeo · 2020-03-11T00:44:39Z

From the QGIS Users list:

Example:
Project created in old version of qgis and opened in recent version. It comes up with the message about "Ballpark Transformations" and suggests installing proj-datumgrid-europe-1.5.zip to enable a better transformatoin between epsg:27700 and epsg:4326. The project contains the OS GB1936 system and WGS84.

So I installed the relevant .gsb files in the correct directory with the other .gsb files, restarted and tried again to open the project. This time it did not come up with the message suggesting the download but instead just suggested using one of the other transformations which are less accurate than the proper OSTN15_NTv2 transformation.

Need to know why it is doing the less accurate transformation and how to get it to do the correct transformation instead.

gioman · 2020-03-11T12:39:53Z

Need to know why it is doing the less accurate transformation and how to get it to do the correct transformation instead.

Hi @rjhale1971 see #33929 and #34273 if the answer is satisfactory can we close this? cheers!

northrivergeo · 2020-03-11T22:00:08Z

Let me take a look! Sorry I'm just getting to this

northrivergeo · 2020-03-11T22:09:23Z

So I'm reading through the bug reports and in two sentences or less: Something in this project falls outside the specified grid so this is expected. (I may have completely botched that explanation)

nyalldawson · 2020-03-11T22:18:48Z

So not a bug?

northrivergeo · 2020-03-11T22:23:38Z

Reading through the two other reports I'm guessing this one has been handled - I guess my question would be when faced with this message it really points to a data issue falling outside of a grid? I only ask because I had another phone call today and I'm a bit fuzzy on the resolution shown in the other two bug reports.

nyalldawson · 2020-03-11T22:30:57Z

That would be the most common explanation. There's possibly other reasons a particular transform may fail causing a fallback ("ballpark") transform to be used though.

roya0045 · 2020-03-11T22:41:26Z

Could the term ballpark be replaced by fallback or any of its related synonyms? Unless ballpark is the term in might cause more confusions in some language or crowds. I'm not sure what translations come up in qt for this, as the word can have three distinct meanings.

nyalldawson · 2020-03-11T23:04:11Z

@roya0045 I think that's up to individual translators to do -- the term already has usage elsewhere in English in the projection world.

northrivergeo · 2020-03-12T00:16:36Z

One more question - and this may be my general lack of not knowing enough on proj. If the "Ballpark transform" comes up - Do I need to fix it or can I just keep working. Does it affect future data collection or is the new data independent of the message.....and this may make no sense as it's been a long day.

Other than that - this can be closed since I'm not the only one this has happened to......

nyalldawson · 2020-03-12T01:31:57Z

No, it's not an error, it's just warning you that you aren't getting the exact results you expected. It would only be an issue if you are working on scales where the difference between the grid based transform and the fallback is an issue. QGIS can't make that decision for you, so it warns you, and it's up to you to decide if this is something you need to fix (e.g. by picking a more appropriate transform) or if it's acceptable given the context of your work.

We could hide that message, but I'm a big fan of transparency in analysis and pushing all responsibility for making correct decisions back to users.

northrivergeo · 2020-03-12T01:36:46Z

Makes sense - I'd rather have it there (now that I know what's happening) than hide it.
I'm good - we can close this. Virtual beers for all and normal measurements like feet and inches for everyone else.

elpaso · 2020-03-12T07:30:53Z

@roya0045 I think that's up to individual translators to do -- the term already has usage elsewhere in English in the projection world.

Can we just add some more understandable explanation? Many users are using QGIS in english even if that's not their primary language.

nyalldawson · 2020-03-12T08:11:14Z

@elpaso there is a more descriptive explanation available when you click the message

rouault · 2020-03-12T12:38:32Z

To be clear, in the current PROJ implementation (and in the foreseable future), the ballpark transformation for horizontal datum shifting is a null transformation, that is we assume that the datums are identical, because we have no other information available. The error in doing so can range from 200 meters when transforming between datums < 1950 and modern datums, to just a few meters when transforming between modern datums.
Initially I suggested "null transformation", but there are cases where a null transformation is geodetically OK, like ETRS89<-->WGS84. So the "ballpark transformation" is actually a "null ballpark transformation".

For vertical transformations (but QGIS is likely not triggering that a lot), there can be vertical ballpark transformations as well. For now they are null too, but we could potentially try to be smarter (see OSGeo/PROJ#1743)

northrivergeo · 2020-03-12T13:58:33Z

So for me (english speaking guy in the southern United States) I use the term "ballpark" when I need a very loose fitting answer. As in "How much to fix this car - can you give me a ballpark estimate" and 'ballpark' is know to be imprecise. I use the term guesstimate or estimate which it sounds like the ballpark transformation isn't doing - it's "not doing anything". For me (and I in no way can speak for the myriad of users out there) I like NULL transformation as that implies nothing happened. Ballpark makes it sound like SOMETHING happened - and whatever it was wasn't very precise - BUT - as far as I know that will be a North American way of looking at the word "ballpark". We can't even handle the metric system so take that for what it's worth.

nyalldawson · 2020-03-12T18:08:41Z

@rjhale1971 it's not doing a null transform. It's doing some transform, but not the one you asked for...

mikedoddOU · 2020-03-19T16:04:07Z

What I need to know is whether qgis is doing the correct OSTN02 (or OSTN15) transformation within the area that it can and only doing the ballpark transformation outside this area or whether it is doing the approximate transformatoin over the whole area. Then need to know how to get it to do the full accuracy transformation in the area that it can.
There must be a bug here as the OSTN02 tranformation applies to the UK ordnance survey data and maps and it used to work fine but now the OS map tiles themselves give this ballpark issue when by definition they must be within the area that the transformation applies to. The OSTN02 transformation files are in the correct place in the relevant qgis directory.

PedroVenancio · 2020-04-01T22:20:11Z

Hi all,

I must confess that something is strange to me here.

I've a QGIS project in EPSG:3763;
I load a PostGIS layer with portuguese geodetic network in EPSG:3763;
Then I load another PostGIS layer with same portuguese geodetic network, but in EPSG:20791. The Ballpark warning appears (Used a ballpark transform from EPSG:20791 to EPSG:3763).

PROJ has a grid transformation file (pt_dgt_DLx_ETRS89_geo) between these CRS, that I loaded in QGIS, to ensure that covers all geodetic points.

projinfo -s EPSG:20791 -t EPSG:3763
Candidate operations found: 2

Operation No. 1:

unknown id, Inverse of Portuguese Grid + Lisbon (Lisbon) to Lisbon (1) + Lisbon to ETRS89 (4) + Portugual TM06, 0.1 m, Portugal - mainland - onshore

PROJ string:
+proj=pipeline +step +inv +proj=tmerc +lat_0=39.6666666666667 +lon_0=1 +k=1 +x_0=0 +y_0=0 +ellps=intl +pm=lisbon +step +proj=hgridshift +grids=pt_dgt_DLx_ETRS89_geo.tif +step +proj=tmerc +lat_0=39.6682583333333 +lon_0=-8.13310833333333 +k=1 +x_0=0 +y_0=0 +ellps=GRS80

WKT2:2019 string:
CONCATENATEDOPERATION["Inverse of Portuguese Grid + Lisbon (Lisbon) to Lisbon (1) + Lisbon to ETRS89 (4) + Portugual TM06",
    SOURCECRS[
        PROJCRS["Lisbon (Lisbon) / Portuguese Grid",
            BASEGEOGCRS["Lisbon (Lisbon)",
                DATUM["Lisbon 1937 (Lisbon)",
                    ELLIPSOID["International 1924",6378388,297,
                        LENGTHUNIT["metre",1]]],
                PRIMEM["Lisbon",-9.13190611111111,
                    ANGLEUNIT["degree",0.0174532925199433]],
                ID["EPSG",4803]],
            CONVERSION["Portuguese Grid",
                METHOD["Transverse Mercator",
                    ID["EPSG",9807]],
                PARAMETER["Latitude of natural origin",39.6666666666667,
                    ANGLEUNIT["degree",0.0174532925199433],
                    ID["EPSG",8801]],
                PARAMETER["Longitude of natural origin",1,
                    ANGLEUNIT["degree",0.0174532925199433],
                    ID["EPSG",8802]],
                PARAMETER["Scale factor at natural origin",1,
                    SCALEUNIT["unity",1],
                    ID["EPSG",8805]],
                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]],
                AXIS["northing (Y)",north,
                    ORDER[2],
                    LENGTHUNIT["metre",1]],
            ID["EPSG",20791]]],
    TARGETCRS[
        PROJCRS["ETRS89 / Portugal TM06",
            BASEGEOGCRS["ETRS89",
                DATUM["European Terrestrial Reference System 1989",
                    ELLIPSOID["GRS 1980",6378137,298.257222101,
                        LENGTHUNIT["metre",1]]],
                PRIMEM["Greenwich",0,
                    ANGLEUNIT["degree",0.0174532925199433]],
                ID["EPSG",4258]],
            CONVERSION["Portugual TM06",
                METHOD["Transverse Mercator",
                    ID["EPSG",9807]],
                PARAMETER["Latitude of natural origin",39.6682583333333,
                    ANGLEUNIT["degree",0.0174532925199433],
                    ID["EPSG",8801]],
                PARAMETER["Longitude of natural origin",-8.13310833333333,
                    ANGLEUNIT["degree",0.0174532925199433],
                    ID["EPSG",8802]],
                PARAMETER["Scale factor at natural origin",1,
                    SCALEUNIT["unity",1],
                    ID["EPSG",8805]],
                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]],
                AXIS["northing (Y)",north,
                    ORDER[2],
                    LENGTHUNIT["metre",1]],
            ID["EPSG",3763]]],
    STEP[
        CONVERSION["Inverse of Portuguese Grid",
            METHOD["Inverse of Transverse Mercator",
                ID["INVERSE(EPSG)",9807]],
            PARAMETER["Latitude of natural origin",39.6666666666667,
                ANGLEUNIT["degree",0.0174532925199433],
                ID["EPSG",8801]],
            PARAMETER["Longitude of natural origin",1,
                ANGLEUNIT["degree",0.0174532925199433],
                ID["EPSG",8802]],
            PARAMETER["Scale factor at natural origin",1,
                SCALEUNIT["unity",1],
                ID["EPSG",8805]],
            PARAMETER["False easting",0,
                LENGTHUNIT["metre",1],
                ID["EPSG",8806]],
            PARAMETER["False northing",0,
                LENGTHUNIT["metre",1],
                ID["EPSG",8807]],
            ID["INVERSE(EPSG)",19969]]],
    STEP[
        COORDINATEOPERATION["Lisbon (Lisbon) to Lisbon (1)",
            VERSION["IGC-Prt"],
            SOURCECRS[
                GEOGCRS["Lisbon (Lisbon)",
                    DATUM["Lisbon 1937 (Lisbon)",
                        ELLIPSOID["International 1924",6378388,297,
                            LENGTHUNIT["metre",1]]],
                    PRIMEM["Lisbon",-9.13190611111111,
                        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]],
                    ID["EPSG",4803]]],
            TARGETCRS[
                GEOGCRS["Lisbon",
                    DATUM["Lisbon 1937",
                        ELLIPSOID["International 1924",6378388,297,
                            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]],
                    ID["EPSG",4207]]],
            METHOD["Longitude rotation",
                ID["EPSG",9601]],
            PARAMETER["Longitude offset",-9.13190611111111,
                ANGLEUNIT["degree",0.0174532925199433],
                ID["EPSG",8602]],
            OPERATIONACCURACY[0.0],
            ID["EPSG",1756]]],
    STEP[
        COORDINATEOPERATION["Lisbon to ETRS89 (4)",
            SOURCECRS[
                GEOGCRS["Lisbon",
                    DATUM["Lisbon 1937",
                        ELLIPSOID["International 1924",6378388,297,
                            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]],
                    ID["EPSG",4207]]],
            TARGETCRS[
                GEOGCRS["ETRS89",
                    DATUM["European Terrestrial Reference System 1989",
                        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]],
                    ID["EPSG",4258]]],
            METHOD["HORIZONTAL_SHIFT_GTIFF"],
            PARAMETERFILE["Latitude and longitude difference file","pt_dgt_DLx_ETRS89_geo.tif"],
            OPERATIONACCURACY[0.1],
            ID["DERIVED_FROM(EPSG)",6188]]],
    STEP[
        CONVERSION["Portugual TM06",
            METHOD["Transverse Mercator",
                ID["EPSG",9807]],
            PARAMETER["Latitude of natural origin",39.6682583333333,
                ANGLEUNIT["degree",0.0174532925199433],
                ID["EPSG",8801]],
            PARAMETER["Longitude of natural origin",-8.13310833333333,
                ANGLEUNIT["degree",0.0174532925199433],
                ID["EPSG",8802]],
            PARAMETER["Scale factor at natural origin",1,
                SCALEUNIT["unity",1],
                ID["EPSG",8805]],
            PARAMETER["False easting",0,
                LENGTHUNIT["metre",1],
                ID["EPSG",8806]],
            PARAMETER["False northing",0,
                LENGTHUNIT["metre",1],
                ID["EPSG",8807]],
            ID["EPSG",19853]]],
    USAGE[
        SCOPE["unknown"],
        AREA["Portugal - mainland - onshore"],
        BBOX[36.95,-9.56,42.16,-6.19]]]

Operation No. 2:

unknown id, Inverse of Portuguese Grid + Lisbon (Lisbon) to Lisbon (1) + Lisbon to ETRS89 (3) + Portugual TM06, 2.5 m, Portugal - mainland - onshore

PROJ string:
+proj=pipeline +step +inv +proj=tmerc +lat_0=39.6666666666667 +lon_0=1 +k=1 +x_0=0 +y_0=0 +ellps=intl +pm=lisbon +step +proj=push +v_3 +step +proj=cart +ellps=intl +step +proj=helmert +x=-303.861 +y=-60.693 +z=103.607 +step +inv +proj=cart +ellps=GRS80 +step +proj=pop +v_3 +step +proj=tmerc +lat_0=39.6682583333333 +lon_0=-8.13310833333333 +k=1 +x_0=0 +y_0=0 +ellps=GRS80

WKT2:2019 string:
CONCATENATEDOPERATION["Inverse of Portuguese Grid + Lisbon (Lisbon) to Lisbon (1) + Lisbon to ETRS89 (3) + Portugual TM06",
    SOURCECRS[
        PROJCRS["Lisbon (Lisbon) / Portuguese Grid",
            BASEGEOGCRS["Lisbon (Lisbon)",
                DATUM["Lisbon 1937 (Lisbon)",
                    ELLIPSOID["International 1924",6378388,297,
                        LENGTHUNIT["metre",1]]],
                PRIMEM["Lisbon",-9.13190611111111,
                    ANGLEUNIT["degree",0.0174532925199433]],
                ID["EPSG",4803]],
            CONVERSION["Portuguese Grid",
                METHOD["Transverse Mercator",
                    ID["EPSG",9807]],
                PARAMETER["Latitude of natural origin",39.6666666666667,
                    ANGLEUNIT["degree",0.0174532925199433],
                    ID["EPSG",8801]],
                PARAMETER["Longitude of natural origin",1,
                    ANGLEUNIT["degree",0.0174532925199433],
                    ID["EPSG",8802]],
                PARAMETER["Scale factor at natural origin",1,
                    SCALEUNIT["unity",1],
                    ID["EPSG",8805]],
                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]],
                AXIS["northing (Y)",north,
                    ORDER[2],
                    LENGTHUNIT["metre",1]],
            ID["EPSG",20791]]],
    TARGETCRS[
        PROJCRS["ETRS89 / Portugal TM06",
            BASEGEOGCRS["ETRS89",
                DATUM["European Terrestrial Reference System 1989",
                    ELLIPSOID["GRS 1980",6378137,298.257222101,
                        LENGTHUNIT["metre",1]]],
                PRIMEM["Greenwich",0,
                    ANGLEUNIT["degree",0.0174532925199433]],
                ID["EPSG",4258]],
            CONVERSION["Portugual TM06",
                METHOD["Transverse Mercator",
                    ID["EPSG",9807]],
                PARAMETER["Latitude of natural origin",39.6682583333333,
                    ANGLEUNIT["degree",0.0174532925199433],
                    ID["EPSG",8801]],
                PARAMETER["Longitude of natural origin",-8.13310833333333,
                    ANGLEUNIT["degree",0.0174532925199433],
                    ID["EPSG",8802]],
                PARAMETER["Scale factor at natural origin",1,
                    SCALEUNIT["unity",1],
                    ID["EPSG",8805]],
                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]],
                AXIS["northing (Y)",north,
                    ORDER[2],
                    LENGTHUNIT["metre",1]],
            ID["EPSG",3763]]],
    STEP[
        CONVERSION["Inverse of Portuguese Grid",
            METHOD["Inverse of Transverse Mercator",
                ID["INVERSE(EPSG)",9807]],
            PARAMETER["Latitude of natural origin",39.6666666666667,
                ANGLEUNIT["degree",0.0174532925199433],
                ID["EPSG",8801]],
            PARAMETER["Longitude of natural origin",1,
                ANGLEUNIT["degree",0.0174532925199433],
                ID["EPSG",8802]],
            PARAMETER["Scale factor at natural origin",1,
                SCALEUNIT["unity",1],
                ID["EPSG",8805]],
            PARAMETER["False easting",0,
                LENGTHUNIT["metre",1],
                ID["EPSG",8806]],
            PARAMETER["False northing",0,
                LENGTHUNIT["metre",1],
                ID["EPSG",8807]],
            ID["INVERSE(EPSG)",19969]]],
    STEP[
        COORDINATEOPERATION["Lisbon (Lisbon) to Lisbon (1)",
            VERSION["IGC-Prt"],
            SOURCECRS[
                GEOGCRS["Lisbon (Lisbon)",
                    DATUM["Lisbon 1937 (Lisbon)",
                        ELLIPSOID["International 1924",6378388,297,
                            LENGTHUNIT["metre",1]]],
                    PRIMEM["Lisbon",-9.13190611111111,
                        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]],
                    ID["EPSG",4803]]],
            TARGETCRS[
                GEOGCRS["Lisbon",
                    DATUM["Lisbon 1937",
                        ELLIPSOID["International 1924",6378388,297,
                            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]],
                    ID["EPSG",4207]]],
            METHOD["Longitude rotation",
                ID["EPSG",9601]],
            PARAMETER["Longitude offset",-9.13190611111111,
                ANGLEUNIT["degree",0.0174532925199433],
                ID["EPSG",8602]],
            OPERATIONACCURACY[0.0],
            ID["EPSG",1756]]],
    STEP[
        COORDINATEOPERATION["Lisbon to ETRS89 (3)",
            VERSION["CGC-Prt 2009 7m"],
            SOURCECRS[
                GEOGCRS["Lisbon",
                    DATUM["Lisbon 1937",
                        ELLIPSOID["International 1924",6378388,297,
                            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]],
                    ID["EPSG",4207]]],
            TARGETCRS[
                GEOGCRS["ETRS89",
                    DATUM["European Terrestrial Reference System 1989",
                        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]],
                    ID["EPSG",4258]]],
            METHOD["Geocentric translations (geog2D domain)",
                ID["EPSG",9603]],
            PARAMETER["X-axis translation",-303.861,
                LENGTHUNIT["metre",1],
                ID["EPSG",8605]],
            PARAMETER["Y-axis translation",-60.693,
                LENGTHUNIT["metre",1],
                ID["EPSG",8606]],
            PARAMETER["Z-axis translation",103.607,
                LENGTHUNIT["metre",1],
                ID["EPSG",8607]],
            OPERATIONACCURACY[2.5],
            ID["EPSG",5038],
            REMARK["Derived in July 2009 from 119 common stations. Info source also gives a Position Vector tfm which is of similar accuracy. Replaces Lisbon to ETRS89 (2) (tfm code 1997)."]]],
    STEP[
        CONVERSION["Portugual TM06",
            METHOD["Transverse Mercator",
                ID["EPSG",9807]],
            PARAMETER["Latitude of natural origin",39.6682583333333,
                ANGLEUNIT["degree",0.0174532925199433],
                ID["EPSG",8801]],
            PARAMETER["Longitude of natural origin",-8.13310833333333,
                ANGLEUNIT["degree",0.0174532925199433],
                ID["EPSG",8802]],
            PARAMETER["Scale factor at natural origin",1,
                SCALEUNIT["unity",1],
                ID["EPSG",8805]],
            PARAMETER["False easting",0,
                LENGTHUNIT["metre",1],
                ID["EPSG",8806]],
            PARAMETER["False northing",0,
                LENGTHUNIT["metre",1],
                ID["EPSG",8807]],
            ID["EPSG",19853]]],
    USAGE[
        SCOPE["unknown"],
        AREA["Portugal - mainland - onshore"],
        BBOX[36.95,-9.56,42.16,-6.19]]]

Going to Project Properties, I see that the best transformation of 2 available is applied. The one that use the hgridshift.

Looking at the accuracy of the transformation, I confirm that the gridshift file is being applied.
If I choose the other transformation option available (3 parameters), I get a much worst transformation

So, I can't really understand why is this warning displayed, when the best transformation is choosed.

Any hint?

nyalldawson · 2020-04-01T22:34:52Z

Can you share a sample project?

PedroVenancio · 2020-04-01T22:51:31Z

Hi @nyalldawson

Yes, of course, thank you very much for looking at this. Here is a project with these layers I was talking about:

Ballpark_Warning_20791_3763.zip

nyalldawson · 2020-04-01T23:39:58Z

@PedroVenancio - perfect, fix inbound. You can safely ignore this warning for this project, it's just being overly pedantic.

PedroVenancio · 2020-04-02T00:01:28Z

Really great @nyalldawson !

Thank you very much!

for rendering We can safely use ballpark transforms without bothering the user here -- at the likely scale of layer extents there won't be an appreciable difference, and we aren't actually transforming any rendered points here anyway (just the layer extent) Fixes qgis#34983

mikedoddOU · 2020-04-02T08:07:14Z

But the point is that it is giving this warning on numerous different projects for many people now who are using a range of different CRS. As I mentioned in one of the comments the various ballpark options offered for the UK system give a wide range of accuracies but none of them are the full OSTN02 or OSTN15 which is needed when using differential gps and highly accurate basemaps. Basically it gives the impression that you can't use qgis for survey grade mapping - is that now true? Either way this urgently needs to be sorted out.

…

________________________________ From: Pedro Venancio <[email protected]> Sent: 02 April 2020 01:01 To: qgis/QGIS <[email protected]> Cc: Michael.Dodd <[email protected]>; Comment <[email protected]> Subject: Re: [qgis/QGIS] QGIS "Ballpark Transformations" (#34983) CAUTION: This mail comes from outside the University. Please consider this before opening attachments, clicking links, or acting on the content. Really great @nyalldawson<https://github.com/nyalldawson> ! Thank you very much! — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#34983 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AO4AYVTK3UIFF4AOK5HONGTRKPIWNANCNFSM4LFK4YAA>.

nyalldawson · 2020-04-02T08:17:36Z

@mikedoddOU did you test the linked patch?

mikedoddOU · 2020-04-02T08:24:11Z

How do I do that?

nyalldawson · 2020-04-02T08:29:34Z

Wait till it's merged and test the nightlies, and then report back here if you still see issues.

mikedoddOU · 2020-04-02T08:31:51Z

OK, thanks

for rendering We can safely use ballpark transforms without bothering the user here -- at the likely scale of layer extents there won't be an appreciable difference, and we aren't actually transforming any rendered points here anyway (just the layer extent) Fixes #34983

PedroVenancio · 2020-04-02T23:00:41Z

Awesome @nyalldawson !

Thank you very much!

AntonioPestana · 2021-12-02T19:00:50Z

Awesome @nyalldawson !

Thank you very much!

AntonioPestana · 2021-12-02T19:07:19Z

I'm on 3.16.14 and those warnings keep being raised!! Just open @PedroVenancio's project and change the map canvas CRS from EPSG:3763 to EPSG:20790...

gioman · 2021-12-03T09:08:21Z

I'm on 3.16.14 and those warnings keep being raised!! Just open @PedroVenancio's project and change the map canvas CRS from EPSG:3763 to EPSG:20790...

@AntonioPestana cannot confirm:

AntonioPestana · 2021-12-03T10:50:25Z

You are absolutely right. I didn't notice that the "ballpark transformation" warning was missing in the select transformation window!... Sorry about that. Giovanni Manghi ***@***.***> escreveu no dia sexta, 3/12/2021 à(s) 09:08:

…

I'm on 3.16.14 and those warnings keep being raised!! Just open @PedroVenancio <https://github.com/PedroVenancio>'s project and change the map canvas CRS from EPSG:3763 to EPSG:20790... @AntonioPestana <https://github.com/AntonioPestana> cannot confirm: [image: image] <https://user-images.githubusercontent.com/1951107/144576012-6a2eb5f2-0515-4f33-8807-cbffdb98b30e.png> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#34983 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ARYXC6N2QIWHTTBXYVU5J2LUPCCJDANCNFSM4LFK4YAA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

rcragun · 2024-10-23T21:22:08Z

It is not clear what was fixed. Most importantly, we never got an answer to this earlier concern:

What I need to know is whether qgis is doing the correct OSTN02 (or OSTN15) transformation within the area that it can and only doing the ballpark transformation outside this area or whether it is doing the approximate transformatoin over the whole area. Then need to know how to get it to do the full accuracy transformation in the area that it can.

Do I need to open a new issue for this?

northrivergeo added the Bug Either a bug report, or a bug fix. Let's hope for the latter! label Mar 11, 2020

gioman added the Feedback Waiting on the submitter for answers label Mar 11, 2020

gioman changed the title ~~QGIS 3.12 on Windows using a "Ballpark Transformation"~~ QGIS "Ballpark Transformations" Mar 12, 2020

nyalldawson mentioned this issue Apr 2, 2020

Don't raise ballpark transform warnings when reprojecting layer extent for rendering #35517

Merged

nyalldawson closed this as completed in #35517 Apr 2, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

QGIS "Ballpark Transformations" #34983

QGIS "Ballpark Transformations" #34983

northrivergeo commented Mar 11, 2020

northrivergeo commented Mar 11, 2020

gioman commented Mar 11, 2020

northrivergeo commented Mar 11, 2020

northrivergeo commented Mar 11, 2020

nyalldawson commented Mar 11, 2020

northrivergeo commented Mar 11, 2020

nyalldawson commented Mar 11, 2020

roya0045 commented Mar 11, 2020

nyalldawson commented Mar 11, 2020

northrivergeo commented Mar 12, 2020

nyalldawson commented Mar 12, 2020

northrivergeo commented Mar 12, 2020

elpaso commented Mar 12, 2020

nyalldawson commented Mar 12, 2020

rouault commented Mar 12, 2020

northrivergeo commented Mar 12, 2020

nyalldawson commented Mar 12, 2020

mikedoddOU commented Mar 19, 2020

PedroVenancio commented Apr 1, 2020

nyalldawson commented Apr 1, 2020

PedroVenancio commented Apr 1, 2020

nyalldawson commented Apr 1, 2020

PedroVenancio commented Apr 2, 2020

mikedoddOU commented Apr 2, 2020 via email

nyalldawson commented Apr 2, 2020

mikedoddOU commented Apr 2, 2020

nyalldawson commented Apr 2, 2020

mikedoddOU commented Apr 2, 2020

PedroVenancio commented Apr 2, 2020

AntonioPestana commented Dec 2, 2021

AntonioPestana commented Dec 2, 2021 •

edited

Loading

gioman commented Dec 3, 2021

AntonioPestana commented Dec 3, 2021 via email

rcragun commented Oct 23, 2024

QGIS "Ballpark Transformations" #34983

QGIS "Ballpark Transformations" #34983

Comments

northrivergeo commented Mar 11, 2020

northrivergeo commented Mar 11, 2020

gioman commented Mar 11, 2020

northrivergeo commented Mar 11, 2020

northrivergeo commented Mar 11, 2020

nyalldawson commented Mar 11, 2020

northrivergeo commented Mar 11, 2020

nyalldawson commented Mar 11, 2020

roya0045 commented Mar 11, 2020

nyalldawson commented Mar 11, 2020

northrivergeo commented Mar 12, 2020

nyalldawson commented Mar 12, 2020

northrivergeo commented Mar 12, 2020

elpaso commented Mar 12, 2020

nyalldawson commented Mar 12, 2020

rouault commented Mar 12, 2020

northrivergeo commented Mar 12, 2020

nyalldawson commented Mar 12, 2020

mikedoddOU commented Mar 19, 2020

PedroVenancio commented Apr 1, 2020

nyalldawson commented Apr 1, 2020

PedroVenancio commented Apr 1, 2020

nyalldawson commented Apr 1, 2020

PedroVenancio commented Apr 2, 2020

mikedoddOU commented Apr 2, 2020 via email

nyalldawson commented Apr 2, 2020

mikedoddOU commented Apr 2, 2020

nyalldawson commented Apr 2, 2020

mikedoddOU commented Apr 2, 2020

PedroVenancio commented Apr 2, 2020

AntonioPestana commented Dec 2, 2021

AntonioPestana commented Dec 2, 2021 • edited Loading

gioman commented Dec 3, 2021

AntonioPestana commented Dec 3, 2021 via email

rcragun commented Oct 23, 2024

AntonioPestana commented Dec 2, 2021 •

edited

Loading