[Qgis-developer] Datum Transformation - parameters for mainland Portugal

[Pedro Venâncio]

Hi André,


----- Mensagem original -----
> DE: André Joost 
>>>
>>> The transformation table inside QGIS only has those tfm from the
>>> EPSG database where the target CRS is 4326 (we want towgs84,
>>> right?)
>>>
>>> So I suggest to set target CRS for all new portuguese CRS to 4326
>>> as well.
>>
>>
>> Yes, I know Andre, in my proposal I put the transformations to 4326,
>> except the transformations using NTv2 grids, since these have been
>> prepared specifically for 4258, and do not use the "+towgs84"
>> parameter, but "+nadgrids". What do you think?
>
> We need them to convert to WGS84. If Marco filters the EPSG list for
> target=4326, he won't get them.
>
> In earlier years, WGS84 parameters were adopted from ETRS89 with a note
> "assuming that WGS84 and ETSR89 are the same". They seem to have
> dropped
> that.
>


I've been doing some tests and, in the case of NTv2 grids, using target_crs_code 4258 vs 4326, the difference is ~0.104mm, which is compatible with the coord_op_scope (decimetre accuracy), don't you think? In this case, we can simply put 4326 as target_crs_code, right?

Anyway, as Marco already inserted portuguese grids in srs.db, and the parameter used is +nadgrids, we don't need to put 4326 as grids target, because it is already in QGIS and the filter to the EPSG DB will prevent duplication.


Different situation happens with Molodensky and Bursa-Wolf transformations. 

Apparently, the latest transformation parameters are being made available for 4258. Nevertheless, if we use 4258 as target_crs_code, the error we get is huge, maybe because it generate some conflict with +towgs84 parameter.
So, simply changing the target_crs_code for 4326 (no further changes), it works ok.

I did some tests with tfm 5037, and with this same tfm but with target_crs_code changed to 4326. The results were these:
- Tmf 5037 (4274 -> 4258): more than 120m error! (this must be the problem with +towgs84)
- Tmf changed, using exactly the same transformation parameters, but with target_crs_code 4326 (4274 -> 4326): error ~0.292m. 

The question is, inevitably we have to put these latest transformations "manually" in srs.db, right? Otherwise they will be filtered out, because the target_crs is not 4326. There is nothing we can do with EPSG, right? 



>
>>
>>
>> The difference between them seems to me only the Prime Meridian, one
>> is referenced to Greenwich and the other to Lisbon:
>
> The transformation for those is a 2-step-transformation: First move the
> prime meridian from Lisbon to Greenwich, then do one of the
> Lisbon-to-WGS84 transformations. So no new parameters here.
>
>
>>
>> I also do not know if this has any implications on the accuracy of
>> the transformations, but which I find more strange is that all the
>> transformations are set from 4207. Would, in the past, EPSG
>> 20790/20791 were using Greenwich Prime Meridian, and this was updated
>> recently?
>


But then, why are the transformations referring to 4207 when the reference systems use pm=lisbon (4803) (except the new 5018)? This leads to this problem http://hub.qgis.org/issues/9614.



>
> No, they still use pm=lisbon, but 20791 was replaced by 5018 using
> Greenwich. The lon_0 moved from +1 to +lon_0=-8.131906111111112
>
> The pm=lisbon is at -9.0754862. I wonder why that fits.
>


I've been watching this and I get it! The information in the EPSG DB v8.4 is in Degrees, Minutes and Seconds, and when I extracted it for the table, the data in DMS changed the format. The longitude of datum Lisbon 1937 is 9°07'54.862" W of Greenwich, which, transformed to Decimal Degrees, is -9.131906111111112.
When I extracted that field to the table, it did not convert anything, simply changed from 9°07'54.862 to 9.0754862! :)



Regarding the Datum Transformation window, whenever I want to convert something to 4258, through a transformation +towgs84, what is done is, again, a 2-step-transformation:
1) source_crs -> 4326
2) 4326 -> 4258.
The problem is that there are now two transformations in srs.db 4326 -> 4258: tfm 1149 (+towgs84=0,0,0); and tmf 1571, that as you explained already, is a bug in the EPSG DB, and is generating a lot of confusion in the 2nd step of the transformation.

I think all deprecated transformations should be dropped.


Thank you very much!

Best regards,
Pedro